Other creatives joined in. In 1993 Olgilvy wrote about “Customer Prints," using marketing characteristics for representative users. That same year, Verplank, Fulton, Black, and Moggridge presented “Observation and Invention: the use of scenarios in interaction design” at InterCHI which introduced “characters” based on direct user observation.

Over the next 10 years, Cooper, Kim Goodwin, and others wrote about personas and how to create them. The software industry adopted personas slowly: first the pioneering HCI folks took interest, then forward-thinking agencies picked them up as a way to understand users. Personas spread as an integral way of representing users during the design and development process.

Problems in Personaland

As their use spread, the distinction between marketing and UX personas blurred, for several reasons. This blurring sowed seeds of discontent around personas that erupted in the maturing UX world in 2007, calling into question personas’ purpose and usefulness. Here’s what happened:

Half-Baked Personas

Early persona-adopter designers and researchers soon learned how hard it was to sell design research both within an organization and to outside clients. Research can be expensive, it’s hard to show immediate ROI, and it takes precious time at the beginning of the design and development process.

This led to the first type of problem persona: the half-baked persona. Research was gathered as it was possible—maybe instead of getting 15 contextual inquiries, five user interviews were performed. Or, if that wasn’t possible, two quick phone interviews and a reliance on available marketing data.

These personas weren’t entirely made up, but they weren’t built on a wealth of first-hand user research. It was easy to produce deceivingly authoritative personas based on this thin information. Details pulled from the consumer studies available were used and embellished upon. Assumptions were made and logos were pasted under “Brand Affinities.” Designers wanted the feeling of having rich personas, but they didn’t have the design research findings to back them up.

Empty Personas

Worse than the half-baked persona is the second type of problem persona: the truly fictional one. Based only on marketing data or the opinions of company stakeholders, whether they’d ever met a real user or not, fictional personas poisoned the pool.

They had no grounding in direct user research, were usually drenched in superfluous details, and they could be smelled from across the office. When presented with a fictional persona, product development teams usually take one look, smile sadly, nod, and get on with their business. And so, the hatred of “BS personas” was born.

Looking for the Fix

Even if designers are able to get funding for their coveted research, there are still problems. When creating personas, it’s easy to take shortcuts during analysis and the personas wrung out of it are shoved into user categories that are irrelevant to the current design problem.

These personas are often too specific, focusing on traits that don’t inform design decisions. For example, when redesigning customer support tracking software, do we need to know if Customer Service Sue is married or single? Isn’t it more important that first-hand user research surfaces insights that not all support reps seem to have the same motivations? Inexperienced reps are focused on their performance numbers—the number of tickets they can close in a day—while experienced reps pay little attention to their stats: they are confident about their performance and instead focus on providing great customer service. These are the sorts of revelations that can lead to real innovation.

How to Get Back to that Loving Feeling

Good personas that enable us to have extended role-play with our users serve a need that isn’t currently filled by anything else. If the design community throws personas in the trash, they’re back to square one: the standard old argument around the product team table based on everyone’s personal opinion. The user is lost in the equation.

So, how can we get back the persona love?

Get Grounded

Good, solid first-person research is at the heart of all useful personas. This includes careful preparation and participant recruiting across a wide variety of potential users. The resulting observations require thoughtful, creative analysis and synthesis that not only boils down what the users are doing and expressing but finds out why: why is this observation true?

While design researchers advocating best practices have encouraged the addition of personal details to make personas feel more real, Jonathan Grundin wrote about how traits change and that personas should focus on goals, motivations, and expectations. This is especially true when real users switch personas as their context changes. Tying personas to personal characteristics and preferences doesn’t help us in these situations, it distracts us. There’s a fine balance between the goals/motivation/expectation focus and the information that increases the humanity of our personas. This balance must be struck carefully for each design problem—each time personas are sussed out of our messy set of user data.

The resulting personas are the opposite of BS. Real personas get at the core, using the users’ own words heard during research. Real personas are not made in some cookie-cutter template but have morphed and changed through the analysis process to reflect the situation and mindset of a particular user group.

