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.
Degree of fidelity
Low fidelity
You can use hand-drawn sketches to create a paper prototype. If you go this route, you may also want to help your users get into the spirit of things during the test by creating a complete low-fidelity, paper environment. This could include a cardboard box made to look like a computer and an object to hold to point and click with. These techniques help users to suspend their disbelief and get their imaginations involved so that they can better visualize the interface. The advantage of using rough sketches is that users will have an easier time suggesting changes. They may even grab a pen and start making their own changes (Datz-Kauffold and Henry).
In theory, low-fidelity sketches are also a time-saver, but this really depends on your point of view. Personally, I like to draw diagrams and wireframes in Visio where I can revise and move things around without erasing and redrawing. If you prefer to work this way too, and if time allows, you can always have those Visio drawings hand-traced or use them as a roadmap for making sketches to test with. You might even find a graphics tool with a filter that will convert a Visio-generated graphic into a hand-drawn sketch with wavy lines.
High fidelity
This approach takes you as close as possible to a true representation of the user interface —screen-quality graphics. All of the blanks on the page are filled in, and it looks good. However, you might not have all of the technical or backend problems worked out yet, or you might have only a small part of the entire site rendered. That’s why it’s still considered a prototype. For example, it might consist of a small series of Photoshop images or HTML pages with just enough functional links to convey the feel of the site’s flow. You may need to enlist the help of a graphic designer or web developer to build these in a reasonable amount of time. Advocates for high-fidelity prototypes argue that they are easier for users to understand just by looking at them. There is no disbelief to overcome, and it is easier to determine when they really do not understand the design. If you choose a high-fidelity prototype, make sure the you have enough of the design fleshed out so that users can complete several tasks. Decide on these tasks early, so you know which areas of the design need to be represented for your tests. Otherwise, you will be in for a great deal of preparation work.
Medium fidelity
In the grand tradition of Goldilocks, I find myself drawn to the middle approach. A medium-fidelity approach tends to include some visual design and a level of detail somewhere between high and low fidelity. Does this sound familiar? As an information architect, I’m accustomed to creating wireframes I can hand off to decision-makers, graphic designers, web developers and programmers. An information architecture wireframe is NOT graphic design. I swear, it’s really not!!! But… I’ll admit that it has enough visual design to convey a rough version of the user interface. Because I create these with drawing tool software, they tend to have more polish than hand-drawn diagrams. Hakim and Spencer are champions for medium-fidelity prototypes because they fit more seamlessly into the design process while providing more realism for users. I found this to be true during a project to design a search interface for Egreetings with my colleagues at Argus. I created rough draft wireframes for the prototype, and after testing I revised them for use in my deliverables.
Interactivity
Interactivity describes how your prototype behaves. Does your prototype react to user inputs with feedback? Can they “click” on something to go to another page or fill in a form? Will buttons appear to depress and drop-down menus work?
Static prototypes
Prototypes used for testing are static if they are pages or page elements shown to users, which don’t provide any feedback. It can sometimes work well to show a page to a user and ask them to explain it to you or to guess where they can go from here. In this kind of test, the user interprets the prototype rather than interacts with it. This is a good way to validate your design by checking to make sure users understand it. It’s also easy to score this sort of test when you have a standard list of questions to ask about each page.
Automated
Automated prototypes allow users to make choices that cause changes. The testing prototype provides the user with feedback. Elements are “clickable” and forms can be filled out. The interface reacts to the user while the tester observes. One way to do this is to create the prototype in HTML or some application that allows interactive elements such as Flash, Visual Basic or even PowerPoint.
Another way to achieve a kind of pseudo-automated interactivity when you have chosen a paper prototype is to pretend (Datz-Kauffold and Henry). Have you ever seen children at play pretend that they are driving a car by setting up chairs for the front and back seats, drawing a dashboard on a cardboard box, and using a Frisbee for the steering wheel? If you have set up the right environment for your users, you can ask them to pretend scraps of paper on a table are their computer screen. When they “click” on a drop-down menu by touching the element with a pointer, a tester assigned to the role of the computer provides feedback by swapping the closed menu for an open one that shows choices. The “computer” may need to write on some elements before showing them to the user, i.e., “Your search retrieved 523,621 hits.” It takes a few minutes to get test participants used to the idea, but if you encourage them to have fun with it you will learn a great deal. You can also easily try out different possible reactions to user input.
This method worked well during the Egreetings project. We especially emphasized the technique of asking the users to click and then provide feedback. We found it useful to laminate the screen components so we didn’t need to produce a clean copy of the test for every subject. The users could write on the laminated pieces with thin whiteboard markers when making selections and entering search criteria. Of course, this meant that we needed to take careful notes because of the need to erase between each test subject.
Here are some other tips to try for low-fidelity testing with simulated interactivity:
- Bring extra paper so you or the respondent can sketch out an idea if the opportunity arises.
- As with any user test, it really helps to ask the respondent to think aloud.
- If you have the luxury, bring a team of three to the test: someone to take notes, someone to play the “computer” and another to facilitate.
- Use a piece of posterboard as your “screen.”
- Cut your design into separate pieces or zones as appropriate and ask the user to rearrange them in the order they prefer.
- Attach the folder tabs that come with hanging files to components so they are easier to grab.
- Invite users to throw away or cross out components that they don’t think are important.
- Number the pieces so that you can easily refer to them in your notes and keep them organized.
- If you do decide to bring separate copies of the test materials for each session, tape down the components to a larger piece of paper as arranged by each user so you have these artifacts to analyze later.
Prepare a kit for yourself containing:
- Scissors and tape,
- Different sizes and varieties of sticky notes (which make great drop-down menus),
- Markers and pens in various colors and sizes,
- Paper clips and binder clips for keeping slips of paper organized, and
- Objects that the user can pretend are the mouse pointer, such as a feather or a small toy.
Medium
There are many possible combinations to choose from for building your prototype. One of the first choices to make is whether you want to have your prototype viewed on an actual computer screen or if you’ll be working on a tabletop with a paper prototype. Believe it or not, fidelity and interactivity are independent of the medium you choose. It’s probably most natural to think of the extreme cases. An automated HTML prototype is often high-fidelity and, of course, the medium is a computer screen. Likewise, a natural medium for a low-fidelity automated interactive prototype is hand-drawn sketches on paper. However, you can also have the following:
- Low to medium-fidelity wireframes built in PowerPoint that show only lines and boxes with text;
- animation features provide automated interactivity,
- Static Photoshop prototype pages shown to users on a computer screen, or
- Same as above, but printed out in color on paper.
Mixing the variables
You can mix these three variables (fidelity, interactivity and medium) in many different combinations. The exact combination you choose should match the goals you determine for your testing. Possible goals for an IA prototype include:
- Testing the effectiveness of labels and icons.
- Finding out the right balance of depth and breadth of a topical hierarchy.
- Determining the right options to offer for narrowing a search.
- Choosing the most important metadata elements to show on a search results screen.
- Settling the question of whether your target audience accomplishes tasks better with a task-oriented organization scheme or with a topical organization scheme.
If you live and breathe NetObjects Fusion and don’t have much time, your preference might be to create a medium-fidelity prototype. That way you could test that sitemap you are working on using some rough placeholder graphics or text instead of the finished graphic design. How you mix the variables depends on the time and budget you have available, as well as your work style. Try experimenting with different approaches to learn how prototyping will work best with your design process.
 |
