Personas: user descriptions + task scenarios
We frequently talk about “the user” when we design new software or hardware, but that’s too general. It’s better to discuss real users and how they would react to your product. For example, "How do we help Fred the Head Chef update a week's worth of menus more quickly?" By doing this, we’re more likely to make valid and consistent decisions.
To do this, we develop personas – descriptions of typical users along with stories about how they would use the product to meet their goals. The personas are written in prose form to bring them to life.
Building a persona
Let's say we're defining a new email feature in a suite of products for non-technical computer users. After reviewing business goals, we would go out and interview a variety of potential users and put them into categories based on behavior with the proposed system.
We might have two main user categories. Let's say that one is represented by Fred Fish, Director of Food Services. Fred uses a computer because he has to, not because he wants to. That's an important consideration, especially because everyone on the development team probably uses email all day long. The person helps us remember how this user type is different from another one, and different from ourselves.
How do we use personas?
Before designing a new feature, we ask important user and business questions:
Will it meet the goals of our personas?
Is it important enough to these users that it's worth the development cost?
Rather than considering what we think of a feature, or what "the user" would think of it, we can use the personas to ask about specific users and their goals.
Personas are useful for all members of the team. Marketing, QA, documentation and sales can all use them to focus their work on the same set of users.
Benefits of using personas
They help the entire team in a variety of ways:
Understanding the user Research into types of users and their needs is needed to complete scenarios. Knowing who the users are and what they understand about the task helps us design a product they can use. This is a good way for new team members (including consultants) to learn about the product, the business and the users.
Clarifying assumptions People don't always verbalize their assumptions. Written scenarios help team members share and formalize assumptions so there are fewer surprises later. Group Design Workshops are good for this, too.
Fully exploring the design Scenarios provide a vehicle for exploring all of the important aspects of the interface.
Providing a context for reviewers Detailed scenarios provide a context for understanding the features of interface specs, functional specs and other project documents.
Helping other project tasks Scenarios represent the important tasks that major classes of users are expected to perform. They are useful in usability testing, documentation, QA and others areas.
Examples beyond software design
This is not just a software technique, it's useful in any product or service. Examples from the popular press and beyond:
Best Buy stores have "begun to woo a roster of shopper profiles, each given a name: Buzz (the young tech enthusiast), Barry (the wealthy professional man), Ray (the family man) and, especially, Jill [a soccer-mom type who is the main shopper for the family but usually avoids electronics stores]" (from the Washington Post).
Adidas uses scenarios to design sneakers, as described in The New York Times Magazine. Here's an example from that article: " 'We sell well right now with Gearhead, Core Letterman and Popgirl,' says Lietdtke... Popgirl loves the shell-toe lowtops that Run-DMC once made famous; Gearhead and Core Letterman like Adidas's performance running shoes. 'We've also lately made a good run at Fastidious Eclectus,' he says. This type likes reissued 70's Addidas classics."
Other examples The book "Just Ask: Integrating Accessibility Throughout Design" includes personas of handicapped users, a topic that's important to include in your project.
More information: The paper on navigation in web applications uses scenarios to describe differences between Web and desktop applications.
© Copyright 1996-2013, Interaction Design, Inc.