<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>Boxes and Arrows: Comments by Juan Ruiz</title>
    <link>http://www.boxesandarrows.com/person/3329</link>
    <pubDate>Mon, 30 Apr 2007 03:40:37 GMT</pubDate>
    <description>Comments by Juan Ruiz</description>
    <item>
      <description>&lt;p&gt;James, this is a very good article outlining what needs to be done before tackling the problem already defined by our clients, especially for internal applications (ie. intranet projects). As you mention, many times, the real problem is not well understood by the client and they tend to focus on common and/or popular solutions rather that understanding the real problem and finding the proper solution.&lt;/p&gt;

	&lt;p&gt;I would like to mention though, that &#8216;needs analysis&#8217; is successful if performed inside the organization because we have direct contact with staff and other workers within the organization. As for building external web applications or websites, where the general internet user will use the application, I find it hard to incorporate a &#8216;needs analysis&#8217; approach since I don&#8217;t have direct contact with external users. Putting together a &#8216;Business Analysis&#8217;, &#8216;Project Requirements&#8217; on the organization side of things, and a &#8216;User research&#8217;, &#8216;User tasks and goals&#8217; on the user side on things, help identify what the &#8216;needs analysis&#8217; achieves  for the internal projects. Or, do you have an example on how to use this approach on external web applications?&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/enterprise-ia#content_7133</link>
      <guid>http://www.boxesandarrows.com/view/enterprise-ia#content_7133</guid>
      <pubDate>Mon, 30 Apr 2007 03:40:37 GMT</pubDate>
      <author>Juan Ruiz</author>
    </item>
    <item>
      <description>&lt;p&gt;It is a topic for an article. Most of the information avaible now for IAs is based on the Enterprise IA model and organization-wide point of view. Where is the IA for small business? how can we tackle this new market?&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/idea/view/6793#content_7135</link>
      <guid>http://www.boxesandarrows.com/idea/view/6793#content_7135</guid>
      <pubDate>Mon, 30 Apr 2007 03:51:40 GMT</pubDate>
      <author>Juan Ruiz</author>
    </item>
    <item>
      <description>&lt;p&gt;We could look at a current software package that promises to solve all intranet needs: Intranet Dashboard. I&amp;#8217;m not advertising the product, but it would be good to know how they based their desicions for building each application / component.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/idea/view/5898#content_7192</link>
      <guid>http://www.boxesandarrows.com/idea/view/5898#content_7192</guid>
      <pubDate>Tue, 01 May 2007 01:19:12 GMT</pubDate>
      <author>Juan Ruiz</author>
    </item>
    <item>
      <description>&lt;p&gt;Good article, Amy and B&amp;amp;A Staff. It is always important to remember how to evangelize the IA and UX practice. I have found that lately our community (we) have been focusing on Enterprise IA or IA/UX for major projects, but, what about small projects? What about small-to-medium businesses that are just learning what IA/UX means? Or don&#8217;t have an idea of what IA/UX is?&lt;/p&gt;

	&lt;p&gt;In my case, I work for a non-profit organization. I have introduced these new concepts onto their project management methodologies, but it has been a very tough road. A major roadblock was that my clients were used to work with Business Analysis documentation and deliverables, and I had to modify my IA/UX findings to look and read like BA documents. While I found this frustrating, I understood that, I had to speak their language first before they speak mine. Now, my documentation is looking more like IA/UX deliverables, but like I said, it took some time to achieve this.&lt;/p&gt;

	&lt;p&gt;One of my best days at work was when my supervisor (PM) was training a new employee and she was introducing IA/UX methodologies to the new team member. That&amp;#8217;s when I knew I was making a change!&lt;/p&gt;

	&lt;p&gt;Keep up working on evangelizing our profession. While I feel that large corporations know about it, we still have to educate small-to-medium businesses about IA/UX methodologies and the &lt;span class="caps"&gt;ROI&lt;/span&gt; of implementing them. Like Seth said: &#8220;Often times, it&#8217;s more about the person than the process.&#8221;&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/pioneering-a-user#content_9241</link>
      <guid>http://www.boxesandarrows.com/view/pioneering-a-user#content_9241</guid>
      <pubDate>Fri, 07 Jan 2011 19:40:35 GMT</pubDate>
      <author>Juan Ruiz</author>
    </item>
    <item>
      <description>&lt;p&gt;Nice, very nice! I cannot only put a face on their names, now I can put a voice too. I have to attend one of these summits&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/meet-your-peers#content_18547</link>
      <guid>http://www.boxesandarrows.com/view/meet-your-peers#content_18547</guid>
      <pubDate>Mon, 14 Apr 2008 02:37:16 GMT</pubDate>
      <author>Juan Ruiz</author>
    </item>
    <item>
      <description>&lt;p&gt;Hi B&amp;amp;A team,&lt;br /&gt;I was talking to one of my new colleagues on where to find good and reliable information in regards to IA, and the first thing I said was &amp;#8220;Go and check out the Boxes and Arrows website&amp;#8221;. I&amp;#8217;ve been using the website for 4+ years now, so I think I owe you guys a big &amp;#8220;thank you&amp;#8221; for your hard work and for helping to shape the industry to what it is now.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/welcome_to_boxes_and_arrows#content_29614</link>
      <guid>http://www.boxesandarrows.com/view/welcome_to_boxes_and_arrows#content_29614</guid>
      <pubDate>Fri, 07 Jan 2011 19:40:35 GMT</pubDate>
      <author>Juan Ruiz</author>
    </item>
    <item>
      <description>&lt;p&gt;Hi Paul, I like that you have documented &lt;span class="caps"&gt;QTUT&lt;/span&gt; and how it should be ran. Following Anthony&amp;#8217;s comment that almost most of the projects are becoming &amp;#8220;agil-ish&amp;#8221;, I have found myself running many &lt;span class="caps"&gt;QTUT&lt;/span&gt; already. So, in my experience:
* Sales &amp;amp; Kickoff. I agree with you, we have to help our sales team and set up proper expectations of the exercise to the client. But I don&amp;#8217;t agree with the part that you say to &amp;#8220;avoid&amp;#8221; clients that are rigid. We cannot always get the perfect client, so we have to accommodate and be flexible with out methodologies and deliverables. In this case, setting up proper expectation with the clients is the key part of the testing, so they know the benefits of the test and what they will get out of it.
* Recruitment: We usually use an external company to do our recruitment and scheduling. We found that this part is very time consuming if done internally.
* Preparation: This is something that I work together with the client. Using the Kick-off session to gather data for this stage is a great recommendation. We usually create the initial script and give it to the client to review. On the script we highlight any conditions/assumptions/dependencies of the testing, for example, if it is a prototype, only few pages and features are working, if it is a major website or application, we highlight that we will only be testing an specific section, etc. This goes back to the &amp;#8220;Sales and Kick-off&amp;#8221; step of setting up correct expectations.&lt;br /&gt;Good article, looking forward for part 2.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/quick-turnaround#content_30545</link>
      <guid>http://www.boxesandarrows.com/view/quick-turnaround#content_30545</guid>
      <pubDate>Fri, 07 Jan 2011 19:40:35 GMT</pubDate>
      <author>Juan Ruiz</author>
    </item>
    <item>
      <description>&lt;p&gt;Hi Dana,&lt;/p&gt;

	&lt;p&gt;In regards to your 5 points to see if we are dissing our participants, you are so right! It is great to be reminded that we work with &amp;#8220;participants&amp;#8221; once in a while. When UX professionals have conducted many usability session, sometimes we see more usability tests as a factory job, a factory line: participant comes in, we perform the study, participant gets paid, we deliver results.&lt;/p&gt;

	&lt;p&gt;As for recruiting participants, this is a tough job by itself. Usually, UX professionals don&amp;#8217;t have enough time to setup a usability test, and the time allocated to recruit participants is very short, therefore, we can&amp;#8217;t use open ended questions, because it means that we have to read all the answer and analyze each one of them. What we do instead, we work with multiple choice questions, but we give a weight to each of the answers, that way, even if the participant is smart enough to figure out the screening, they answers will sum-up a different number compare to other participants, that way we can select the ones with the highest score. Not the best method, but something that works for us when we are running short on time.&lt;/p&gt;

	&lt;p&gt;-Juan&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/why-we-call-them#content_31189</link>
      <guid>http://www.boxesandarrows.com/view/why-we-call-them#content_31189</guid>
      <pubDate>Thu, 27 Nov 2008 02:43:54 GMT</pubDate>
      <author>Juan Ruiz</author>
    </item>
  </channel>
</rss>