For more information
|
|
| Chris Farnum is an information architect with over four years’ experience, and is currently with Compuware Corporation. Three of those years were spent at Argus Associates working with Lou Rosenfeld and Peter Morville, the authors of Information Architecture for the World Wide Web. |
|
> An information architecture wireframe
> is NOT graphic design. I swear, it’s really not!!!
I laughed out loud at that. How often does the final visual design look like a “prettied up” version of the wireframes?
Truth is, most IAs want to be designers as well. It’s a control thing.
Cheers, d
> I laughed out loud at that. How often does the final visual
> design look like a “prettied up” version of the wireframes?
> Truth is, most IAs want to be designers as well. It’s a control thing.
I agree, many times I’ve created wireframes, the finished design also ends up being a “prettied up” wireframe design.
On the other hand, I’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.
Is this a case of designers trying to be IAs? I think this ‘control thing’ works both ways.
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.
it would be great to be a one man/woman show, but that’s usually not how it works, right?
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).
ow does one often deal with this? does it depend on the personalities invoved?
J-
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’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’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.
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 NOT 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.
I’ve worked on several large-ish scale prototypes (from 10 to 50+ pages (paper and HTML)) in the past and count myself on the high fidelity team. The basic reason why is the ‘suspension of disbelief’ issue seems to rear its head everytime I present a prototype. Rather than bore folks with the longer story here, I’ve blogged my experience…
http://inmyexperience.com/archives/000164.shtml
Excellent article Chris.
Low fidelity prototyping is only good when presenting to other IA’s / people in the dev team who have the brains to “fill in the blanks”. 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 “oh, we didn’t *get it* that way…”
It’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:
1- what content goes where
2- how do i get from here to there
3- how did I get from there to here
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’t get the context).
SO.. high fidelity my friends. “The devil is in the details”. “Ambiguity: the devil’s volleyball…” (No I ain’t no christian freak, I just like good quotes 😉
SO, I guess I should someday make public my PHP-based rapid site prototyping system… build up an entire site architecture in minutes, and even set complete wireframes of layouts using CSS.. also in minutes… And the best part? Once the client/boss signs off, you slap in some colors and graphics and the site is done! Bwahahahahaha…
Cheers !
B.
I strongly disagree with Boris– I’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’re trying to get out of the test.
With the strongly functional sites that I work in, I’m testing to look for:
– 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’re also going to get great feedback on how your scheme fits into their conception of things)
– am the prototype missing things functionally that people expect– i.e. features, fields, etc
– how does the flow in accomplishing tasks work for them?
The cheapness and earliness of the process (if I’m using wireframes, generally I’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’re sure that the foundation is solid.
(at the risk of starting a thread.. 🙂
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 “not all the elements being present” and invariably leads to misunderstandings. Many people are not able to fully conceptualise architecture and linking etc etc etc.
Cost is no issue when you have a quick HTML based prototyping tool. (and I really mean basic here… No grpahics no nuthing, just a site structure, navigation system and wireframe/”page description diagram” boxes.)
I’ve developed everything from brochure websites (“hi, this is our company, thanks for visiting”) to full blown e-commerce systems (world wide online grocery shopping network)… But my specialty is web-based GUIs for embedded systems (wireless LAN routers, etc). In the 8 years I’ve been doing this I’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. NEVER have I dealt with a “client” who could or wanted to understand the underlying process. “Show me what you are going to do” or “show me what you want me to do” is what it’s always about.
And it is important to adapt, tailor your output for the person who is going to recieve it. Don’t show a CEO the taxonomy, and don’t hand a designer a page layout design.
😉
First of all, let me remind you that its ‘Spitzer’. Certainly I’m in violent agreement with most of what Chris wrote.
I’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 HTML 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.
We’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 – 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.
We’re in a between project breather and (because product development is in Jack’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).
– cheers
Just a quick one – 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 “done” at all – even halfway) rendered prototype – you’re just asking for a world of hurt.
It’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.
I tend to like the low fidelity approach, but sometimes I like to show feedback and interactivity, again, depending on who I’m working with – I’ve found it best to do this as minimally as possible.
>I laughed out loud at that. How often does the >final visual design look like a “prettied up” version >of the wireframes?
>Truth is, most IAs want to be designers as well. >It’s a control thing.
If a design ends up being a “prettied up” version of the wireframe then that is the sole fault of the web designer or graphic artists who created the design.
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.
If you or the customer want hi-fi prototypes, then great – but why not work with the graphic designer to produce them? The comments here are as if the designer doesn’t even exist until the prototype is approved.
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.