Scott asks:
Do you use formal personas when thinking about the users of a new app?
We don’t use personas. We use ourselves. I believe personas lead to a false sense of understanding at the deepest, most critical levels.
Every product we build is a product we build for ourselves to solve our own problems. We recognize our problems aren’t unique. In fact, our problems are probably a lot like your problems. So we bundle up the solutions to our problems in the form of web-based software and offer them for sale.
We recognize not everyone shares our problems, our point of view, or our opinions, but that verdict’s the same if you use personas. Making decisions based on real opinions trumps making decisions based on imaginary opinions.
I’ve never been a big believer in personas. They’re artificial, abstract, and fictitious. I don’t think you can build a great product for a person that doesn’t exist. And I definitely don’t think you can build a great product based on a composite sketch of 10 different people all rolled into one (or two or three).
Personas don’t
Personas don’t talk back. Personas can’t answer questions. Personas don’t have opinions. Personas can’t tell you when something just doesn’t feel right. Personas can’t tell you when a sentence doesn’t make sense. Personas don’t get frustrated. Personas aren’t pressed for time. Personas aren’t moody. Personas can’t click things. Personas can’t make mistakes. Personas can’t make value judgements. Personas don’t use products. Personas aren’t real.
People do
People talk back. People answer questions. People have opinions. People can tell you when something just doesn’t feel right. People can tell you when a sentence doesn’t make sense. People get frustrated. People are pressed for time. People are moody. People click things. People make mistakes. People make value judgements. People use products. People are real.
Get Real
So if you can’t design something for yourself, design something for someone you know. Get that person or people involved in your project early on. Basing your decisions on a matrix of personality traits isn’t what I’d recommend if you really want to build a great product.
John S.
on 06 Nov 07Personas can also too easily be contrived to imply a specific requirement/feature/etc is a higher priority than it actually is.
Ivy
on 06 Nov 07I don’t think we’re arguing for personas to take the place of real users, or making decisions based on imaginary opinions. Personas can help in thinking through scenarios, putting an actor into your narrative or cognitive walk through. Yes, ultimately, a persona should be based on who is using the product – real people. And those users should be involved in the process to provide feedback. Although I do think you can successfully design for yourselves-as-users, isn’t there such a thing as being too close to the end product which may blind you to potential issues other users may have?
Alexander
on 06 Nov 07True: If you lack the imagination and empathy to bring a persona to life, based on your experience with real people, then personas aren’t for you.
Peter Urban
on 06 Nov 07I agree with Jason, it is all to easy to make up personas the way you want them to be so they are a good fit for your product idea and not the other way round. Think of it this way, if you make up the persona first and then you ‘ask’ those fictitious characters questions about your product and then you answer those questions from the persona’s perspective… – there is an awful lot of you involved.
Since the characters and their answers are only as good, realistic, creative or real as your knowledge (or worse imagination) of such characters and their situation, you might as well skip all the role play and ask / answer the questions to yourself.
A compromise woud be to put different people in your organisation into the role of a character / user etc. That only works better if they can really identify themselves with the role thay are ‘playing’...
Dan
on 06 Nov 07Surely, in many ways, your seeing yourself as a persona byy stepping outside of yourself and asking – what do I want? You have all the details about who you are, so effectively you’re designing around a persona (or set of personas in the case of a team) that are very familiar.
Personas as a methodology are flawed – you can’t ever really understand a persona without fully understanding many people that are similar to the stereotype.
They can open up the development process to the fact that there are many kinds of people within your target audience and that maybe acknowledging these can improve a product through considerations these audience members can suggest.
Just a though ;)
Nathan Youngman
on 06 Nov 07Ooops, typo “Personas can tell you when a sentence doesn’t make sense.”
Nathan Youngman
on 06 Nov 07Ooops, you caught it after the RSS feed went out. Too quick on my post.
RS
on 06 Nov 07Not at all. In order to see yourself as a persona, you’d have to erase all the rich details you know about yourself and become a cardboard cutout. It’s impossible to reduce your personal experience down to a handful of data points.
That’s precisely why personas fall short. They make you think you’re designing for a living person when you’re really designing for a concept built out of 10 data points.
To be clear, ditching personas doesn’t mean you ignore customer feedback. It means you listen to feedback from real customers instead of imaginary ones. :)
Josh Seiden
on 06 Nov 07@Basing your decisions on a matrix of personality traits isn’t what I’d recommend if you really want to build a great product.
Personas are not a “matrix of personality traits”, they are simply a type of model—one that represents users. Sometimes, it is enormously helpful to use models, sometimes it’s not. Good models simplify, clarify, represent essentials, and make the abstract concrete.
Models are not a substitute for “reality.” They are a supplement.
Luigi Montanez
on 06 Nov 07Personas are still better than nothing. Obviously real people are the best, but getting real people when you need them isn’t always possible. For those of us who do client work, we need to rely on tools like personas (and use cases and wireframes) to better communicate with the client and manage expectations. Sure, it would be great if we could always build products for ourselves, but client work requires otherwise.
I’m curious, what’s 37signals’ viewpoint on using the Getting Real techniques for client work, when you can’t build products for yourself?
JF
on 06 Nov 07Personas are not a “matrix of personality traits”, they are simply a type of model—one that represents users.
Explain one of these models. Let’s see how they are communicated.
MT Heart
on 06 Nov 07The whole point of creating personas is to get past our personal opinions and presuppositions to understand what users truly need. If we invent fictitious model users and call them personas, we’ll just have the same old problems with the development process packaged up in a new way. If you truly want to build a better product, create your personas based on real data, and use them in conjunction with business goals and good design principles to guide your solutions.
Getting from Research to Personas
Mimo
on 06 Nov 07I never heard of Personas before. Now i read it on wikipedia. The idea sounds interesting. But I think at the end of the day it is crap. The product is always shaped by two things. YOUR experience (your present ego and YOUR idea (your future ego). One of the biggest Inventor of your time, the guy who invented the plastic dowel Artur Fischer was just trying to make cool stuff. And he is still working on things. I am sure he never used personas. He asked himself how can i make this already existing thing better and then he just invented it. Because he is a person who loves simple things he have build simple products. People who are more into structuring labeling things will build their products their way. People who are more into colours will get more colours in their products. Your product is always shaped buy YOUR EGO and not by an imaginative one.
AW
on 07 Nov 07What 37signals advocates (with research in general) works great if like them, your customers want what you want, and you have good access to their opinions (i.e., the people you want to reach spend time on your discussion boards). It works much less well if your customers have some needs you don’t know first-hand, or if you’re trying to reach people who either use your service rarely or don’t give you feedback unless something breaks.
Gary R Boodhoo
on 07 Nov 07with regard to “managing expectations” I’ve seen personas do so nicely at the beginning of a project. Not so much during the middle. Never at the end. It begs the question – whose expectations are being managed and why?
I’m increasingly convinced that personas are at best self-serving, at worst, self-deluding. Probably both. Interface as Theater or desirability testing reveal far more about your own biases/intentions/requirements than fictional users ever could
Sam Alexander
on 07 Nov 07A Persona is a tool just as a whiteboard, wireframe, or pseudocode is a tool. A whiteboard can’t get frustrated, a wireframe only offers pre-programmed feedback, and pseudocode isn’t real (unless you write in Python :))
Personas were never meant to replace people. When used correctly, they are just an aid.
Personas prevent self-serving, single path applications. While you are developing rapidly, they remind you: “Oh yeah, even though I would do things this way if I add the ability to do it this way all the users who think like Fred the Persona would be really really happy.
In fact, most of us are already using them. Every time you think about a user, unless you actually have a concrete human being in mind, you are creating a persona of a user.
When you don’t, or can’t, have real people to test things for you; and you aren’t designing for just youself. Personas are an excellent way to keep you open-minded and user-centric, and prevent usability myopia.
Just make sure you use them instead of them using you.
Gabe
on 07 Nov 07I love the idea of asking people what they think. When I’m at work, I try to ask the least technical people I can when I run into something that makes perfect sense to me. Rather than asking a colleague if they agree with what I’ve done, or asking for help when I run into a problem, I like to ask about the things that seem obvious. When developing something we know exactly how it works, but asking others can provide super insight that we’d have never considered. I’ve asked my wife, my brother, my parents, my in-laws, even my grandmother what they think, and the feedback is always eye-opening.
John Dusek
on 07 Nov 0737Signals, you guys are way off base on this one, and I’m glad to see so many SvN readers saying so.
You don’t value personas in your software development process because you already have a deep understanding of your users. You think like they do, speak their same language and share many of their same needs.
I know you guys don’t do client work anymore, but what if you were building software for people who were very different from you, who used words you didn’t understand or who had needs that didn’t match your own experiences? What if you were designing software for heart surgeons or water treatment workers or air traffic controllers?
Surely you would want to go out and talk to these people to gain a better understand of their needs. You’d want to get to know them, as best you could, in order to get a preliminary sense of how they might use your product. You might find that not all of the users want the same things or that some users have specialized needs. And you might need to communicate these findings to other people who did not get to participate in the research themselves.
Personas are a helpful tool for capturing this kind of information and sharing it with the rest of the team. They can be developed relatively quickly and can help prevent costly mistakes based on an inadequate understanding of the users. They’re not perfect, but when you’re building something foreign, they can be extremely helpful.
Sure, you guys may not need personas thanks to your small team size and domain expertise, but before you dismiss them as a waste of time, consider that you are in the fortunate position of being well-educated about your customers. Many companies are not as well-informed, as evidenced by the many examples of badly-designed software and websites out there. Honestly, do you think Basecamp or Highrise would be as successful if you had undertaken the exact same design process but had started from a position of knowing very little about the types of people who would be using them?
Matt McInerney
on 07 Nov 07It’s always nice to hear about designing for people, as opposed to designing for a target market.
Gary R Boodhoo
on 07 Nov 07John I understand your point very well, and have used personas on various projects. In each case the persona research was of less value than putting a prototype (perhaps simple as a bare-bones HTML mockup or PDF file with limited interactivity) in front of actual users. Granted the scale of those projects may not have been what was required for a nuclear plant worker or air traffic controller… Still, it begs the question – these badly designed software projects & websites you mention – are they badly designed because persona research wasn’t conducted?
My issue with this technique is that its gains are fleeting and seemingly evident at the beginning of a project when there’s a fair amount of uncertainty in a number of domains including marketing, design, tools, implementation and so forth.
At the same time I recognize that its probably unfair to use the term “persona research” as though it weren’t a creative endeavor in its own right. It may be that when such research is conducted, its not taken as seriously as it might be, because you know, the computer is always right – even when its doing the wrong thing:) I’d be very interested to see how these composite “users” evolved over time (like a Sim) and wonder in that case how that user’s needs might feed into day to day design/development/marketing agendas
Harry
on 07 Nov 07I agree with John Dussek.
You employ Personas when you are designing for a user-base and problem-space that the design team doesn’t yet understand. Personas are not a replacement for user research – quite the opposite – they are a tool for communicating the findings of your user research. You don’t just make them up.
Personas are an effective way of communicating research findings back to a busy multidisciplinary design team who don’t have time to sit around reading long reports.
Miyon
on 07 Nov 07I agree with John Dussek and Harry. I am a UI designer for a consumer electronics company and I think the people I work with who actually build the products have no clue about the people they are making it for. This does not mean they are not good at their jobs, they’re bright people. But they are not the end user and if we built our products based on our own needs and desires we would end up with an incomprehensible piece of junk. I think 37signals is in a very fortunate position to be working on products that they can relate to as an end user, but unfortunately that is not reality for many of us and personas have proved to be a helpful aid in the design process. Personas don’t give me answers, but they help me ask the right questions.
MT Heart
on 07 Nov 07Yep. I see this ‘armchair quarterbacking’ all the time, especially from programmers. You can’t just make some stuff up about what you think your user might want to do. You have go research it. Visit the places where they work, observe them in action. Some users really are far smarter and busier than yourself. You don’t design software for air traffic controllers, heart surgeons, archivists etc.. as if it was for a Mom signing up online for some library activity for her kids.
Better yet, leave it to the designers to go do the research.
kevin o'shaughnessy
on 07 Nov 07The idea of using real people is a sound alternative to personas. One technique that I’ve found interesting is the Lead User method, conceived at MIT
http://en.wikipedia.org/wiki/Lead_user
http://web.mit.edu/evhippel/www/papers/Herstatt-EvH%20Journal%20Product%20Innov%20Management.pdf
Karen
on 07 Nov 07Persona’s don’t have to built from a fluffy 10 data points Check out Steve Mulder’s(Molecular) quantitative persona approach – far more robust and directional.
http://www.practicalpersonas.com/book.html
Simon
on 07 Nov 07Here’s a quick example of how we used personas on a recent project:
One of our clients – a rail operator – wanted to allow its customers to purchase train tickets by phone / online and pick them up at the station on the day of travel. To do so, however, required customers to bring along the credit card they had used at the time of booking as proof-of-identity.
When viewed through our own eyes (as designers / developers / people who travel quite regularly) this all seemed fine…however, upon reviewing our persona docs a problem became immediately obvious.
The notes we’d made when constructing our “Personal Assistant” persona revealed that PAs often booked travel on behalf of the company executives they assisted, and did so using their own credit cards. Thus, had the process described above been implemented as specified, we’d have seen lots of company execs turning up at train stations without a means of collecting their tickets (as they wouldn’t have had their PA’s credit card with them on the day of travel).
Now, perhaps we should have been able to anticipate this problem without need for persona docs…but for one reason or another we didn’t. Most likely because we aren’t PAs ourselves and we don’t employ any PAs at our company. In these circumstances, our PA persona provided a useful “PA-by-proxy”, enabling us to validate our designs more thoroughly than we otherwise would have done – and reminding us to ensure that this users group’s needs were being met as the project progressed.
(Our “Personal Assistant” persona wasn’t made up btw – we job-shadowed ten real-life PAs in order to construct it…which is why it proved so useful later on in the project).
Anonymous Coward
on 07 Nov 07Could’ve seen this flame war coming from a mile away, don’t tell the UCD community that personas aren’t useful ;)
I agree with the camp that they can provide a false sense of security. While people may differ, the tasks they are trying to accomplish don’t really. And depending on who your core persona is, you can really cripple the broader usefulness of your product/service without realizing it.
This doesn’t mean that you should design an air-traffic control system without doing user research, but there are more useful tools than personas for handling the results.
At the end of the day, it’s really about being a good designer. No number of personas can overcome mediocrity in that area, and in fact can mask it since the bad designer can (consciously or subconsciously) tailor the persona to match their level of competence.
Alex Bunardzic
on 07 Nov 07Personas are an old, and arguably very dated concept applied to software development practices in the time when said practices used to be focused on serving the underlying machinery. Back in the 80s and 90s, software development was so finicky and so expensive that no one had the time to stop and think about human users.
Nowadays, thanks to the ‘less infrastructure’ movement which brought us platforms such as Rails, software development is many orders of magnitude less expensive than it used to be only five years ago. Thus, we’re left with more free cycles which we can devote to focusing on the human user experiences when using our software.
Personas were also an attempt to objectivize what is inherently a very subjective discipline—designing a product that will hopefully be viewed as desirable by the targeted market. If there was a way to objectivize that discipline, there would be much more successful businesses around.
This quest for objectivity is, of course, fool’s gold. In that respect, it is true that personas are nothing more than a sedative for people who crave objectivity.
Nevertheless, we should keep in mind that personas have been introduced as a bulwark against the rampant ‘useritis’. In the early days of software development, feature proliferation was singularly traceable back to the ‘wait a minute, what if the user wants to [fill in the blanks]!’ revelations. In other words, the notion of a ‘user’ was utilized to cover up the multitude of crimes. A ‘user’, an abstract human being, used to be dragged in into every brainstorm session focused on software design and development. This nebulous ‘user’ used to be shoved down the development teams’ throats as an excuse for anything, any stale brain fart.
That was a terrible discipline (the one that can probably explain the atrocious state of many software products). To remedy that, we’ve adopted a less abstract, more focused notion of persona. A persona is a construct that it more specific than just a ‘user’. In that regard, personas served a very useful role in avoiding rampant featuritis and scope creep.
However, maybe it’s time we move beyond the cardboard cutouts that we call personas, and into the real, subjective world of human users.
The problem with that is that by doing so, we pretty much surrender our main trump card—abstractions. It will be interesting to see how will this conundrum play itself out in the next 5 to 10 years.
Weixi Yen
on 08 Nov 07After reading this article, I’d like to issue a couple challenge to 37signals:
- Prove that personas and people are mutually exclusive. - Where did it say that we build applications for personas? It seems you referenced this many times vs building for people, which evidently can’t happen if we use personas… - Explain why, in client-related work, personas help detract from a common understanding of users between a client and service provider.
Anonymous Coward
on 08 Nov 07You all don’t use personas? Is that why I don’t use basecamp anymore?
Dave R.
on 08 Nov 07I agree with MT, John, Sam, and Alex. You guys are a bit off on this one. Personas can be designed and used in different ways (do a quick search), some useful and some not. Cooper does a descent job of explaining why his version of personas are useful.
Because 37 signals designs software for other designers and web 2.0 types their opinion on design methods are not always useful to those of us who design for other groups. They don’t have to design for other people, because they can succeed by designing for themselves. They are a unique case.
Sebhelyesfarku
on 08 Nov 07“Personas prevent self-serving, single path applications.”
But that’s the point. 37signals make self-serving, single path applications for themselves and the fanboys.
kma
on 08 Nov 07Personas are meant to be another tool in your toolbox. They aren’t supposed to serve as a substitute for actual users. In the absence of having actual users to tap into, they are good reminder to everyone working on the product who that user is and who that user is not.
I’ve been in meetings where executives bicker over web site language, button sizes and link colors and because they are the execs, they win (even if they aren’t right which 9 out of 10 times, they aren’t). In my experience, personas are fantastic for creating that distance between stakeholder and end-user because that stakeholder may not be that product’s ideal user.
JF
on 08 Nov 07“Personas prevent self-serving, single path applications.”
How’s that? How does a persona prevent anything? It’s not real.
Keith
on 08 Nov 07We have had a LOT of success using personas or “user stories.” The important things to keep in mind:
1 – They need to be based on the most basic assumptions like, “An online banking client wants to transfer funds…”
2 – They need to be backed up by doing a usability study with the personas that you “invented.” If you say a bank manager needs to do x, y, & z. You better get a bank manager to work with a paper prototype at a minimum of your application.
3 – They need to have a defined scope such as, “I will use personas to develop…..” The persona is made up and should never be extended to do more than help you work with creating the core functionality you envision you may need.
I think the place where personas got a bad reputation was when they were used as a justification for decisions that were never tested and slipped into production. Quite simply, a persona helps you role-play when you’re in the initial design phase or consulting phases.
Don’t mistake the made up persona of a user for an actual one. That’s what I think Jason is getting at here…
R. Neal
on 09 Nov 07A good persona should not be a creative writing exercise. They should reflect what you’ve learned about actual users turned into a handy design tool. They should not be guesses on who you think is using a system. That’s a good way to get into trouble—what if you’re wrong?
Jason seems to be reacting to badly designed personas. Personas are as good and effective as the team that builds them. I agree that badly designed personas are worthless, but when done right by a good design team that gets the concept and doesn’t let client politics drive them into the ditch, there is nothing else like them for user-centered design.
We’ve all seen bad personas and read bad advice on how to build them. Usability.gov’s examples are not good. Wikipedia’s description of them is incomplete. That doesn’t make them useless categorically. Personas model goals of users, not laundry lists of tasks. They are based on significant behavioral motivations and goals shared by users who, on the surface, may seem very different. They are not based on job titles. They may seem thin because they don’t model every goal a user may have, but only those that drive behavior with the system you’re designing
Some of the criticism of personas should be piled at the feet of the design team that misused them or made up data to create them rather than modeling real system users. Garbage in, garbage out.
I agree with John Dusek. Personas are a way to “get real” by helping make sense of the goals and needs of crowds of users who are not like you.
Self-referential design can be a recipe for disaster. As Cooper says, you are not your users.
John
on 09 Nov 07I completely agree.
tamara adlin
on 09 Nov 07Well, clearly I’m an advocate for personas. But I’m realizing it’s not about the ‘personas’ as much as it is about ‘shared focus on what the hell you are trying to do.’ Which depends, interestingly enough, much less on data than it does on getting people to expose their sacred cow assumptions and agree on some other way of thinking about what they are trying to do.
37S, you guys are good at focusing together. Most exec staffs are NOT good at focusing together. They are good at arguing. And they can’t stop.
Personas created and ‘thrown over the wall’ by an outside group, no matter HOW data-driven they are, don’t really help. Personas created with a bunch of stakeholders get people transitioned from thinking about ‘users’ and ‘customers’ (which all mean different things to different people at different moments) to thinking about personas (which must be very specifically described by the team and then prioritized by business types) is unbelievably valuable.
You guys are too good at what you do to understand this problem, clearly. Which is a nice problem to have. But if my clients were happy with the results of designing for themselves, which they all have LOTS of experience doing, they wouldn’t be crying over lousy products and sites and calling me.
Personas (as a tool, not a panacea) force execs to answer really hard questions much earlier than they are used to (e.g., ‘what are we trying to build, why are we trying to build it, who do we think will use it, and why on earth would they want to use it?). Once they answer these questions (which otherwise tends to happen when the project is half-done) they can communicate their decisions. If they can communicate their decisions, smart people can build cool stuff.
The fundamental problem that personas solve is that there is no shared language around clearly-articulated business, brand, and customer goals. Shared language and an ability to communicate between teams is the magic bullet. Personas are one of the guns.
Jason Yip
on 11 Nov 07According to Usability.gov’s research-based guidelines, personae have a low level of relative importance and limited supporting evidence.
See item 8 of Chapter 1
So I tend to agree. I’d prefer a person over a persona.
Cliff Gerrish
on 12 Nov 07I’m late to this party, but I’d have to come down on the side of using personas when they’re useful. As with any tool, personas can be used incorrectly or to bolster a particular agenda. The same can be said about using yourself as a proxy for a user. No one tool or technique will get you to where you need to be every time.
The key is knowing your users, eating your own dogfood, and seeing the application through their eyes. But also understanding that all users aren’t the same. They have different demographics, psychographics, and general relationship to using a computer.
If your Web app doesn’t have to work for everybody, then designing into users just like you can work. If it needs to work for everybody, then personas can help you keep the marginal users in mind. Finding the weak signal in a sea of noise—and helping that person accomplish things as well.
eric
on 13 Nov 07comments about this posting then? http://www.grokdotcom.com/2007/11/12/personas-boost-conversion-400-percent/
Len Dierickx
on 13 Nov 07A tool is not a bad thing, personas are not bad, just be careful when and how you use it. I guess that goes for every tool, even if that tool is your own personality.
This discussion is closed.