What You Should Know About Prototypes for User Testing

Written by: Chris Farnum

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 “An information architecture wireframe is NOT graphic design. I swear, it’s really not!!!”Fidelity is the degree of closeness to the “depth, breadth and finish of the intended product” (Hakim & Spitzer). Opinions vary a great deal on how much a prototype should resemble the final version of your design. Usability practitioners like Barbara Datz-Kauffold and Shawn Lawton Henry are champions for low fidelity —the sketchier the better! Meanwhile, Jack Hakim and Tom Spitzer advocate a medium- to high-fidelity approach that gives users a closer approximation of a finished version. You’ll want to make a decision about the right approach for you based on the needs of your project.

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 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 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.

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

  • Evaluating Information Architecture,” Steve Toub (2000).
  • UPA 2000 Proceedings:
    #28 – “Waving Magic Wands: Interaction Techniques to Improve Usability Testing Low-Fidelity Protoypes,” Barb Datz-Kauffold & Shawn Lawton Henry.
    #32 – “Prototyping for Usability,” Jack Hakim & Tom Spencer.
  • “Prototyping for Tiny Fingers,” Marc Rettig, Communications of the ACM, Vol.37, No.4 (April 1994).
    http://portal.acm.org/citation.cfm?id=175288 (ACM Membership required)
  • Using Paper Prototypes to Manage Risk,” User Interface Engineering.
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.

Bringing Your Personas to Life in Real Life

Written by: Elan Freydenson

You read about personas in “The Inmates are Running the Asylum.” You know that using them improves your interactive designs and helps get your coworkers on the same boat. You did your ethnographic research, created a useful persona set and are ready to start designing for the needs of your personas. But first you have to document and share your personas with your colleagues.

When presenting, talking about your personas, or referring to them in writing, communicate as though they are real people, people that you know. Express it like you are talking about a friend.

The way you communicate the personas and present your deliverables is key to ensuring consistency of vision. Without that consistency, you’ll spend far too much time arguing with your colleagues about who your users are rather than how to meet their needs. Let’s start with a review of what we know about personas, and why they are useful.

Personas are user archetypes created primarily to be design targets
Personas are almost always based on patterns and findings you gather during interviewing. You use them to prevent problems such as the “elastic user”—the user that morphs from grandmother, to John Doe, to your CEO, depending on the day. Having a stationary target in a non-stationary world is a first step to creating a holistic, useful and usable product.

As a first step to documenting your personas, make sure you’ve done the preliminary work. You created multiple personas, fleshed out to the same level of detail. For most projects, each persona has at least a first and last name, age, goals, background story, a telling quote, email address, job title and a photograph. Some projects may require more characteristics to highlight specific areas of importance

Depending on the project, you identify various persona characteristics or facets relevant to the design (more on this later). Finally, give each persona a designated status: primary, secondary, supplemental, negative, etc.

These designations help prioritize your design efforts. In later design stages, you will create scenarios for a design that satisfies mainly the needs of your primary. Status designation also helps to minimize feature creep; requests are easier to reject or incorporate when you’ve already decided who the product is and isn’t for (e.g., it shouldn’t be added if it is for your negative persona, if it is only for your secondary it can be hidden away from the primary areas).

Marlena, an interaction designer using personas
As an example, let’s watch Marlena go through the process of preparing and documenting personas at her company. Marlena is an interaction designer at DigitalMail, a provider of HTML email marketing software for managing customer relationships. Adam, also an interaction designer, is working closely with Marlena on designing the next version of DigitalMail’s flagship product, DigitalMail Reach.

Marlena and Adam have conducted interviews with marketing managers and assistants, webmasters, graphic designers, and sales professionals at companies that have already used or are likely to use Reach. After their research and a few intense whiteboard sessions, they identify patterns that help them flesh out their personas. Now Marlena and Adam have to check in with the heads of product management and engineering and with the CEO of DigitalMail before they can start designing for their personas.

Use structure to help others reach your conclusions
In order to get her co-workers on board, Marlena knows she needs to carefully manage their first impressions. Having had some experience sharing personas before, she knows she has to provide detailed written documentation for those who don’t attend the meeting and for later reference. All the design documents she will produce from this point forward will incorporate the personas to help focus the design

Audiences do not generally understand persona designations until the entire persona set is explained. Seeing them all on one page to compare goals and summary information is key, so the audience can be confident that all bases are covered.

Marlena starts by documenting their research. She then creates about a page for each persona, including all the information mentioned above (name, goals, age, background story, etc.) except the persona’s designation. Instead, she uses the designation to order the persona pages with the primary being appearing on the first page of personas section.

After her personas section, she adds the persona designations and the reasoning behind the status designations. Marlena also adds a section with summary information (picture, goals, name) about each persona, so readers can compare and contrast the personas. Finally, she adds a page containing a diagram that shows how each persona is involved in using the product.

Depending on your project and research, you’ll uncover characteristics of your personas that are relevant to the design of the product. Each persona may have a different information—sharing need or a particular role in relation to the product (e.g. consumer, creator or approver of content).

Marlena and Adam discover a common process among their interviewees—marketing usually initiates the email campaign; the graphic designer creates the design and integrates the marketing copy; and the webmaster checks the HTML. At various points in the process, multiple people will use Reach for particular tasks. This is central to the design, therefore, Marlena creates a diagram that communicates this key distinction. She also mentions it in the narrative about each persona.

