Here’s the spoiler: When a persona lacks specificity, it ceases to be useful.
What do you think of when you hear the word “persona”? Do you think of the literary use – a character in a work of fiction like a novel or play? Do you think of design personas reminiscent of Alan Cooper? A marketing slide with a picture of a very nondescript person of unknown ethnic origins that could maybe represent a broad range of demographics? Human-fueled, voice-filled stories? Something completely different?
Chances are, you bring a certain set of expectations based on prior experience. This is good. Personas take many forms, for many purposes. Our intention is not to disparage other types of personas. But instead to identify a few different types, and make a case for why we find Use-Case Persona’s to be particularly useful for the majority of our creative problem solving work.
“All models are wrong, but some are useful”
George P. Box
Before we get too far, it may be helpful to clarify a few definitions:
User Type: describes permissions and access given to different roles within a system.
Example: Sales Personnel, Back Office Teams and Customers can each be separate User Types with different tasks available for them to use within a system. Identifying the separate contributions and functions needed by each User Type is useful in the design process so that the right permissions and restrictions can be in place. It doesn’t typically need to be much more than that… for User Types.
User Persona: approximates a description of the people that use your product.
User Personas represent a specific user behavioral patterns in their purchasing decisions, use of technology or products, customer service preferences, lifestyle choices, and the like. This is perhaps the most common persona varietal. Which makes it the hardest to define.
User Personas can be useful tools when they’re founded in research (not pieced together by imagination and guts) and when they provide enough context to make important decisions with minimal guesswork. However, in a lot of instances, even a well researched User Persona provides only a broad glimpse at the users, leaving the design team to form guesses based on what features they think a man between the ages of 35-45 with above average income and education would want.
Customer / Buyer Persona: describes the decision maker(s) responsible for purchase.
Example: A children’s book. Who would be the buyer? And who would be the user? Unlike a User Persona, the Customer / Buyer Persona does not always represent the people using the product. It can. But its primary task is to identify the motivations of the buyer, or in many cases, a team of buyers. This type of persona is especially helpful in B2B scenarios when two distinct sets of motivations need to be clearly identified so that the desires of the buyer and needs of the end-user can each be considered.
Use-Case Persona: describes a specific user need within a specific situation.
Example: Rollaboard luggage. Now ubiquitous, the rollaboard suitcase was first designed for a very specific user, a pilot, who was having a specific problem, dragging his luggage on and off planes and carrying it from gate to gate. He found the invention to be useful, personally. Then he started making it available to other pilots and flight crews.
Another example: The Sonos Playbase. As TVs became flatter and easier to wall-mount, speaker designs became flatter and wall-mountable too. It was commonly assumed that soundbars could mount up with the TV to provide better sound than the built in TV speakers. But… Sonos conducted some research and discovered that 70% of flat screen TVs don’t actually hang on the wall. And the slimmer profiles of flat screen TVs and soundbar speakers made stacking a speaker on top of a TV nearly impossible. It was this specific insight about the use-case, that led the team at Sonos to develop a product that could sit between a piece of furniture and the TV.
Because the Use-Case Persona provides situational awareness of a very specific user need, it’s becomes much easier to filter important decisions about the project with greater empathy for the user’s perspective.
The Average Problem
When faced with the question of who to base a persona upon, the common temptation is to be a completionist and capture all of the data in one place for all current customers and all potential prospects no matter how massive that scale may be. The logic follows that we don’t want to only make one sale to Bob… Right? We want to make all the sales. To all the Bobs. And to everyone else like Bob. So instead of basing a persona on just Bob alone, we rely upon averages to describe all of the mass-potential demographically (and if the data has been captured, even psychographically). And that is how we might end up with something like this randomly selected Google Image Search result for bad personas…
But what’s wrong with either of those?
It seems right to think that making design decisions based on averages should work out great. Right? After all, if it works for the many it should also work for the few. But this approach isn’t quite right. Despite how right it feels.
“Consider the case of the statistician who drowns while fording a river that he calculates is, on average, three feet deep. If he were alive to tell the tale, he would expound on the “flaw of averages,” which states, simply, that plans based on assumptions about average conditions usually go wrong. This basic but almost always unseen flaw shows up everywhere in business, distorting accounts, undermining forecasts, and dooming apparently well-considered projects to disappointing results” – Sam Savage for Harvard Business Review
As another example, Todd Rose tells a great story of how the U.S. Air Force decided to ban the average. At the time, there were some 4,000 pilots. And the cockpits were designed to fit the average pilot across 140 separate measures of height, shoulder width, etc. But, amazingly not a single pilot among the 4,000 actually fit the average measurements. By attempting to design a cockpit for the average, the design actually failed to fit a single pilot.
Link to Todd Rose’s TED talk for the rest of the story: https://www.youtube.com/watch?v=4eBmyttcfU4
Ban the average. Be specific.
The profiles above list Goals and Challenges / How We Can Help and Buying Motivations / Buying Concerns. This creates a more complete profile than just demographic information. But they still speak in vague generalities. To be of more use for design purposes, a persona should help you say “no” to potential solutions, and – more importantly – identify which problems require solutions.
Design for one person
“The more specific we make our personas, the more effective they are as design tools. That’s because personas lose elasticity as they become specific. For example, we don’t just say that Emilee uses business software. We say that Emilee uses WordPerfect version 5.1 to write letters to Gramma. We don’t just let Emilee drive to work. We give her a dark-blue 1991 Toyota Camry, with a gray plastic kid’s seat strapped into the back and an ugly scrape on the rear bumper. We don’t just let her go to work, we give her a job as…” – Joel Marsh, UX for Beginners, A Crash Course in 100 Short Lessons
Personas should be based on primary and secondary research, such as stakeholder surveys, empathy maps, user-tests and in-depth user interviews AND NOT on gut-feel guesswork and generalized-assumptions. Even in the rare case that you find yourself to be among the intended end-users, it’s very likely that you’ll be cursed with more background knowledge than other users. Reduce intellectual baggage. Remember, subject matter experts bring a different perspective, it’s not likely that they’ll interact and behave in the same ways as your users.
Use-Case Personas are consistently one of the more powerful work products of strategy. They synthesize our discovery and help us to better answer the question – “what problem does the user need solved?”
“Our personas are not solutions oriented. They exist to define the problem space.”
- Blake Godkin
Use-Case Personas can be effective tools for the design process for drive deliberate innovation through greater compassion for users.
They are specific about the problem that needs to be solved,
sufficiently backed by research and data, and
they can help remove our assumptions about the user.
More From Alan Cooper, The Inmates are Running the Asylum
“The most powerful tools are always simple in concept, but they must be applied with some sophistication… Our most effective tool is profoundly simple: Develop a precise description of our users and what he wishes to accomplish. The sophistication comes from how we determine and use that precise description.” – Alan Cooper, The Inmates are Running the Asylum
More From Joel Marsh, UX for Beginners, A Crash Course in 100 Short Lessons
“Personas are not: Personality types, demographics, characters in your “brand story”, stereotypes based on your experience, shallow or one-dimensional, concepts, predictions” – Joel Marsh, UX for Beginners, A Crash Course in 100 Short Lessons
“Personas describe the goals, expectations, motivations, and behavior of real people. Why do they come to your site? What are they looking for? What makes them nervous? And so on. All the information you need should be in your research and data. If you can’t back it up with research or data, you’re just making shit up, and you should stop.” – Joel Marsh, UX for Beginners, A Crash Course in 100 Short Lessons