Published: Jul 06, 2011
If you were to label any user experience techniques as 'advanced', personas would be a top candidate. A successful persona project is difficult to pull off. The UX world is littered with attempts at using personas that never produced value for their teams, and left a lot of wounds amongst the people who tried to make them happen.
It would be easy to dismiss personas altogether, since they are so difficult to do well. However, we've seen incredible designs come directly from well-executed persona projects. Done effectively, they give the team a fantastic way to stay on the same page, glean insights that would otherwise remain hidden, and produce designs that bring true delight to their users. We're not ready to give up on this technique quite yet.
A few years back, we sat down to research why persona projects fail so often. We investigated what strategies teams should employ to ensure successful projects. After talking with dozens of team, some whose projects succeeded and many whose projects failed, here's what we found out.
Every successful team we spoke with had conducted their own research as part of the project. They talked directly to prospective or current users, observed them doing real activities, and brought that information back into their work.
Very few of the failed teams did their own research. Most didn't do any research. Instead, they made up the personas out of whole cloth and what they imagined their users to be like.
The few failed projects we saw with a research component had farmed it out to a consulting firm or other research team. The people doing the research weren't the ones building the product.
Because the successful teams participated in their own research, they could relate the people they met to their design ideas. The team members had their own memories and experiences to work from, not a second-hand description of the audience.
Strategy: Start your persona project with a quick round of field visits. Don't make up personas, even from demographic and psychographic data. Instead, focus primarily on your target audience's behaviors. The more people you visit, the more likely your personas will reflect real audiences and produce the great design insights you seek.
Who needs to create and use the personas? On the teams with the failed projects, only a few people knew about the personas. Often, it was a small group that created them, frequently followed by a publicity campaign to get others to use them.
The successful teams made sure their core designers Ð the folks up to their elbows in wireframes and pixels Ð were part of the persona creation team. However, most successful teams went further and included the other influencers, such as stakeholders, product owners, support people, and other executives.
Often, when persona projects fail, it's because many of the people who are influencing the design don't understand the personas. They end up pushing for design changes and requirements based on their own personal perceptions, which is exactly what personas help to avoid.
If the team involves the influencers in the creation of the personas, they'll be more likely to use them as they assert their influence throughout the project. This also gives the team the response of "that's a great idea, but how would Martha use that feature?" when something wacky comes down from above.
Strategy: At the project's start, identify the core team members and the influencers. Core team members should participate in most of the research. You should set a minimum amount of participation for influencers, which includes several visits and time in the creation process (so they see how it's done).
When we talked to the successful projects' team members, each one could, without fail, describe the personas from their projects. They knew who they were and what made each one unique. They did this all from memory, often months after the project's completion.
The failed projects' team members, in contrast, couldn't tell us hardly anything about their personas without looking up the documents. Even when they could talk about them, they often had the details confused.
Having been part of the research and the persona creation phase, the successful projects' team members had really gotten to know these folks. They behaved as if the personas were people they'd known for years. Of course, when you know someone that well, it's much easier to create a design specifically for them.
Another thing we saw with the successful teams: Each piece of the persona description had a clear affect on the upcoming design decisions. For example, if a persona's description said they enjoy classical music, then everyone knew how that would change the music site's information architecture. (Classical music has very different facets from popular music, such as a distinction between composer and musical director or conductor. The persona description talked to that difference.)
Strategy: Teams should regularly review their persona descriptions throughout the project. Each team member should have no trouble describing how each persona will influence the direction of the design.
A trap that we found common to the failed projects was their use of generic personas. Because they wanted to make their personas as useful as possible across many design objectives, the descriptions they created were broad and non-specific.
The problem is that it's hard to make design decisions with generic personas. When the persona is too broad, there isn't enough definition to help the designer know which way to go. Generic personas are far more likely to be put aside than specific ones.
The successful teams had very specific persona descriptions that weren't useful beyond a specific design objective. For example, if the objective was to create a new music-site search interface, then everything in the behaviors would be about searching for music. If that project then moved on to a new music player for discovering new songs and artists, the previously created personas might no longer work. (In fact, it's likely they didn't work at all, because search is very different from discovery.)
It is very difficult to create specific personas that span multiple design objectives. It's not impossible, however, and we've met seasoned teams that have learned how. However, for teams new to using personas, it can get the team into trouble to try to do this. They end up with something less useful than if they focused on a single objective.
Strategy: Pick the most valuable design objectives when creating your personas. Look at the upcoming design challenges and choose objectives where the UX will bring great returns if you do an awesome job. For the other objectives, don't fret if your personas aren't useful. (But you'll get extra karma points when they are.)
Persona expert Kim Goodwin once told us, "If personas are the lights in the operating theatre, then scenarios are the surgeon's scalpel." Wise words. And it matches exactly what we saw when we studied these projects.
Many of the failed persona-project teams never bothered to create any scenarios for their personas. (It turns out it's very hard to create specific scenarios for generic personas.) Even those that did create some scenarios had very few to work with.
When you give the team a persona specific to a design objective, it's usually pretty easy to come up with a set of rich scenarios to go with it. These scenarios become the meat of their design activity, guiding the team through many important details of the design.
And just like their persona counterparts, each sentence of the scenario description needs to tie directly to a design decision. If we say the persona's new found love for tango music has driven them to find the best classical guitarists, we should know how this level of specificity will change the music search interface.
Strategy: Derive your scenarios directly from your research. The more time you spend in research, the easier it is to create a multitude of specific scenarios. It becomes a simple matter of describing exactly what you saw.
Personas are an extremely valuable tool for designers who desire to create leading-edge results. As with other tools, the designer will need to acquire the skills through regular practice. If you give your team the space they need to master the tool, you'll find it to be a fabulous way to boost your UX practice.
If you're looking to get more out of personas, check out Whitney Quesenbery's virtual seminar, 7 things You Can Do with Your Personas. Whitney will tell you the 7 characteristics of effective personas and describe how to use them for improving user experiences.
Have you tried to use personas in your projects? What have you found to be the keys to your project's success (or the reason for your project's demise)? We'd love to hear your thoughts. Put them on our UIE Brain Sparks blog (and check out what others are saying).
Read related articles: