Originally published: Feb 17, 2010
Personas are a flexible and powerful tool for user researchers. They're also one of the most misunderstood. When done well, they ensure the team focuses on the needs and delights of their users.
Like other effective user research techniques, personas deliver confidence and insights to the team. Personas help the team make important design decisions with a thorough understanding of who the users are, what they need, and when they need it.
For the last few years, we've studied how a variety of design teams have tried to harvest the benefits of persona projects. We've explored several wildly successful persona projects and many that fell far short of their goals. We now better understand where the magic lies with personas -- what the essence of a successful project is.
You don't get the benefits of personas for free. While we saw many teams reap new insights within the first few hours, the teams that saw the most out of it made a long-term investment.
Our research showed timing is a critical element in the success of persona projects. The team has to be in a place where they can proactively tackle design challenges. If the team is dealing with a firehose-stream of feature requests and enhancements, the project won't get much traction.
At the same time, the organization needs to be ready to make the users' overall experience a priority. We noticed this often comes after an experience disaster -- some external issue that brings the overall experience, not just the features and technology, into the limelight.
For example, when a major e-commerce web site suffered a failed redesign launch, reducing sales by 35%, their senior management finally understood the need to know more about how their customers shopped. Before the devastating launch, the management's focus was all about features and slick visual design, but because of the revenue decrease, customer experience was now on everyone's mind. Personas were now a priority.
Because personas take time to develop and integrate into the culture, they require involvement at all organizational levels to be effective. Like any important endeavor, if the organization can't give the team the time and resources, then the persona project will probably fail. When that happens, it's likely the organization is just not ready.
We were surprised by how easy it was to jumpstart a persona project. We came into the research thinking successful projects had to start with an intensive research effort, costing big bucks and eating up the calendar. We couldn't have been more wrong.
Many successful teams started by culling information the organization already had in their heads. Using techniques that collect this information, such as Tamara Adlin's Ad-Hoc Persona workshop, these teams get working personas very quickly.
These quick-start methods are often fun and inspiring, as they focus the team on usersí needs from the very beginning of the project. A key element is involving senior management and stakeholders from the get-go. Their participation sanctions the work, helps everyone think from a user experience vantage point, and simplifies the persona ranking process.
At first, we were wary about constructing personas from existing viewpoints instead of from fresh research of real users doing real things. We thought it would create a design trying to solve problems that donít encompass real users needs.
However, almost every team that used the jumpstart method went off to do more robust, formal field research, visiting users and observing real issues. As the new information came in, they changed their personas along the way, showing management where the internal beliefs differ from the real world. And, because the team involved senior management in the first pass, it was easier to sell the more rigorous research.
Our big surprise was discovering this: A team using the same, incorrect personas is better than each member designing for a different user, where some hit the mark and some don't.
Having the same personas to work with, even if they're off the mark, gives the team a common language. Since the successful projects ensured their teams had subsequent exposure to real users, correcting any wrong beliefs was easy. When everyone started on the same page, they found it easy to talk about how new information needed to change their understanding.
A common fixation amongst the failed persona projects we studied was the look and feel of the description document. The teams believed they needed a great looking description for each persona for its adoption. These teams invested hundreds of dollars (sometimes thousands) to produce slick posters, screensavers, and slideshows, describing the intricacies of each persona.
Studying the successful projects, we learned these description documents aren't important at all. These teams often had very bland, non-descript documents describing each persona. Instead, we found four success criteria: internalizing the personas, creating rich scenarios, prioritizing the most important personas, and involving all the stakeholders and influencers.
Internalizing the Personas: Each team member had the same personas in their head. As we talked with each person, they could describe the personas as if they were their favorite story characters. They had internalized the details -- making them real.
Creating Rich Scenarios: The team members could talk through the personas' scenarios in detail. They could share each persona's context, the desired scenario outcome, and the approach the persona took to get there. It was clear the team had talked about these scenarios often, because everyone would tell us the same details, much like when people share their favorite fairytales.
Prioritizing: Interestingly, the successful projects also had something we hadn't originally looked for: a clear understanding of each persona's priority. We'd always thought the importance of a persona would shift depending on the designer's current focus. However, amongst the successful teams, they knew which personas were most important and which they could sacrifice when compromises had to happen.
Stakeholder Involvement: The most successful projects made sure this knowledge extended beyond the primary design team members, to all the people who could influence the design. When we talked with stakeholders and influencers outside the core project team, such as business line managers and the company's lawyers, it was clear they were also well versed in the personas, their scenarios, and their priority. They told us of frequent meetings and memos where an in-depth analysis of a persona's scenario influenced important business decisions.
We've found there's a simple test to measure whether a persona project will be a success: Walk up to any team member, stakeholder, or influencer and ask who the most important personas are. If they can give the same story as everyone else on the team, you have a winning project on your hands. Slick posters and screensavers aren't spreading this understanding -- it's frequent, in-depth discussions at practically every point in the project.
We've long believed personas were a valuable design tool. We were initially disheartened by the many failures we'd seen, but now that we've had a chance to study some successes in-depth, we can see teams realizing the promised benefits.
The trick is to not rush into it. Ensuring the organization is at the right place in their user experience maturity is critical. Using a jump-start technique works, but the team needs to follow up with robust research. Finally, keeping the personas alive through frequent discussions, especially around key decisions and trade-off conversations, makes them a valuable design asset.
We are really impressed with Tamara Adlin's Ad Hoc Personas technique. We think this is an essential tool for getting everyone in the organization on the same page. And you're in luck. We have a recording available of Tamara's virtual seminar The Power of Ad Hoc Personas, where Tamara walks us through the method.
Have you peered into your search log? We'd love to hear what you found. Let us know at the UIE Brain Sparks blog.
Read related articles: