<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>Comments on What You Should Know About Prototypes for User Testing</title>
    <link>http://www.boxesandarrows.com/view/what_an_ia_should_know_about_prototypes_for_user_testing</link>
    <pubDate>Thu, 01 Jul 2010 11:41:14 GMT</pubDate>
    <description>There are several important factors to consider when you are planning to do prototyping for user testing.  You will want to make careful choices about fidelity, level of interactivity and the medium of your prototype. Chris Farnum offers descriptions and best use scenarios to help you make the best prototype decision for your tests.</description>
    <item>
      <description>&lt;p&gt;If you or the customer want hi-fi prototypes, then great &amp;#8211; but why not work with the graphic designer to produce them?  The comments here are as if the designer doesn&amp;#8217;t even exist until the prototype is approved.&lt;/p&gt;

	&lt;p&gt;Everyone knows that IA and Graphic Design overlap considerably.  Each person in those roles should allow the overlap to be worked on with the other.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/what_an_ia_should_know_about_prototypes_for_user_testing#content_706</link>
      <guid>http://www.boxesandarrows.com/view/what_an_ia_should_know_about_prototypes_for_user_testing#content_706</guid>
      <pubDate>Thu, 01 Jul 2010 11:41:14 GMT</pubDate>
      <author>David Frahm</author>
    </item>
    <item>
      <description>&lt;p&gt;&amp;gt;I laughed out loud at that. How often does the &amp;gt;final visual design look like a &amp;#8220;prettied up&amp;#8221; version &amp;gt;of the wireframes?&lt;/p&gt;

	&lt;p&gt;&amp;gt;Truth is, most IAs want to be designers as well. &amp;gt;It&amp;#8217;s a control thing.&lt;/p&gt;

	&lt;p&gt;If a design ends up being a &amp;#8220;prettied up&amp;#8221; version of the wireframe then that is the sole fault of the web designer or graphic artists who created the design. &lt;br /&gt;There are pros and cons to using high, medium and low fidelty prototypes. The only way you can use low fidelity prototype wireframes is if you have an artist who is creative enough to look past the lines drawn on a wireframe to create something spectacular and origional, and if you have a marketer who can suspend reality and use their imagination when discussing wireframe layouts. A true internet marketer should be able to distinguish the difference between a wireframe and a design.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/what_an_ia_should_know_about_prototypes_for_user_testing#content_705</link>
      <guid>http://www.boxesandarrows.com/view/what_an_ia_should_know_about_prototypes_for_user_testing#content_705</guid>
      <pubDate>Tue, 11 Jan 2011 03:40:00 GMT</pubDate>
      <author>anonymous</author>
    </item>
    <item>
      <description>&lt;p&gt;Just a quick one &amp;#8211; great article, good points.  One thing I can say from experience is that most times this really depends of who you are going to be showing this prototype to.  I would never show a client, a marketing person or a designer a fully (heck anything that looks &amp;#8220;done&amp;#8221; at all &amp;#8211; even halfway) rendered prototype &amp;#8211; you&amp;#8217;re just asking for a world of hurt.&lt;/p&gt;

	&lt;p&gt;It&amp;#8217;ll be very hard to get them to suspend belief (read: judgement) long enough to get some good information out of them and you run the risk of them liking or disliking it too much.&lt;/p&gt;

	&lt;p&gt;I tend to like the low fidelity approach, but sometimes I like to show feedback and interactivity, again, depending on who I&amp;#8217;m working with &amp;#8211; I&amp;#8217;ve found it best to do this as minimally as possible.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/what_an_ia_should_know_about_prototypes_for_user_testing#content_704</link>
      <guid>http://www.boxesandarrows.com/view/what_an_ia_should_know_about_prototypes_for_user_testing#content_704</guid>
      <pubDate>Fri, 26 Jan 2007 14:50:29 GMT</pubDate>
      <author>dkr</author>
    </item>
    <item>
      <description>&lt;p&gt;First of all, let me remind you that its &amp;#8216;Spitzer&amp;#8217;. Certainly I&amp;#8217;m in violent agreement with most of what Chris wrote.&lt;/p&gt;

	&lt;p&gt;I&amp;#8217;d only add that in the last year we have been designing consumer kiosk and business applications that get developed in C#, so prototyping in &lt;span class="caps"&gt;HTML&lt;/span&gt; is completely out of the question! John Armitage joined us, having previously worked for Aaron Marcus and Viant, and brought expertise prototyping in Macromedia Director. We have found that Director can be a very powerful tool for medium fidelity prototyping, as well as for adding graphical elements once the core workflows are established. Our process has evolved into writing scenarios, animating the scenarios with black and white Director wireframes, getting user feedback, and then building out software support for the scenario.&lt;/p&gt;

	&lt;p&gt;We&amp;#8217;re happy with this process. For recent projects, its been important that our prototypes include controls for display/edit of all the information that the application deals with (our users are librarians &amp;#8211; if we miss a field, its a big deal), so the fidelity has been high from the standpoint of information content, but low from the standpoint of graphical treatment.&lt;/p&gt;

	&lt;p&gt;We&amp;#8217;re in a between project breather and (because product development is in Jack&amp;#8217;s and my blood) thinking about how to build a set of tools to enforce the process and open it up to other tools besides Director for wireframe production. Director is especially good because its easy to manage a library of reusable UI components (the cast).&lt;/p&gt;

	&lt;p&gt;- cheers&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/what_an_ia_should_know_about_prototypes_for_user_testing#content_703</link>
      <guid>http://www.boxesandarrows.com/view/what_an_ia_should_know_about_prototypes_for_user_testing#content_703</guid>
      <pubDate>Fri, 26 Jan 2007 14:50:29 GMT</pubDate>
      <author>Tom Spitzer</author>
    </item>
    <item>
      <description>&lt;p&gt;(at the risk of starting a thread.. :)&lt;/p&gt;

	&lt;p&gt;I guess the point I was trying to make was that low fidelity prototyping, in a situation where you need to share it with other people, is rather limiting due to ambiguity caused by &amp;#8220;not all the elements being present&amp;#8221; and invariably leads to misunderstandings. Many people are not able to fully conceptualise architecture and linking etc etc etc.&lt;/p&gt;

	&lt;p&gt;Cost is no issue when you have a quick &lt;span class="caps"&gt;HTML&lt;/span&gt; based prototyping tool. (and I really mean basic here&amp;#8230; No grpahics no nuthing, just a site structure, navigation system and wireframe/&amp;#8221;page description diagram&amp;#8221; boxes.)&lt;/p&gt;

	&lt;p&gt;I&amp;#8217;ve developed everything from brochure websites (&amp;#8220;hi, this is our company, thanks for visiting&amp;#8221;) to full blown e-commerce systems (world wide online grocery shopping network)... But my specialty is web-based GUIs for embedded systems (wireless &lt;span class="caps"&gt;LAN&lt;/span&gt; routers, etc). In the 8 years I&amp;#8217;ve been doing this I&amp;#8217;ve dealt with mom-and-pop business owners, top-tier executives, management types of all levels and all departments and ultra-brainiac engineers and scientists. &lt;span class="caps"&gt;NEVER&lt;/span&gt; have I dealt with a &amp;#8220;client&amp;#8221; who could or wanted to understand the underlying process. &amp;#8220;Show me what you are going to do&amp;#8221; or &amp;#8220;show me what you want me to do&amp;#8221; is what it&amp;#8217;s always about.&lt;/p&gt;

	&lt;p&gt;And it is important to adapt, tailor your output for the person who is going to recieve it. Don&amp;#8217;t show a &lt;span class="caps"&gt;CEO&lt;/span&gt; the taxonomy, and don&amp;#8217;t hand a designer a page layout design.&lt;/p&gt;

	&lt;p&gt;;)&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/what_an_ia_should_know_about_prototypes_for_user_testing#content_702</link>
      <guid>http://www.boxesandarrows.com/view/what_an_ia_should_know_about_prototypes_for_user_testing#content_702</guid>
      <pubDate>Fri, 26 Jan 2007 14:50:29 GMT</pubDate>
      <author>Boris</author>
    </item>
    <item>
      <description>&lt;p&gt;I strongly disagree with Boris&amp;#8212;I&amp;#8217;ve tested many a site with low fidelity prototype (vision wireframes being my prototype of choice) and find them an invaluable tool.  It does, I imagine, depend on what you&amp;#8217;re trying to get out of the test.&lt;/p&gt;

	&lt;p&gt;With the strongly functional sites that I work in, I&amp;#8217;m testing to look for:&lt;br /&gt;- do users understand the gist of the navigation? (and sure, a take-away might be that a particular element needs more graphic prominance, but you&amp;#8217;re also going to get great feedback on how your scheme fits into their conception of things)&lt;br /&gt;- am the prototype missing things functionally that people expect&amp;#8212;i.e. features, fields, etc&lt;br /&gt;- how does the flow in accomplishing tasks work for them?&lt;/p&gt;

	&lt;p&gt;The cheapness and earliness of the process (if I&amp;#8217;m using wireframes, generally I&amp;#8217;m going to do them anyway) to my mind altogether makes up for any mis-understandings caused by lack of graphic design.  And then you can test the graphic design later when you&amp;#8217;re sure that the foundation is solid.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/what_an_ia_should_know_about_prototypes_for_user_testing#content_701</link>
      <guid>http://www.boxesandarrows.com/view/what_an_ia_should_know_about_prototypes_for_user_testing#content_701</guid>
      <pubDate>Fri, 26 Jan 2007 14:50:29 GMT</pubDate>
      <author>lsq</author>
    </item>
    <item>
      <description>&lt;p&gt;Low fidelity prototyping is only good when presenting to other IA&amp;#8217;s / people in the dev team who have the brains to &amp;#8220;fill in the blanks&amp;#8221;. I have been in enough meetings with marketing (or whoever thinks they are in charge) with hand drawn layouts and paper trees and entire week long discussions only to in the end hear &amp;#8220;oh, we didn&amp;#8217;t *get it* that way&amp;#8230;&amp;#8221;&lt;/p&gt;

	&lt;p&gt;It&amp;#8217;s all about details people! The more elements you make clear, the better the communication. When protyping a web project, the key elements to convey are:&lt;br /&gt;1- what content goes where&lt;br /&gt;2- how do i get from here to there&lt;br /&gt;3- how did I get from there to here&lt;br /&gt;4- (arguably) how the content is layed-out on the screen. (not in my book but anyways, it makes VP feel happy when they see a layout even though they don&amp;#8217;t get the context).&lt;/p&gt;

	&lt;p&gt;SO.. high fidelity my friends. &amp;#8220;The devil is in the details&amp;#8221;. &amp;#8220;Ambiguity: the devil&amp;#8217;s volleyball&amp;#8230;&amp;#8221; (No I ain&amp;#8217;t no christian freak, I just like good quotes ;)&lt;/p&gt;

	&lt;p&gt;SO, I guess I should someday make public my &lt;span class="caps"&gt;PHP&lt;/span&gt;-based rapid site prototyping system&amp;#8230; build up an entire site architecture in minutes, and even set complete wireframes of layouts using &lt;span class="caps"&gt;CSS&lt;/span&gt;.. also in minutes&amp;#8230; And the best part? Once the client/boss signs off, you slap in some colors and graphics and the site is done! Bwahahahahaha&amp;#8230;&lt;/p&gt;

	&lt;p&gt;Cheers !&lt;/p&gt;

	&lt;p&gt;B.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/what_an_ia_should_know_about_prototypes_for_user_testing#content_700</link>
      <guid>http://www.boxesandarrows.com/view/what_an_ia_should_know_about_prototypes_for_user_testing#content_700</guid>
      <pubDate>Fri, 26 Jan 2007 14:50:29 GMT</pubDate>
      <author>Boris</author>
    </item>
    <item>
      <description>&lt;p&gt;I&amp;#8217;ve worked on several large-ish scale prototypes (from 10 to 50+ pages (paper and &lt;span class="caps"&gt;HTML&lt;/span&gt;)) in the past and count myself on the high fidelity team. The basic reason why is the &amp;#8216;suspension of disbelief&amp;#8217; issue seems to rear its head everytime I present a prototype. Rather than bore folks with the longer story here, I&amp;#8217;ve blogged my experience&amp;#8230;&lt;/p&gt;

	&lt;p&gt;&lt;a href="http://inmyexperience.com/archives/000164.shtml" rel="nofollow" rel="nofollow"&gt;http://inmyexperience.com/archives/000164.shtml&lt;/a&gt;&lt;/p&gt;

	&lt;p&gt;Excellent article Chris.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/what_an_ia_should_know_about_prototypes_for_user_testing#content_699</link>
      <guid>http://www.boxesandarrows.com/view/what_an_ia_should_know_about_prototypes_for_user_testing#content_699</guid>
      <pubDate>Tue, 11 Jan 2011 03:40:01 GMT</pubDate>
      <author>Dan Kapusta</author>
    </item>
    <item>
      <description>&lt;p&gt;J-&lt;br /&gt;I think it depends enormously on the personalities involved.  It also depends on their skill sets.  I find that when I work with highly creative graphic designers I need to really keep the level of visual detail low-end on my deliverables so that I don&amp;#8217;t step on toes.  Sometimes, text-only description is the way to go.  When I work with programmers or other folks less interested in visual design, I tend to offer more detail.  Many times in the past I&amp;#8217;ve groaned when I have seen a final design stick too close to my wireframe layout.  One of the best antidotes is to communicate as much as possible with the rest of the team so that they get a good sense of which aspects of your wireframes are open to interpretation.&lt;/p&gt;

	&lt;p&gt;Now, wireframes that you create to use as prototypes on the other hand often need to have some sort of rudimentary visual design applied.  The trick is to try to get the respondents to &lt;span class="caps"&gt;NOT&lt;/span&gt; react to your clunky layout.  Again, communication is helpful.  Another trick is the pencil sketch idea I mentioned in the article.  If the respondents see that the design is hand drawn and rough, they are less likely to take the visual design seriously.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/what_an_ia_should_know_about_prototypes_for_user_testing#content_698</link>
      <guid>http://www.boxesandarrows.com/view/what_an_ia_should_know_about_prototypes_for_user_testing#content_698</guid>
      <pubDate>Fri, 26 Jan 2007 14:50:29 GMT</pubDate>
      <author>Chris Farnum</author>
    </item>
    <item>
      <description>&lt;p&gt;i am an ia and would sometimes love to be a visual designer as well, but, alas, (sigh) i have no talent in the visual realm.&lt;/p&gt;

	&lt;p&gt;it would be great to be a one man/woman show, but that&amp;#8217;s usually not how it works, right?&lt;/p&gt;

	&lt;p&gt;wireframes are tricky since there is overlap between identification of functional page elements and how to position them on the page from a usability perspective (another overlap area).&lt;/p&gt;

	&lt;p&gt;ow does one often deal with this? does it depend on the personalities invoved?&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/what_an_ia_should_know_about_prototypes_for_user_testing#content_697</link>
      <guid>http://www.boxesandarrows.com/view/what_an_ia_should_know_about_prototypes_for_user_testing#content_697</guid>
      <pubDate>Fri, 26 Jan 2007 14:50:29 GMT</pubDate>
      <author>j. hatfield</author>
    </item>
    <item>
      <description>&lt;p&gt;&amp;gt; I laughed out loud at that. How often does the final visual&lt;br /&gt;&amp;gt; design look like a &amp;#8220;prettied up&amp;#8221; version of the wireframes?&lt;/p&gt;

	&lt;p&gt;&amp;gt; Truth is, most IAs want to be designers as well. It&amp;#8217;s a control thing.&lt;/p&gt;

	&lt;p&gt;I agree, many times I&amp;#8217;ve created wireframes, the finished design also ends up being a &amp;#8220;prettied up&amp;#8221; wireframe design.&lt;/p&gt;

	&lt;p&gt;On the other hand, I&amp;#8217;ve created well laid out wireframes which make clear hierarchical sense, only to find the designer has ripped apart all the page elements with a completely different design layout, that actually looks more confusing than the original wireframe.&lt;/p&gt;

	&lt;p&gt;Is this a case of designers trying to be IAs? I think this &amp;#8216;control thing&amp;#8217; works both ways.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/what_an_ia_should_know_about_prototypes_for_user_testing#content_696</link>
      <guid>http://www.boxesandarrows.com/view/what_an_ia_should_know_about_prototypes_for_user_testing#content_696</guid>
      <pubDate>Tue, 11 Jan 2011 03:40:02 GMT</pubDate>
      <author>Steve</author>
    </item>
    <item>
      <description>&lt;p&gt;&amp;gt; An information architecture wireframe &lt;br /&gt;&amp;gt; is &lt;span class="caps"&gt;NOT&lt;/span&gt; graphic design. I swear, it&amp;#8217;s really not!!!&lt;/p&gt;

	&lt;p&gt;I laughed out loud at that. How often does the final visual design look like a &amp;#8220;prettied up&amp;#8221; version of the wireframes?&lt;/p&gt;

	&lt;p&gt;Truth is, most IAs want to be designers as well. It&amp;#8217;s a control thing.&lt;/p&gt;

	&lt;p&gt;Cheers, d&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/what_an_ia_should_know_about_prototypes_for_user_testing#content_695</link>
      <guid>http://www.boxesandarrows.com/view/what_an_ia_should_know_about_prototypes_for_user_testing#content_695</guid>
      <pubDate>Tue, 11 Jan 2011 03:40:02 GMT</pubDate>
      <author>David</author>
    </item>
  </channel>
</rss>

