Ever since Alan Cooper’s 1999 book The Inmates are Running The Asylum was published, everyone is mad for personas. They’ve permeated the highest and deepest levels of organizations, and have become a standard interaction design tool. Whole projects are now built around creating them, and there’s a feeling that once you get a half dozen or so, your design problems will be solved. Presumably, your personas solve them for you.
In case you haven’t been in the same design and business bubble that I’ve been living in ‘lo these many years, personas are a documented set of archetypal users who are involved with a product, typically the product’s users. Each persona has a name and a picture. They’re supposed to give designers a sense that they are designing for specific people, not just generic, ill-defined users.
Done well, this is exactly what personas do. The problem is, most teams build personas from the wrong kind of user information, or worse, base them on assumptions. It’s no surprise that a Web search for personas brings up an amazing variety of persona sets, and most of them are terrible.
Fact or Fiction
The main cause of this mess is that half of the personas out there are entirely made up, with no user research to back them. In most cases, no one on the design team has talked directly to users to find out who they are, so designers come up with an idea of a user type. The resulting personas are like the designer’s imaginary friends.
Without any research to back assumptions, it’s easy to end up with a product built for what designers think the users are like, rather than what the users really are like. It’s the difference between reading about someone and actually meeting them, between fantasy and reality. The best personas are really conceptual models, which help you to digest the user research in a coherent way. They put a name and face to an observed pattern of behavior.
The only time it’s useful to do personas before research is as a check of the design team’s assumptions, which you can test and revise later. It can get them to stop thinking about a monolithic block of “users” and start thinking about “the guy who searches in that weird way.”
Even if the assumptions prove to be wrong, these “pre-personas” are worthwhile as a team-building exercise. However, if team building isn’t your objective, you’ll want to approach personas differently.
Solid personas can be incredibly helpful. Several years ago, Schwab redesigned its site based on three primary personas: the learner, the active trader, and the serious investor. Apple has had some great successes designing for an aesthete persona who demands that things look clean and work smoothly. (The persona’s name is Steve.)
However, the greatest pitfall with personas is that most of them focus on the wrong things. Differences between personas are often chosen based on demographics and preferences, not the things that really matter, like goals, motivations, and behaviors.
To whit: John Persona is a 35-year-old male living in London. He likes Benny Hill and lager. Susan Persona is a 22-year-old female who lives in Peoria and enjoys casual sex. Ok, that’s interesting information and all, but what does it really tell us? It’s tough to translate preferences into designs; indeed, they can lead to a paralysis spiral. (John likes blue. But Susan likes green! What color will we choose?) We shouldn’t be slaves to our personas. They are tools; useful when appropriate, worthless when they are not.
The only time demographics really matter for personas is when those demographics directly affect user behavior. A 13 year old will probably use a product differently than an 83 year old. A rural peat farmer in Ireland might use a product differently than a Korean financial analyst in Seoul. But maybe not. The demographics may not matter at all; in fact, they could limit and hinder your personas. Using demographics to demarcate personas doesn’t scale well; for products with millions of users, you could end up with hundreds of personas, and such a large set is essentially useless.
What if I’m a disabled, Native American farmer?
It’s easy to see the surface elements that we’ve used throughout history to separate and shallowly categorize one another — race, age, where we live, what we like to eat, and so forth. It’s much harder to uncover what binds us together: our shared goals, motivations, and behaviors. But to make sound personas, this is exactly what we must observe and record.
The differences between personas must be based on these deeper issues — what people do (actions or projected actions), and why they do them (goals and motivations) — and not as much on who people are. It’s not that knowing who people are isn’t important, it just isn’t as important for personas.
Use ‘Em or Lose ‘Em
There’s little sense in having a set of personas around if you don’t beat them against actual projects. Once you’ve developed a persona set, the team needs to use them, by running them through scenarios of use and testing features both for appropriateness and for utility. Would this persona do this task? Could this persona do this task as it is designed?
You can also use personas to set priorities. A persona that represents a majority of a product’s users may not be the user that the organization values the most; other personas might make the organization more money, be more involved, use more features, and so on. Organizations can and should use personas to make strategic decisions.
While I find personas helpful, they aren’t for everyone. For some, they form an artificial barrier between the designer’s product and its users. Some projects, especially smaller ones, may not warrant a full set of personas. But if you base your personas on research and focus on the right characteristics, you can reclaim them as a valuable tool.