When I joined Microsoft in 2000, personas were hot. They were everywhere and Alan Cooper’s The Inmates are Running the Asylum was the most talked about UX design book. The persona posters were on all the walls. There were even persona ice cream socials.
By the time I left Microsoft in 2010, the Windows 7 team had abandoned personas. User researchers would only whisper the word in public. I met with a group forming a panel discussion called Are personas dead? As I recall, John Pruitt and I were the only ones taking the pro-persona side. Everyone else had abandoned them.
I’m still a strong believer in personas (but with a twist, as you will soon see). But what happened to make personas acceptance fall so far so fast?
A persona is a fake person constructed with real user research data to represent a class of target users. Designing for users is, after all, the essential foundation of user-centered design, so it makes sense to have a tool to help teams define their targets. You can’t hit a target if you don’t have one.
The problem that personas solve is that without clear targets, everyone on the team forms their own independent picture of the target user. And somehow, those target users always seem remarkably similar to the people on the team itself…or perhaps their mothers. Furthermore, that target user may change from feature to feature, or even from discussion to discussion. Ultimately, without a clear definition, target users are basically whatever the person speaking wants them to be at the time. Not a very solid foundation.
This problem is known as the elastic user. Personas are a tool to define and communicate a clear, fixed target user—building a strong foundation for user centered design.
In practice, personas didn’t achieve that goal. User researchers would spend a significant amount of time gathering data about target users, defining personas to represent them, and crafting detailed persona documents.
Design teams would then use those personas by learning the persona names, their high level descriptions, and…well, that’s about it. So for Windows Vista, Abby was the soccer mom and she had a teenage son named Toby. Few people knew much more. Instead of having discussions about generic users, design teams would discuss what Abby and Toby wanted, but without regard to any facts in those detailed documents that the user researchers so diligently compiled.
In practice, “using personas” often boiled down to replacing an elastic user with an equally elastic user with a very specific first name. Instead, personas should have been about creating user models for a decision making framework using a well understood process. Mindlessly substituting “the user” with “Abby” wasn’t really a big step forward in user-centered design.
User researchers compiled these detailed persona documents because that’s what Alan Cooper recommended in The Inmates are Running the Asylum. The goal was to make the personas feel real—so that you could walk a mile in their shoes.
An unfortunate fact of life: People don’t read large documents. So nobody really knew any facts about the personas. And even if they did, relevant facts for specific decisions were often missing. For example, if you were designing a search feature, chances are the long persona document would provide no useful information about the user’s knowledge, habits, or preferences about search.
Instead of creating a long personal life story, why not create a short user model that focuses only on the details that affect design decisions at hand? Better to have a few relevant facts that everybody knows.
In Design scenarios—and how thrilled users ruin them, I gave a scenario for Joe “the shipping guy,” who needs to access Snarfbladt info using a BladtBlaster device. Let’s make a persona for Joe.
To help you see the value of personas, please read the scenario (the good example at the end, not the bad one) before continuing, and put some thought into designing a solution.
Now a traditional persona might be several pages long and give all kinds of personal and professional details about Joe. Much of that detail will be completely irrelevant to the design problem at hand—what I like to call the “four Ks”: details like koffee, kids, kats, and kars. Frankly my dear, I don’t give a damn.
I believe the long story of largely irrelevant details is what ruins traditional personas. So instead, let’s get right to the point with facts about Joe that are relevant to the scenario:
That’s it! That’s all we need! This user model contains facts about Joe and his relationship to the product that are relevant to making design decisions. No life story here. No mile in Joe’s shoes.
I don’t know about you, but I now have a much better understanding of Joe and can make better design decisions for Joe, more quickly and confidently. For example, I know that a good design can optimize for right-handed users, but not in a way that harms left-handed users. To simplify the UI, I know that a good design will focus on doing the top 6 tasks efficiently, in a way that doesn’t require memorization. I know that a good design should have buttons large enough for use with a gloved thumb. And since Joe has basic computer literacy, the UI can have basic computer terms (like save or network), but should avoid advanced ones (like virtual or IP address).
Given several different design alternatives, I now know what Joe is going to want. By documenting this persona, everyone on the team will be designing for the same target. If someone makes an assertion about Joe that’s not in the model, we can easily flag it and either validate it or reject it.
The elastic user problem is solved!
If you do only five things:
1) Keep it simple and focused. Focus the persona on the design task at hand, not the target user’s entire life story. See what you can do with one page and at most two hours, using the facts that you already know. Anything beyond that is detail you won’t need anyway.
2) Make a user model, not a life story. Just give that specific facts to help make good decisions. If there’s not a potential design decision behind the detail, don’t include it. Don’t walk a mile in the person’s shoes. If your persona looks like an online dating profile, you are doing it wrong.
3) Use them when making decisions! If you aren’t actively using your models when making design decisions, you’re doing it wrong. And by “actively using”, I mean applying the model not making arbitrary assertions. Flag assertions that are outside the model and validate them.
4) Train your team to use a simple process. Give some simple training on how to use personas productively. Don’t assume that people will figure it out on their own—my experience shows that they won’t.
5) Be mindful of politics. If you can’t use personas for political reasons, just call them user models. If it helps, consider calling them “agile user models.” Most likely nobody will catch on.
Coda: It is not my intention to downplay the role of user research in this process. If your team has user researchers, of course they will own and drive this effort, using a far more substantial process than I describe here. Still, experienced user researchers will vouch for the importance of concise communication for their effectiveness within a team. Ease of use equals use, and that applies to design techniques. So keep your personas simple and focused.
Joe works at a Fortune 500 company. On occasion, he needs to access Snarfbladt info for his customers. He discovered that the BladtBlaster 2000 allows him to request access to Snarfbladts from the BladtBlaster website. Joe is thrilled.
What’s wrong with this scenario? In short, everything. It’s not really a design scenario but a thinly veiled feature advertisement. Its only purpose is for the feature owner to say “somewhere out there is a customer who needs Snarfbladt info, so please don’t cut my feature.” Beyond that, it accomplishes nothing.
Unfortunately, most scenarios I’ve seen in practice follow this basic template.
New! To learn more, join our first virtual UX design class on scenarios on September 10, 2015. For more information and to register, check Effective Scenarios.
To better understand the problems with this scenario, let’s quickly review the history of scenario-based design. In the early days of the software business, there was very little software with very little capability, so there was a feature arms race. Feature-based design boils down to creating products with long feature lists and the product with the longest list wins.
The problem with this approach is that user don’t do features, they do tasks. So while having a long list of features might initially appear impressive, having many complex, poorly coordinated features doesn’t help users get their work done. As an alternative, task-based design is all about helping users get their work done, with efficient, well designed end-to-end tasks.
Task-based design sounds pretty good, so what’s the problem? The problem is that great user experiences are designed for their target users and task-based design doesn’t consider target users at all. Add the tendency for people to design for themselves, and task-based design often leads to designs that developers love but customers hate.
Great design requires designing for a clear target. Enter scenario-based design. What’s a scenario?
A scenario describes a specific target user trying to achieve a specific goal or task in a specific context or environment.
Or more concisely:
Scenario = user + task + environment
So, the difference between scenario- and task-based design is the focus on users and their environment. Good designs are useful, but great designs are usable and desirable by providing what users need. Design scenarios are about excellence, not acceptability. You can get to acceptable through good task design.
Best of all, a solid set of scenarios creates a decision making framework. Brainstorming? Review your scenarios to give you inspiration. Choosing between two alternatives? Use the scenarios to help you decide. If you aren’t constantly referring to your scenarios throughout the design process, you’re doing it wrong.
What’s wrong with the original scenario? Let’s analyze each sentence:
Joe works at a Fortune 500 company. A meaningless attempt at providing a description of the user and environment. This tells you nothing about Joe—he could be anybody doing anything anywhere. Not a clear target.
On occasion, he needs to access Snarfbladt info for his customers. At least we have a goal/task.
He discovered that the BladtBlaster 2000 allows him to request access to Snarfbladts from the BladtBlaster website. Here’s the advertisement that suggests why Joe wants the feature. But there’s a first degree scenario-writing crime here: the scenario provides the solution. Who says Joe wants to request access from the BladtBlaster website? Aren’t there other possible solutions? By putting the solution in the scenario, no other solution is possible. (Unless, of course, you ignore the scenario.)
Joe is thrilled. Another first degree scenario-writing crime. See why below.
It might seem like a small detail, but ending a scenario with a thrilled user completely undermines the scenario. Why? Consider Everett’s Rule of Scenario-Based Design:
If success is shipping a feature, you aren’t doing scenario-based design! Rather, you’re doing feature-based design.
Instead of using scenario-based design to figure out how to thrill Joe, we have guaranteed “success” by simply shipping the feature.
But who says Joe is really thrilled? What specifically about the design is going to thrill him? That information should be in the scenario, but it’s not. By adding those three little words, we’ve devolved all the way back to feature-based design. We’re now doing scenario-based design in name only.
Joe works in the shipping department of a large company, where he is responsible for the pickup and delivery of about 200 packages a day across 10 buildings. To maintain his aggressive schedule, he is always on the move, either with a cart or carrying a few packages underarm.
Between deliveries, Joe occasionally needs to access Snarfbladt info for his customers. The BladtBlaster 2000 allows him to access the Snarfbladts info instantly. Best of all, he can do it while walking, using a single hand with only three thumb strokes or less.
While the new scenario doesn’t have a specific solution or tell us that Joe is thrilled, we now have a pretty clear picture to help us visualize what might thrill him (as well as what might frustrate him.) It’s now up to us to design a solution that nails this scenario for Joe.
If you do only one thing:
Write scenarios that can be used as a decision-making framework. Provide details about users, goals, tasks, and environment. Don’t provide a solution because figuring out the best solution is the entire point of the scenario. And don’t declare that the user is thrilled because a feature exists. Provide the details for what it would take to thrill the user instead.
Congratulations! By reading this post, you have mastered about one hundredth of what you would learn by taking User Experience Design Essentials. What to learn more? Sign up now!
Know your users, design for your users… right?
Living near the Canadian border, I’ve long had access to Canadian broadcasting and greatly prefer their coverage over ours. Apparently, I’m not the only one. I took a short winter vacation at Stowe, VT and of the Olympic coverage that I saw displayed in public, the score was CTV 6, USA 1, NBC 0. Not one set showed NBC!
Before the games, I had two predictions about NBC’s coverage. First, I expected to see a lot of Michael Phelps as a cheap ratings ploy (sorry guys, wrong Olympics!) Second, I expected to not see any significant coverage for events that 1) are unpopular with Americans, 2) didn’t have any American medal contenders, and 3) don’t immediately appear exciting or dangerous. In other words, no cross-country skiing and for sure no curling. I nailed the first prediction but was pleasantly surprised to see NBC cover entire cross-country skiing events that had no American contenders. (Didn’t see any curling though).
As a user centered design challenge, this presents an interesting question: what’s wrong with giving people what they want? If most viewers aren’t interested in cross-country skiing, wouldn’t user centered design suggest that NBC would be right to not include it? (Let’s assume for a moment that user centered design is what NBC tried to do, as opposed to, say, maximizing advertising revenue.) NBC does extensive viewer research and their programming choices reflect their data, so we should love the results based on our own input. Why then did so many people prefer CTV’s coverage?
The answer, I believe, is that giving people what they ask for can lead to good design, but it doesn’t guarantee great design. You can be good by following your users, but to be great, you have to lead them. In short, great design often requires courage.
Following your users is safe design. It requires research, analysis, and process, but little more. By contrast, courageous design is risky. It requires insight, creativity, and boldness to go beyond the data. Courageous design requires saying “we’re going to give you something you didn’t ask for, but we believe you might like anyway.” This is hard to do well because you have to discover desires that people don’t even know that they have. And if you fail, you fail big. You might be leading your customers to some new, exciting place…or maybe somewhere they have no desire to go.
Why is this important? Well, nobody asked Apple for an iPhone. Nobody asked for Facebook. For sure nobody asked for Twitter. Revolutionary innovation requires courage. You can’t lead by following.
If you do only one thing: Do the best user research you can, but be willing to see beyond the data.