How Pragmatic Personas Help You Understand Your End-User

A "persona," when used in software development, is a simple, valuable, concrete example user of your software. Here, I explain how to create pragmatic personas quickly.

You are Not Your User
"You are not your user" is the cautionary mantra used by people who do user-centered design work. It's a good one, because it's so easy to ask yourself what you would like when making choices about features to put in a product, as well how those features look and behave. "Self-substitution" is the most common trap we fall into when making software functionality and UI decisions.

The next most common trap is simply asking users what features they want and building them. That story often ends with users' getting what they asked for and still not being satisfied with the product. The software team then grumpily complains that the users "always change their mind" or "never know what they want." If your user community is sufficiently large or diverse, you're likely to get many contradictory messages when asking users what they want.

Ultimately, we as software professionals, equipped with an understanding of what software can do and how to build it, should be making some good decisions about what software to build based on understanding what users really value.

That's where the idea of a persona comes in.

A persona is an example of a specific user written into a document whom those making choices about the software can use to evaluate decisions about software features. It's not based on one user, but a synthesis of information about many users. So, even though a persona may look like it's describing a real person, that person is fictitious. Having this fictitious person helps us not get hung up on ourselves as the user or any single user's opinions. It's a neutral "design target"-the person we're trying to satisfy. The hope is that making this persona happy will result in making all people like the persona happy.

While it is true that personas should be built on rigorous research, this notion is exactly what stopped me from making good use of personas for many years. I used to get hung up on the term "research" because it sounds science-y, and I'm not. I later found that the great deal of time I generally spent talking with users and watching them work counts as research. There are more rigorous ways to plan, execute, and make sense of research results—all ways are valuable—but, at minimum, it's good to observe users first hand.

The second thing I got hung up on was building the personas based on research that some teams didn't have. We had some direct experience with users, but it wasn't written down in any useful way. It wasn't until I worked with my friend David Hussman that I stopped questioning if I was using personas correctly and started having good team conversations about users. David calls his approach to personas "pragmatic personas," and now so do I.

How to Make Pragmatic Personas
1. Start by Naming Types of Users
When we talk about users of business systems, it's common to list their job titles. When using use cases, we might name users as "actors." Some folks use "user roles" to describe different ways to name users. There's a soup of ways to name people, and they're all right.

Titles name the relationship between a person and something else. A job title names the relationship you have with your employer or profession. "Father" names the relationship I have with my daughters. "Frequent flyer" names the relationship I have with my airlines. It's fun to think about the different ways we refer to people, but don't get caught up in doing it "right."

In your small group, quickly brainstorm types of users for your system. If you've got a bunch of types, then group similar types and rename the group with a new, single term. While there's no right way to name them, looking for names that describe the users' relationships with your product is a good starting point.

For a typical software product, I usually expect to see three to ten types of users. Rank your user types by asking, "If the system were to be successful, which user type(s) is it most critical to please?"

2. Profile a User
Start with one of the critical user types that must be satisfied and add some information. I use the word "profile" to describe lots of general information we could collect about a type of user. Start by profiling quickly with your group, using the information you know. Most folks are surprised by how much they do know, and everyone has some gaps where they need to learn more. Discussing it gets it on the table. Make notes on a whiteboard or flipchart paper while you do this, so everyone in your group can see.

I use the general categories of information below as a starting point for discussion. This isn't a template, so don't trying to fill it out like one. You might find some of this information isn't relevant to your product, and you might discover information you should be discussing that's not listed here.

General stuff about these kinds of people:

• Number of people of this type: Is it a couple, dozens, hundreds, or thousands? Knowing this helps you get a feel for the impact of your decisions about this user and lets you guess at the diversity of the community.
• Technology skills: How good are they at using computers and software?
• Subject matter expertise: If you were a non-profit organization building an application to collect donations, then you might ask how much they know about donating, charitable organizations, or the cause to which they're donating. What subject matter expertise is relevant for your application?
• Relevant demographics: These are items such as ages, genders, and professions.

