I attended a fascinating IA Summit presentation by Molecular’s Steve Mulder called “Bringing More Science to Persona Creation“. Lately I’ve been pretty interested in how different companies approach user personas, so this was a must-see for me.
I was impressed with Steve’s insights into user persona creation, but this was tempered by a fear that, if taken too literally, Steve’s perspective on personas might actually do as much harm as good to the adoption of personas more generally as a powerful design tool.
A Brief History of Personas
User Personas, defined simply, are short profiles of typical users of a product or web site, intended to help the design team reach a meaningful understanding who their end users really are. I’ll assume that if you’re reading this, you already know something about personas.
Alan Cooper introduced the world to User Personas in his classic book “The Inmates are Running the Asylum“, and since then it seems like thousands of companies have at least tried the technique in the hopes of building better products for their customers and employees. Today, many companies (including Behavior) use personas as a core part of their user-centered design toolkits. In 25 pages, Cooper ignited a revolution.
Or did he? I would argue that while Cooper did ignite something, user personas are still the subject of far too much confusion and debate in the user experience design community. There are still wide open questions about what personas are for and how we should use them. Are user personas being used correctly? Are they being used enough? The answer to the second question, to me, is a resounding NO, we’re not using them enough. The answer to the first question, to Steve Mulder, is also no: we’re not using personas correctly because we’re not being scientific enough in the way we create them.
And that’s where I think we might have a problem: If Steve’s advice is taken too far (and he’s not the only one saying it), if personas must be be approached more scientifically in order to be valid tools, then fewer of us will use them on our projects. The more “scientific” personas are required to be, the less likely they are to actually be used. I’ll explain…
The Problems with Personas
Steve acknowledged the deep reservations most information architects have with creating user personas: While most of us are immediately drawn to the potential power and usefulness of personas in theory, we constantly wring our hands over the fact that user personas are, at least in the way they’re currently conceived, largely seen as potential fabrications. Works of fiction. And we know it. And our clients know it.
To information architects steeped in the ideals of user research, usability testing, and empirical methodologies, creating user personas from scratch is unethical and even heretical. Making up characters might be okay for Jayson Blair or James Frey, but not for real user advocates.
The preferable alternative, Steve says, is to craft your personas using a more “scientific” approach: to use a variety of powerful empirical tools to remove as much guesswork and speculation from the task as you can, and to base your personas on actual users, their real goals and needs, and their real behaviors. In his presentation, he described many different ways one can make one’s personas more real and more scientific, including quantitative and qualitative user research, surveys, interviews, log analysis, contextual inquiry, CRM data analysis, and more.
This urge, at least as I see it, is what Jesse James Garret called “lab coat IA”: We strive to ground our design decisions on empirical truth in order to avoid arguments based on personal taste and individual idiosyncracies. In his 2002 essay ia/recon, he writes:
The current fashion in thinking about information architecture is that the only good architecture is one that has been built upon a foundation of pre-design user research, and validated with a subsequent round of user testing. But the conflation of architecture with research — and the conclusion that one cannot exist without the other — is a deceptive oversimplification.
At best, we are merely deceiving our clients. At worst, we are also deceiving ourselves.
I agreed with Jesse at the time, and I agree now. To be fair, though, Steve freely acknowledges that there’s never really “proof” that your personas are “real”: No matter how much research you do to make them real, they still require a little fudging, a little inspiration, and a little expert insight to make them truly useful. There is always an art to it. The data will merely permit you to be, in Steve’s words, “less wrong” than if you didn’t have the data.
In theory, of course, Steve is absolutely right that “scientific” personas are better than non-scientific ones. He’s right that many IAs pull our personas out of thin air, and he’s right that many of us wring our hands over how we aren’t doing enough research to back up our work. Our faithfulness to understanding real user needs is the backbone of the information architect’s identity.
My contention, though, is that the vast majority of us really don’t need to be quite as scientific as Steve recommends.
Don Norman often uses the term “creeping featuritis” to describe what happens when we add features to a product without basing those features on what people actually want and need. This would seem to be a convincing rationale for creating deep, complex user personas, right?
Maybe not. If you view the user personas themselves as a product, and the product design team as users of that product, you wouldn’t necessarily reach the same conclusion. The level of complexity, detail, and scientific “truthfulness” of a user persona is a factor of context: Who is ultimately using the personas and how, and what the schedule and budget are.
If personas are going to be used to help a thirty-person team build a multi-million dollar web site, spending a month or more doing the research to build scientific personas makes a lot of sense. But for a five-figure web site, a development team may only be able to budget a few days for persona creation. For smaller projects, maybe even less than a day.
In fact, when Cooper introduced the persona concept, personas were breif to-the-point sketches. Those are what we fell in love with back in 1998. But look at what’s happened since then: User personas have bloated out of control! What started out as simply a name, a photograph, and two or three short paragraphs of text have turned into virtual FBI dossiers and employee personnel files, replete with citations, numbers, charts and graphs, and reams of text.
For big projects, complex personas might be perfectly appropriate. But all too often smaller, low budget projects end up making a tough choice: Clients and teams doubt the value in building and using personas that lack a strong research foundation, so they simply skip them entirely.
Getting Real with Rapid Persona Modeling
To latch onto the buzzword du jour, I think it’s high time a lot of us “got real” about personas, and attack them with a little more flexiblity. While the 37 signals crew would probably skip personas entirely, I think personas incredibly useful even for small teams and small- to medium-sized projects, even if they’re not firmly based in research, even if they’re largely “made up”. If produced by team members with even a little bit of insight into the product’s users, they’ll still help a team’s understanding of what’s right and wrong for the product, and are certainly better than just not doing personas at all.
What we need is a professional toolkit and a respectable discourse to support a rapid- or guerilla-based persona modeling approach. I fear there’s a lot of resistance in the IA community to this, however, but I hope I’m wrong. Steve Mulder’s approach is great, but it’s not for everyone or every project and by no means should our admiration for his tools mean that alternative, possibly less scientific, approaches aren’t incredibly useful, too.
Don Norman, by the way, agrees with me. He calls this approach “Ad-Hoc Personas” (ironically, this is a sidebar in a book dedicated to the idea that personas must be grounded in user research):
Do Personas have to be accurate? Do they require a large body of research? Not always, I conclude. The Personas must indeed reflect the target group for the design team, but for some purposes, that is sufficient. A Persona allows designers to bring their own life-long experience to bear on the problem, and because each Persona is a realistic individual person, the designers can focus upon features, behaviors, and expectations appropriate for this individual, allowing the designer to screen off from consideration all those other wonderful ideas they may have. If the other ideas are as useful and valuable as they might seem, the designer’s challenge is to either create a scenario for the existing Persona where they makes sense, or to invent a new Persona where it is appropriate and then to justify inclusion of this new Persona by making the business case argument that the new Persona does indeed represent an important target population for the product.
I’ll be writing more about this in the future, but I’d love to hear what you think about these ideas: Do you use personas at all, or do you skip them because they’re too much work, or because you think they’re just too phony? If you use them, do you do a heap of research, do you make em up out of thin air, or somewhere inbetween? Leave a comment, or reply to me offline, if you prefer (askrom [at] graphpaper dot com). Thanks!
UPDATE: Closed comments. This post is somehow a spam-magnet. Weird.