37signals: Why personas aren't useful

This argument is a bit like saying that a novel is just words on a page. The question is not what it is, but how you do it.

I've always understood personas to be one side, the designer side, of human-centred research-based designing. They were never intended to replace empirical research of real people. They were intended to help designers make the findings that emerge from research of, or with, real people, into design-able-from findings.

To this extent they are an attempt (not a fail safe one) to bridge designers and the humans they are designing for. What needs to be bridged is the fact that:
1) non-designer humans tend not to be able to say what they want in design-able ways
2) designers tend to sometimes not hear well enough what is being said to them by non-designer humans, no matter how real the source (if they do, they do not need personas)

Personas make the designer become the humans they are designing for, allowing the latter to talk in more design-ready ways (dealing with 1) and forcing the former to be less egotistical (dealing with 2).

This means however that in the end personas are only ever as good as the acting skills of the designers impersonating the personas while designing. If the designer manages to become the persona, then designing become a live dialogue (not an asynchronous one with previously recorded or summarised data, ie dead data). Personas bring research to life precisely so that the research talks back, has opinions, gets frustrated, in ways that are relevant to designing.

It might be hard to argue with - but I did anyway. =)

http://uxsoapbox.blogspot.com/2007/11/37signals-doesnt-like-personas.html

It must be great to work in an organization where you always get to test things with real users. Unfortunately, for those of us who work in the real world, our personas are often the only proxy we have for the user after our initial round of interviews are over. They are imperfect, and they are not very useful for usability testing. But, as a way to work against a concept, they can be incredibly useful.

Personas, ultimately, serve as a kind of reminder of the user, less effective than actual users, but helpful to "have in the room" when no users are available.

Well, actually I don't find it that hard to argue with at all. Personas are yet another tool at our disposal, and an interesting way to ground the common characteristics of your target audience into something less abstract and artificial. When you do them properly, meaning you start with real customer research, they seem to provide pretty good value in keeping design and architecture discussions focused. They are not and never will be a replacement for many of the other evaluative tools in the practitioners toolbox (like actual usability testing).

Also, I think 37signals has a somewhat less-common position of, as they put it, "building products for ourselves to solve our own problems". I would say most of us in the industry are not building those types of applications or sites, and therefore it would be entirely wrong-headed to use ourselves and our issues in defining the product.

Finally, one thing that I try to do with personas is to use them as a basis for customer feedback and testing recruitment. It helps to circle back around and validate the personas that are created based upon analysis of the original customer research, and so far has proven to be a pretty effective way to describe participants for recruiters.

I agree with those who say personas are just another tool in our toolbox, and should be used when and where it makes sense.

However, I also have to say that the very vast majority of personas I've seen have not been particularly actionable. I talked to one designer recently who was laughing hyterically about an immense cost a consultancy charged to develop personas for his company. For an enterprise software product, the personas included information such as what kind of cologne the system admins wore and what his eye color was (green)!

I've personally seen several personas where the user's goal was described as something like "going home on time." Uh, no kidding?

All of us, whether our role is design, research, content, development, have internal and external customers that need to act on information we provide. "Fluffy personas" do the industry, and our clients, no good. Those who develop personas should make sure the information they're providing can be acted upon by the target audience for the personas (designers? developers? marketing? others?) and can inform product decisions.

That's like saying, "Why gather requirements? They're just textual, abstract, and static. They don't respond, they don't click, they don't talk back..." (and some say this very thing, but that's another rant) Saying the same thing about personas is just as ludicrous.

Personas, just like requirements, are *meant* to be an abstraction of a lot of complex concepts. They are a communication tool to help us poor humans understand what other poor humans want and need. They do not take the place of the conversation, nor do they take the place of live feedback on real systems. They are both a step to help us understand others, and get to the place where we have a functioning and effective solution to a problem.

As with requirements, as others have pointed out, if you don't do them right, then they will be worse than useless. But if done well, then they are a huge help in getting us to the goal. Sounds like someone's never actually created or used one correctly. :-)

Andrew M.

The best use of personas, in my mind, is to help new designers and product managers understand what the people who are already intimate and experienced with the product and audience already know. They are good for getting your new employees ramped up (especially those in the periphery who are unlikely to ever spend a moment looking at audience demographics or user research), and it's great for making sure that design consultancies aren't misinterpreting your audience and aiming at the wrong target.

When I do personas, it's explicitly for this latter reason, for letting me and my team understand my clients' users and audience in a quick and effective way. Emphasis on quick: I've never worked on a project where we've spent more than a week or two on personas, and I've worked on more than a few where the entire exercise was completed in a single day of conversations with the client.

Like Jason, and maybe you, I'm generally skeptical of their usefulness, but for this one purpose they're pretty great.

I'm with you on this one Mark. I've seen a lot of time wasted developing personas, which are very often shelved and not referred to, or with each new project, details are added to the personas until they are no longer realistic. They turn out to be super-hero like combinations of customers marketers wish existed, rather than real customers.

But the intention to know your customer is a good one. What to do?

Don’t create fictional customers. Use real, actual customers. Write up a profile for one customer in each of your segments. Change names if you have to, but keep the other details real.

Actually, what someone described as "fluffy facts" can be very useful. The example cited as fluffy was that the audience liked to leave work on time. Actually, this came up on a project I was on. Our client assumed their audience liked to stay after work to do research on products and services, as this had been the case historically. In fact, a new generation of customers we interviewed told us they valued going home more than staying late and doing research, meaning we had to incorporate research data into the primary user experience, rather than as a separate item to be done later.

Point being: what seems fluffy might actually be useful. Eye color? Probably not.

If indeed personas are fictitious then it's hard to argue that they're useful. I tend to agree that most efforts in creating personas are wasted because no proper contextual research has been done on which to create them. But if you spend the effort to read the original research documents on personas, and spend the effort to create them based on real data, then they are NOT fictitious and therefore can serve the purpose for which they are intended.

Two points:

• If persona is written for a person that does not really exist, it is the wrong persona.
• 37Signals is being a bit disingenuous. Their applications scratch their own itches and are intentionally feature light. In such a scenario creating explicit personas does seem redundant.

Jared Spool nailed this one. Briefly:

37 Signals are their own users, so they do have real user insight without personas. This is a rare luxury.

Bad personas are worthless. Good personas require research and are beneficial.

This is a great thread - here are some thoughts

37Signals does have a great luxury and they seem to know it and are trying to make the most of that situation - their agile approach and culture seems very Googly (sp? I am not)

Simplification seems to be one of 37signals driving design goals - that makes sense since collaboration doesn't happen without usage and a combination of a simple + the web might be enough to win over a base (sounds like an approach you can use when migrating horizontal activities to the web, think: gmail)

37Signals is a company that is automating their business problems and finds an audience that is happy to adapt and buy into their solution - this is not the same design context as what Best Buy faces when trying to design say... a new and relevant multichannel customer experiences to win over busy moms (on Black Friday) in a commoditized and competitive B2C landscape.

As their application spreads across multi industries (and they are no longer solving problems for themselves) , they may benefit by drilling down into their new users to identify was to simplify and add value

regards,
Vahe