Marlena then creates her PowerPoint by simply summarizing her document. She structures the information in her presentation in the same order as her documentation, so her audience can follow the same process she followed and reach the same conclusions.

She’s found that audiences do not generally understand persona designations until she explains the entire persona set. Seeing them all on one page to compare goals and summary information is key, so the audience can be confident that all bases are covered. Marlena wants her personas to be representative of the actual patterns in her user population, and conveyed succinctly so they are useful.

Thanks to Marlena’s meticulous work habits and Adam’s presentation skills, the meeting with their executives goes well. With minor adjustments, management agreed that they should design for the primary persona while keeping in mind the needs of the secondaries. Everyone who is working on the next version of Reach will read the deliverables, and Marlena and Adam will give another presentation to a wider audience of team members. They also suggested to the executives that they start using the names of the personas instead of the word “user” to avoid miscommunications.

Marlena and Adam are satisfied, but they know there will be more challenges to understanding the personas as they begin to do more detailed work with coworkers, so they do some more documentation work.

Know, sell, use and help others use your personas
Four weeks later, after Marlena and Adam have reached some high-level conclusions about how the product will function, they schedule a meeting with key engineers to verify the feasibility of their design. They want engineering to know the skill sets needed to implement the design so that they can plan for additional hiring, skills development and resource allocation.

To provide quick reminders to colleagues who aren’t so versed in the personas, Marlena created a persona “placemat”—a laminated sheet that contains the same summary information and diagram found in the last two pages of her persona deliverable: the goals, names, and pictures. She easily created the placemat by tweaking what she already had in the persona document.

They start the meeting by reiterating the primary persona (Kathy, the marketing manager) as well as the secondaries (Charles, the graphic designer, and Patrick, the webmaster). Tom, an interface engineer, shows up 10 minutes late, just as Marlena is discussing the preview functionality she foresees needing.

Marlena: Kathy wants to preview the message in Outlook. If there are any potential compatibility problems she wants to know, but she really doesn’t care what they are. Patrick will want to do the same with Outlook and all the other major mail clients. He will also want to know specifically what the compatibility problems are and even tips on how to fix them if the product can’t just do it automatically.
Tom: Wait. Which one is Patrick again? And why won’t Kathy want to see what exactly is wrong and how to fix it?

Marlena knows she has about 15 seconds to explain who Patrick is and maybe 45 more seconds to explain why Kathy doesn’t want all that functionality before Tom and the other engineers get impatient. Marlena takes out a laminated persona placemat and hands one to Tom, then hands other copies to the rest of the attendees.

Marlena: Patrick is the 26-year old webmaster. He’s responsible for making sure the emails reach and are readable by all the recipients. On the placemat you’ll see two of his goals are “Be knowledgeable” and “Make sure code doesn’t break.”
Tom: (looking back and forth between the placemat and Marlena) Oh… right and why doesn’t Kathy care?
Marlena: Well, Kathy, our primary persona, is the marketing manager and she mainly cares about the message contents and design. She just wants to insure her marketing messages are conveyed. She is busy and depends on Patrick for technical concerns. If you turn over the placemat, you’ll see a process diagram showing that she barely previews. Patrick is mainly involved in the tail end of the process.
Tom: Oh, okay. Uhm, sorry for interrupting. Go on.

Marlena knew from experience that even though people may read (or skim) the documentation, they need quick reminders of the personas and the relevancy of their stories. After all, she and Adam spend their entire days thinking about what Kathy, Charles and Patrick want and how to give it to them. (In fact, Marlena hasn’t yet shared with Adam that she had a dream about Patrick the night before.)

Even though the placemats provide a good reminder, after this meeting, she and Adam realize they need to do more. They are going to create posters with pictures and summary information of the primary and secondaries and they will be hung around the office.

Marlena offered these other tips for documenting and sharing your personas:

  • Tie your personas to your research, showing your audience that you’ve personified the patterns you’ve found because that makes sense for design.
  • Less is more. Get to the heart of the persona.
  • When presenting, talking about your personas, or referring to them in writing, communicate as though they are real people, people that you know. Express it like you are talking about a friend. Remember, you want your audience to like (though not necessarily agree with) the personas. There is little motivation to try to understand or design for people you hate.
  • Reuse persona pictures often—people feel connected to them and remember faces easily.
  • In your persona description, focus on their regular daily activities.
  • Be creative in the ways you communicate them and use multiple methods—posters, t-shirts and sock puppets have been known to work—but don’t get too cute.
  • Use good communication guidelines, for example make the primary persona picture largest.

Documenting personas keeps your design on track
Now that you have a better idea of how to document your personas, remember that documentation isn’t the point of your work. It is simply an important step on the way to designing and building better products. Also, what is described above is a cookie-cutter approach towards documenting your personas. Each project will have different documentation requirements to make different points, but the underlying principles stay the same. As a designer, it is up to you to determine how much persona detail is sufficient and how to set up the personas and their presentation so that you pre-empt confusion and questions. You also need to provide a quick way to familiarize newcomers to the persona set, and find ways for your colleagues and clients to keep focused on the personas throughout the project.

For More Information:

The ideas above were impressed upon Elan when he used to work for Cooper Interaction Design. These days he consults independently (though with other former Cooperistas) for companies that don’t have the liberty to screw up their products. When he’s not designing, he can be found playing volleyball, improvising or improvising as a volleyball (you try that sometime)….