Personas and the Advantage of Designing for Yourself
Date : 2008 01 21 Category : Design & Usability
Bokardo - Social Design by Joshua PorterSteve 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.
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 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. What most definitions don’t say is that personas are a document. They might be a poster, a word file, or a PDF. But they are a document that represents an archetypical person that is passed around design teams. Ok, just wanted to make that clear.
So let’s turn to the Wikipedia definition of personas:
“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. 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)”
Personas are a design tool invented by Alan Cooper. He invented them 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 a persona. 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 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.
Kelly Linda Evan Bob EmmaThat people will have problems with these personas suggests there is widespread disagreement on what a persona actually is. This is true. Though I have defined them in this piece and tried to quote Cooper himself I know that I will not be the one to crack this problem. The confusion about what a persona is will likely persist.
But why don’t we see more personas? Well, one argument is that they’re so contextual that they don’t make sense to people outside of the design project. But to me this is hogwash. Let’s give people the opportunity to make that judgement themselves. Design is communication, after all. How else would a designer learn what a good persona is? Otherwise it’s akin to saying: “Pay no attention to that man behind the curtain.”
The fact that nobody has published personas so far says a lot about their confidence in using them. 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.
In general, 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).
You don’t always need personasBoth 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 SeparationI 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 practiceBut 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: PassionA 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 do 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. 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 necessary in 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 can’t get into the right mindset, consider using them. If you do end up creating a persona to get yourself into the right mindset or to communicate better with others, 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! If other people do design without using personas, let them.
Artifacts of the design process are insignificant compared with the design artifact itself.
Add Comment (4)