Personas and the Advantage of Designing for Yourself
What are personas good for?
Update: Since the original publication I’ve received a tremendous amount of feedback concerning the definition of personas (as I anticipated). To that end, I’ve tried to incorporate all those concerns into the piece. I’ve re-ordered some things and clarified where appropriate.
Steve Portigal, whom I’ve met and whom I don’t think is insane, recently said in a presentation that “personas are user-centered bullshit”.
But he didn’t stop there. He then went on to write an article in this months ACM Interactions magazine extolling the evils of personas which is provoking quite a reaction among designers. He says:
‘Personas are misused to maintain a “safe” distance from the people we design for, manifesting contempt over understanding and creating the facade of user-centeredness while merely reinforcing who we want to be designing for and selling to’
Portigal isn’t the only one to argue against personas. Jason Fried said recently that personas “lead to a false sense of understanding at the deepest, most critical levels.”
Each of these pieces has received a mountain of pushback from certain members of the design community, who feel that in many ways personas are the best tools for communicating design research throughout heterogeneous groups made up of designers, marketers, managers, and executives.
Peter Merholz, in describing a recent project, found personas quite valuable:
‘So on the morning of the second day we dove into a discussion of personas – those archetypal users of the product. We had three personas (Casey, Jessica, and Eric), and we talked about (and occasionally argued about) them for quite a while, until we arrived at a shared understanding of who they are, and what they would get out of the product.
This discussion proved enormously valuable – it lead to some coherence around who the product was for, and it helped focus our discussion of desired experiences, and, in turn, functional requirements. We referred to these personas for the remainder of the workshop, and they came in handy for resolving conversations that got stuck in “Well, I think…”
Definition, please?
But while all of this arguing is going on, nobody is really defining what personas are. This, of course, is a big part of the problem.
Here is the Wikipedia definition:
“Personas or personae are fictitious characters that are created to represent the different user types within a targeted demographic that might use a site or product. Personas are given characteristics and are assumed to be in particular environments based on known users’ requirements so that these elements can be taken into consideration when creating scenarios for conceptualizing a site or product. Alan Cooper (in The Inmates are Running the Asylum) outlined the general characteristics and uses of personas for product design and development.
In the context of software requirements gathering, a user persona is a representation of a real audience group. A persona description includes a user’s context, goals, pain points, and major questions that need answers. Personas are a common tool in Interaction Design (IxD)”
As the Wikipedia definition suggests, personas are often realized as a document that is passed around design teams. A document is created so that everyone is on the same page (otherwise each person would have to remember a tremendous number of details). Personas (persona documents) might be a poster, a word file, or a PDF. Whatever the format, they represent an archetypical person. (While it isn’t technically necessary to create a persona document, it is done in every case I’ve ever heard of) Kim Goodwin, who has refined personas over the years at Cooper, suggests that describing your personas in narrative form is an important part of their creation:
“A list of bullet points might contain the same essential facts, but since personas do double duty as communication tools, a narrative is far more powerful in conveying the persona’s attitudes, needs, and problems. The Cliff’s Notes edition may convey the basic ideas, but it will never be as compelling as the story.”
It should be clear that personas are only one way of organizing research. Other ways include user profiles, user scenarios, mental models, and simple storytelling. Many design teams have their own way of organizing and summarizing their research data.
Personas should not be construed as the act of doing research! They are merely one way to summarize research. What’s really important is not that teams create personas (or some other organizing mechanism) out of their research data, but that they do research in the first place! This will help prevent the arbitrary decisions that plague so many design efforts.
But let’s return to the subject at hand, personas.
As mentioned, personas were formulated by Alan Cooper. He wanted to be able to design for a “broad audience of users”. When you design for a broad audience you can’t design for each individual, you must make generalizations and design for those. To quote from Cooper’s book About Face: The Essentials of Interaction Design:
“the key is in choosing the right individuals to design for, ones whose needs represent the needs of a larger set of key constituents, and knowing how to prioritize design elements to address the needs of the most important users without significantly inconveniencing secondary users”.
Cooper’s solution is to do real research on folks, grab the trends out of that research, and create personas out of them to help spur discussion and decision making. Part of that “creating personas” step is to give them a name, a face, so that they are easily referenced.
From my experience, this anthropomorphism leads to difficulty. The problem is that personas are, by definition, an abstraction of research. Personas represent a summary of research from many different people. In other words, it’s a generalized construct.
But when you place a very specific picture of a person on that persona while giving it a name, you’ve made it particular again. You’re asking people to treat it as an individual person. You’ve taken the summary and made it specific. This is confusing.
Abstractions, which are the quality of dealing with ideas instead of events, can be particularly confusing in design, especially in web application design where events are crucial.
Cooper, however, says that this is necessary:
“this is appropriate and effective because of the unique aspects of personas as user models: they engage the empathy of the development team twoards the human target of the design”
Empathy is important. But I would argue that empathy is something that has to happen within the person designing, it’s not something you can make someone feel through generalization. But whether or not personas help to create empathy, they might help designers get into the right mindset for design. Andrew Hinton wrote a nice piece on how personas are really about role-playing. This is directly from Cooper as well. Personas help designers get into the right mindset if they aren’t already.
Cooper goes on to say:
“Although personas are represented as specific individuals, at the same time they represent a class or type of user of a particular interactive product. Specifically, a persona encapsulates a distinct set of usage patterns, behavior patterns regarding the use of a particular product (or analogous activities in the domain if a product does not yet exist). These patterns are identified through an analysis of ethnographic interviews, supported by supplemental data if necessary…”
(my bolding added…they represent multiple things at once…again I find this confusing)
Ok, let’s get more concrete. What does a persona look like? Well, it’s quite like the Loch Ness Monster…everybody talks about it but nobody shows an example…especially during a heated debate!
A concrete example of a persona?
Christoper Fahey, picking up on a comment to Jared Spool’s reaction to Fried’s piece, proposes a novel solution that would help clear the air in this debate. Why don’t we: actually publish good personas?
He says:
“It’s all just talk, and highly idealized, too. Advocates of personas unfailingly paint dreamy idyllic pictures of wondrous projects where the team has hundreds and hundreds of person-hours budgeted for persona research. But we readers are left having to imagine how great, how non-crappy, their personas are. Show us the goods!”
To that end, here are a few examples. But before I show them to you, realize that I am 100% sure that these will not be satisfactory to all interested parties. Some folks will look at them and say “Ok, I guess” while others will claim that these personas are the worst blight on all humanity. But these are a necessary first step in coming to some agreement here.
That people will have problems with these personas suggests there is widespread disagreement on what a persona actually is. If we can’t agree on what they look like on paper, how can we have any confidence that we’re even talking about the same thing?
However, I’ve seen Kim Goodwin give talks where she walks through documenting personas. I thought it was great. Unfortunately, Goodwin’s confidence in showing personas doesn’t carry over to many others. My gut tells me that people are really quite afraid of showing their personas in public, for fear that other practitioners will condemn them as rubbish. This is the elephant in the room of this discussion.
Thus, the confusion about what a persona is will likely persist.
In general though, the primary benefit of personas, that most of those arguing for them suggest, is this:
On projects with more than a couple stakeholders, you need to be able to communicate the needs of users to everyone on the team. Personas are a nice portable artifact that allows you to do so. They allow you to communicate with stakeholders, developers, other designers, and any other interested parties.
Note that this is different from Hinton’s piece above. We are now using personas to communicate with others, not to get into the right mindset ourselves (as designers). This fundamental issue leads to the question: who are personas for? Cooper and Goodwin seem to explain that you do make design decisions from them. Others view them as simply a communication tool with non-designers to get them up to speed.
You don’t always need personas
Both Jared and Andy Budd have pointed out what might be the most interesting issue with personas: You don’t need them when you’re designing for yourself. That is, when you are building something for yourself you simply build what tool you want to use. You don’t have to worry about the needs of others.
This is interesting for several reasons. First, it admits that personas aren’t necessary for good design. Good, so we got that out of the way. Don’t use them if you don’t like them, or more appropriately, if you don’t need them.
Second, it begs the question: why don’t more people design for themselves?
I’ve been thinking about this much more lately, as I’ve gone out on my own and am starting to decide what projects to work on and what projects to pass on. Obviously, most of my decision has to do with how much time I have available. But I am more interested in projects that I would get value out of: the ones that I would use myself.
This might be about selfishness…I want better software…but it might also be about self-preservation, too. It makes sense to me that I’ll do much better work (and help my clients much more) if I’m an actual user of the very software we’re designing. So not only am I more interested in those projects, but I would also do better work for my client since I don’t have that wall of the unknown sitting between me and those I’m designing for. That’s why we do user research…to get over that wall of the unknown.
Degrees of Separation
I think we can make a general statement here:
The further a designer is from the people they’re designing for, the harder it is to design for them.
The immediate outcome of this is that those designers who design for themselves will make better designs more easily. The secondary outcome is that those people who are designing for others are at a known disadvantage: they’re at least one degree of separation away from the people who will use the design. Their challenge is harder.
This next paragraph is a joke.
Even the hugely successful iPod, which has taken its place as one of the best designs in human history, was created by music lovers. Jonathan Ive, chief designer of the iPod, is known to have designed the iPod while listening to the very music he would one day play on it.
Designing for self in practice
But does this hold up in practice? Are those people who design for themselves more successful than those who don’t? Here are some examples (off the top of my head) of people and/or products who are designed by people for themselves:
Netflix, eBay, Google Apps, Wufoo, Basecamp, Freshbooks, Yelp, Craigslist, Blinksale
Most of these examples came from folks who were designers/developers first, created something for themselves, and then when others clamored to get their hands on it, they decided to get into the software business.
Coincidence?
The missing piece: Passion
A year ago November I wrote a piece called Users as Developers. In it I argue that there is another important element at work here: passion. I’ll reiterate a quote from Dan Cederholm (who designed Corkd for himself) from that piece:
“There’s a real difference between being a hired hand on a project for a specific amount of time and someone who has ownership as well as passion for what they’re working on (ownership and passion can be exclusive as well, but combined, they pack quite a punch). The short-term, part-time attention of a freelance designer or developer can often lead to clunky, duct-taped solutions after the contract is over and the site is actually being used by real people.”
I think passion is a real issue with personas. Personas might elicit empathy with the people you design for, but they don’t elicit passion. Passion comes from having a stake, having a long-term commitment. Passion is what gets you that last 10% to make something great. Designers designing for themselves are often passionate. It’s hard to get as passionate when you’re designing or doing research for someone else as a freelancer or consultant.
Obviously, being a freelancer myself this brings up a quandary. How can I do great work when I’m only being brought in for a portion of the lifetime of the web application? How can any consultant or designer?
Well, I think the answer (for me, at least) is to only work on those projects that I won’t really leave. Work only on projects that I’ll continue to use, that provide me with value over time. Software that I actually use myself and would want to even if I wasn’t part of the design team. So far, this has happened on about half of the projects I’ve worked on. I’m hoping to increase that over time to all the projects I work on.
If the only thing I have after a project is over is an artifact of the design process like a persona, that says something very important about my relationship to the project and the people I’ve worked with.
So I think focusing on personas is actually a red herring. If you’re doing research and learning about your users, then it doesn’t matter if you create personas or some other summary of your research. Whatever works for you. What is really important is having passion for what you’re doing and putting all of your energy into it. If you are a designer and you’re not a potential user of what you’re designing, you have a higher hill to climb. Better get started now.
Personas may or may not be right for your project. It depends on the group of people you’re designing with. If you can’t communicate what you need to without personas, then consider using them. If you do end up creating a persona, great! But that doesn’t mean it’s the right process for other designers and it doesn’t mean that someone else’s personas are right or wrong. Stop defending turf you don’t need to!
Artifacts of the design process are insignificant compared with the design artifact itself.