The role-playing conversation held with these motivated characters—whether through scenarios, storyboards, or in discussions—is used to make decisions on feature prioritization and to craft usable designs. The personas talk back. A persona can say, “I don’t care about that. This is what’s important to me.”

Round Out with Real Voices

The presentation of personas should facilitate a deep understanding as well as the ability to scan, parse, and leverage information. Placemat personas are often looked at once and put away forever. Don’t consign your poor users to this fate: there must be an effective vehicle for sharing research findings about targeted end users.

If direct research can be shared, allow actual users to tell their own stories. Use real photos, audio, or video of people in their environment. Instead of inventing stories to bring imaginary people to life, lean on journalistic or documentary techniques to let users have their say in their own words. See how The New York Times lets a woman speak for herself.

User researchers can employ similar methods, bringing together users with similar goals or motivations to tell a collective story. It will be far more memorable to a development team to hear four interviewees describe a goal in similar terms than to scan a single PDF that gets filed away. If the entire team believes in the personas and who they represent, personas are much more likely to be loved and used.

Evangelize Your Personas

Beyond letting the personas speak through real users’ voices, they can be kept alive within an organization by laying some groundwork.

Name and empower an internal champion to keep personas alive and involved in the process.

Create persona signifiers for continued use throughout the organization. Despite sometimes feeling goofy, we’ve found giving personas memorable names helps them stick in team member’s minds.

Create cardboard cutouts, photos, or hats with the personas’ names on them to use when speaking with their voice.

Use role-playing and Q&A with personas to answer questions the team has. This helps establish a “culture of asking” instead of making things up based on hearsay or personal opinions in the team.

Conclusion

These steps—solid research, creative analysis, and compelling presentation and rollout—can bring teams back around to a tool that they badly need. Feel free to dump the shallow personas that people roll their eyes at. It’s time to reengage with empathetic work by making your users real, and letting their real voices be heard.

About the Author(s)

As principal UX designer for projekt202, Kyra finds joy in taking the initial chaotic soup of requirements, user data, and expectations and distilling it with a goal in mind: to create elegant interfaces and services that makes users' lives better. Kyra has worked with large companies including PayPal, Motorola, Microsoft, and Charles Schwab, as well as startups, non-profits, and universities. With all of them she has found that user research makes a positive difference in how teams work together to make successful products.

As principal design researcher for projekt202, Jan is responsible for both generative and evaluative user research. Figuring out how to answer design questions demands creativity and willingness to experiment with methods. Her passion for research lies in her fundamental belief that design research can lead to nonobvious insights.

And I like “I don’t care about that. This is what’s important to me.” I sell personas to designers as design constraints. As a way to help narrow down the space of possible solutions to those that will be useful, useable and engaging for the customers/audience/staff.

And finally, thank you for the emphasis on actually using the personas. I'd like to add a couple more that have worked for me:
• in new staff induction, use your personas to help people them get up to speed with product/service users
• in vendors/technology selection, ask candidate suppliers to show how their solution will meet the needs of your personas, ask them to demonstrate your personas following your stories/journeys/scenarios to achieve their goals

Great article guys. Love that last line - "solid research, creative analysis, and compelling presentation and rollout".

On proto-personas, I have used them successfully in organisations that have a good base of existing data. You create proto-personas from the existing data see where you have gaps in understanding and focus your further research on those areas. The danger, of course, is that you never do that research and make up stuff to join the dots.

It's also great that your article has the word 'empathy' in the title. I see too many personas that go no further than bullet points, attributes gauges, etc. To create empathy our personas need to be real characters that tell their story. A bullet point saying a persona is 'time-poor' is one thing. A couple of sentences in their story showing how their lack of time impacts their life is gold.

I agree with the article and with Ben & Andrew's points about persona development sessions with stakeholders. I'm curious about the rallying cry. We seem to all agree that the ideal scenario is more robust research, but in the world of Lean and Agile we have less time today than ever before. How do we avoid the same challenges that plagued personas the first go round?

I've had good success with proto-personas, and like Andrew have run workshops under low-budget conditions to 'draw' them out of clients. For me the value in proto-personas is actually mostly to get clients to understand how *little* they know about their own customers. They might know target demographics and the types of *roles* customers might have (particularly ones who run member-based organizations), but they're often in the dark about their customers' real motivations, tasks and scenarios.

