(2007-11-10) 37signals Vs Personas

Thirty7 Signals doesn't use Persona-s. We use ourselves... Personas don't talk back... Personas aren't pressed for time. I think that if you write rich and focused-enough personas, you can role-play that kinda stuff. I think it's too easy to believe you're designing for people like yourself, and miss where those other people diverge from your own Context. 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. That's a great idea - the closer you can get to having an Onsite Customer the better off you are.

Back in 2005 Dan Saffer noted that Persona-s are generally done wrong. The main cause of this mess is that half of the personas out there are entirely made up, with no user research to back them. In most cases, no one on the design team has talked directly to users to find out who they are, so designers come up with an idea of a user type. The resulting personas are like the designer's imaginary friends. Without any research to back assumptions, it's easy to end up with a product built for what designers think the users are like, rather than what the users really are like... The differences between personas must be based on these deeper issues - what people do (actions or projected actions), and why they do them (goals and motivations) - and not as much on who people are. It's not that knowing who people are isn't important, it just isn't as important for personas.

Jan'2008: Peter Merholz defends them again. Well, if personas suck, how do I make sense of my user research? How do I build empathy across a product team?

Aug'2008: Steve Yegge attacks Persona-s and all methods of GatheringBusinessRequirements (GBR):

• The thing that might surprise you is that this fictitious (and yet eerily familiar) Case Study isn't just an illustration of how gathering business requirements can go afoul. We're not talking about a failure mode for Gathering Business Requirements (GBR). We're talking about something more fundamental: the GBR phase of a project is a leading indicator that the project will fail. Put another way: GBR is a virtual guarantee that a project is building the wrong thing, so no amount of brilliant execution can save it.

• He draws analogies from Peter Lynch's and Warren Buffett's investing philosophies (e.g. equivalent of "invest in businesses that make products you like to buy" is "scratch your own itch"): Building a product for yourself is intrinsically easier, since you don't have to gather requirements; you already know what you want. And you also know, for any given compromise anyone suggests, whether it will ruin the product.

• You can almost always make a product better by trimming the requirements list (Minimum Viable Product). We're talking brutal triage: throwing out stuff that's really painful to lose, such as the ability to change the battery. If you're lucky, you should be building a product that so excites everyone involved that everyone has an opinion, and you wind up spending most of your time in triage. When you're trimming the business requirements, then you're exhibiting healthy project behavior. This contrasts directly with gathering requirements, which has both the connotation that you're clueless about the product and the connotation that you're inflating the requirements list in direct conflict with schedule, usability and fashion. Trimming: good. Gathering: bad.