About their pains and goals, and what makes them want to use this software:

• What makes them happy? If I'm interviewing potential users for a piece of software, I always ask them to tell me about a good day—a day when using this product or one like it went well. From that conversation you'll usually get a good idea of why software like this is valuable to them. For someone donating money to a charitable organization, he might describe a situation where he found a small non-profit that he really felt good about helping, and thus felt his donation made a difference.
• What makes them mad? These are the sorts of things they're trying to avoid—things that can go wrong with your type of product, or things they're trying to avoid by using your product.

About their use of software:

• What are the basic things for which they're likely to use the software?
• Where are they likely to be when using the software?
• How often are they likely to use the software?
• Who are the other people with whom they work or collaborate when using the software?
• What other software or non-software tools are they likely to use with your software or instead of your software?

3. Build Your Pragmatic Persona
Now the fun part. Put your best novelist or screenwriter hat on. It's time to tie all the information together into a tangible character.

Figure 1

The sample persona in figure 1 is for Chuck the Casual Web Surfer, a persona a team and I put together for Mano a Mano, a nonprofit organization building applications to accept online donations.

Name your persona. I like to make the first name of the persona start with the same later as the user type—like Chuck the Casual Web Surfer. Write the persona's name and role clearly at the top.

Give your persona a face. I like to draw simple pictures. But, I sometimes cheat by pulling pictures from magazines, finding Creative Commons-licensed pictures on Flickr, or buying them from iStockPhoto. Don't skip this step. You'll be surprised how much easier it is to talk about your persona when you can look him in the face.

Put your persona in front of your software. To the right of Chuck's picture is the situation in which we've put Chuck. He's just received a tweet from a friend about Mano a Mano. Following a link will take him to the website.

Tell us about your persona. You don't have much space to write here, so don't waste it by telling us about your persona's dog or hobbies—they don't matter. Tell us things about your persona that will help us make decisions about the software. For Chuck, we noted that "he wants to feel like his small contribution matters." We discussed the fact that he didn't have a lot of money to give and he hates giving it to a large organization, believing that his money will go to buy coffee for the phone solicitors trying to collect even more money. Our single, bulleted statement sums up these sentiments.

Now tell us about the product implications. This is where we start to see why the persona is relevant to the product. For each bit of information you write down about your persona, consider how you'd build the product differently as a result. When we considered that Chuck wanted his donation to matter, we decided that it meant our product should explicitly show what a small donation does.

Figure 2

Now What?
For our group at Mano a Mano, the first application we built was for the iPhone. It was a simple application that allows people to donate money. This little insight about letting people see the value of their donation caused the team to include the "support a cause" section on the donation page (see figure 2). In it were choices like "Help ship $1,500 worth of medical supplies" and "Purchase and plant five fruit trees." These are pretty specific things that help people like Chuck feel like a small amount of money really does result in something valuable to people in Bolivia and that the people at Mano a Mano helped.

Curiously, in the final application, most of the donations came through as general donations. According to Nate from Mano a Mano: "What I've found is that people are more likely to give if there are specific options available, e.g., pay the salary of a nurse, but then still tend to give undesignated donations. I have a few studies laying around that reach that conclusion as well." The feature gave Mano a Mano a chance to tell people about the specific things they were doing. People using the product found it fun to look over choices about how their money would be used, more fun than reading a big block of text. The insight that resulted in the feature choices came from thinking and talking about what was important to the people using this software. It was a bonus that later research supported the decision.

Try this with your product, but be careful. You're likely to find some interesting things your product could or should be doing for its users.

For more information:

• Personas were first described in The Inmates Are Running the Asylum, by Alan Cooper, published by Sams in 1999.
• Personas are more thoroughly described in About Face 3: The Essentials of Interaction Design, by Cooper, Reimann, and Cronin, published by Wily in 2007.
• Beauty Is in the Eye of the Beholder
• Write a Blockbuster Using User Scenarios
• IEEE Software: Understanding User-centricity