So it's mostly a learning exercise - a 'come along the user-centered design journey with us' exercise - for clients, than for us as UX designers to get good, meaty, authentic personas. We definitely need proper research to get that. :)

But it gives us insights into what clients *think* about their own customers, that's for sure!

Andrew: I’m feeling the need to clarify. :) I think ad-hoc personas don’t enable the role-playing conversations we try to have as designers because they’re more profiles and not underlying motivations and goals. Ad-hocs can focus team conversations on key roles and tasks but I’m unconvinced they support truly fresh problem *setting* which can lead to entirely different solutions -- this is what makes a deeper persona so powerful.

I grant that every project isn’t going to have 6-12 weeks of dedicated research (oh, user research heaven!), but I think there’s usually room in even the smallest budgets to do some guerrilla research and actually speak with end-users. I’ve had good luck doing this with early phase start-ups and it’s always eye-opening to the founder-team to hear what users are saying and feeling in their own words. It’s also really fun. And yes, then they start doing it themselves and I get like a proud parent. :)

Thanks for your reply, I’m glad people really think and care about how their users are represented to the broader team.

Kyra: I think we are both on the same page. The article seemed to take a strong position against ad-hoc personas (probably strategically to stress the importance of user research). But, it sounds like you still believe they can be useful when used properly (emphasis on *properly*).

I guess my point is that it is impossible for every product to have a well-researched set of personas behind it. While the number of user researchers is growing every day, there is not enough of us to cover all of the products in the world. This is similar to Steve Krug's proclamation that it is better to have a usability test on a product done by an amateur, than to have none done at all. It is still controversial, but I am on Steve's side of that argument (unless you are conducting a usability study on a control panel for a missile).

When I am working with a client with a small budget, I would prefer to base my content/design decisions based on ad-hoc personas than to not have any focus. I do inform the small budget clients of the importance of user research, and sometimes they will do surveys or interviews on their own. I am very proud of them when that happens :-)

Hi Andrew,
Thanks for the thoughtful comment. It's always good to learn about other folks' process and how tools are being used.

It was actually our use of ad-hoc personas and our dissatisfaction with them that led us to re-think our entire persona process. There may be a time and a place for them, but in my experience is that it's with design problems that have been solved repeatedly usually for a broad consumer audience. In these cases the terrain is better known to all stakeholders. Ad-hoc personas can do a fine job of aligning the business and product teams to be on the same page about user roles or tasks and then moving the conversation forward about scenarios, features, user recruiting and testing, etc.

For new products in a new space, more complicated product ecosystems, or for a company that hasn't had a lot of contact with their end-users (and I've worked with plenty of companies like this - where knowledge of end-users is hearsay except from the frontline customer support folks), we think it's important to do the first person research and find out actual end-users' motivations and goals. It can reveal to some surprises and those surprises may be the insights that lead to a new product, feature, or a shift in focus.

Like you, we too use hypothetical sketched personas based on company and product knowledge as we enter research. Then they’re proven and elaborated upon, disproven and scrapped or morph depending on what we hear from the participants.

Good article--I especially like the recommendations to evangelize your personas at the end.

However, I use proto-personas (or ad-hoc personas) regularly and I do not view them as "BS personas". With small 10-hour budgets for UX strategy, I find a proto-persona workshop as a very useful activity that lasts 2 hours or less. At the end of the workshop, we have 3-5 specific personas complete with a sketch, demographics, needs, and solutions. I also organize them in a persona map, so that we know who are primary, secondary, and tertiary personas are. It is risky to work from proto-personas, but I strongly believe that it is better to design for someone we think exists than no one at all.

With larger budgets, I still view proto-personas as a great starting point. They are a hypothesis of who the users are that can be proven/disproven later. Recently, I worked on a project that started with proto-personas and then we revised them later based on survey data.

Also, Jeff Gothelf wrote a great article last year on using proto-personas for executive alignment (and he is following up on this in Chapter 3 of his Lean UX book):
http://uxmag.com/articles/using-proto-personas-for-executive-alignment