Experience Matters

What would we do if they banned personas?

Steve Portigal published a thought-provoking article about the failings of personas in ACM’s Interactions magazine earlier this month. His fundamental argument is that personas are more dangerous than useful because they “are misused to maintain a safe distance from the people we design for… manifesting contempt over understanding, and creating the façade of user centered-ness…”. If you want to read it, ask Steve to send you a copy – it’s a stimulating read.

When I first tried to write today’s blog post, I read the volumes of criticism and commentary from user experience heavyweights like Peter Merholz at Adaptive Path, and Jared Spool at User Interface Engineering. Then I tried to write my own clever and finely tuned rebuttal. After all, we’re proud to be recognized for creating and using excellent personas (at least, according to one source). I mean, if I believe in them, I have to defend some turf here, right?

I tried that (for about three hours yesterday), and it made for a really, really dull blog post. So let’s take a different approach.

Let’s pretend that personas are banned. What would we do?

To better define the problem, have a good hard look at Portigal’s concerns. His article suggested that personas fail in a couple of different ways and I tried to turn those failure points into questions to guide our virtual brainstorming session. I came up with the following:

• How do we engage in a meaningful way with complicated customers to learn about them and their messy worlds?
• How do we maintain this relationship over time, as customers and their worlds change?

Some things that don’t change: There are probably a lot of things that we would do the same way, regardless of whether personas were on the table or not. Preparing for any project, we want to make sure that our team and clients have a clear understanding of the customer and their needs, interests and desires. Personally, I would be certain to:

• Spend time to research and understand the customers’ needs.
• Use ethnographic techniques to observe the customers in their own environments.
• Observe as many people as possible.
• Take lots of pictures, and make recordings (among other things) for those who couldn’t observe.
• Spend an hour after the research day in the pub highlighting important observations.
• Analyze and discuss the data to synthesize the key insights.

As Spool explains, the key isn’t so much about the appearance of the document as it is the research experience. The method should be an experience through which the participants gather authentic data and create meaning.

And some things that might change: Despite all my idealism about participation, we would need to start doing a few other things differently. Without personas for ongoing reference, we still have to capture and communicate our findings to those who need help remembering what they saw or who couldn’t attend in person. As Merholz tells us, we need an anchor for our discussions about the solution.

We might also address some other problems left unaddressed by personas. What are they? I’ve noticed that all our left brained information architects love the logic and precision of personas, but our right-brained designers and art directors sometimes struggle to internalize all the information in the personas. Frankly, they don’t always find them very inspirational or interesting. Talking about feelings, personas work well for our transactional projects, but they don’t really always convey the emotional and perceptional details that I like for more brand-oriented projects.

The goal here is to communicate our findings to the group that had to stay behind and to do it in a way that can be inspiring. To do that, maybe we would:

• Steal ideas from great creative briefs by our friends, the account planners who know how to talk to creatives and convey emotion
• Get a lot better at telling stories from the field research
• Create an animation or film that explains the customer and their needs
• Create a briefing that uses the video and audio recordings to impart key learnings
• Hold a workshop to convey and discuss the key findings with the team and our client
• Have real customers participate in ideation sessions to help brainstorm solutions
• Use other participatory design techniques like paper-prototyping
• Post large images of research participants, artifacts and environments on a wall in the work space with explanations of key learnings
• Post diagrams explaining the customers’ key processes or thinking patterns

And what about follow-up? I think one of Portigal’s most important messages is about maintaining meaningful engagement with customers on an ongoing basis. I agree that it isn’t acceptable to simply complete upfront research and then never speak to customers again. So here are some follow-up strategies that we might consider as we design and release the product:

• Perform concept and usability testing on your solutions
• Establish customer feedback panels to consult with
• Use quantitative methods to measure the customers’ response to your solution
• Visit customers using your products in the field

So how did we do? Would you, dear reader, add to or remove anything from my three lists?

So does this mean I can live without personas? Despite what you might read into this article, I’ve had more success than failure with personas and will continue to use them, when it is appropriate. But if told to do without personas (and I have been), I think we can find equally productive ways to work around the challenge. Many of things in these lists are things that we’ve executed successfully at Critical Mass and we consider many of them to be equally important parts of our working processes.

Now let’s ask this: “What would I do if the only tool we could use was personas?” This is a much harder question to answer, isn’t it? It highlights that personas alone won’t make a great experience any more than a designer or a developer or ethnographic interviews alone will deliver a great experience. Personas have their place in synthesizing inputs and communicating key insights, but they’re only one tool. Personally, I prefer to have more than a hammer in my toolbox.