Birm here…

Has this ever happened to you? It’s happened to me. You sit down to write an application that looks great and works even better. The UI you’ve designed is a model of esthetics and efficiency. You’ve demo’d it to the developer in the next cubicle and she’s loved it! Then you hand it off to a real-life user and it falls flat. Like a run-over pancake.

When we sit down to code an application somewhere, somehow there is a person who’s eventually going to be using it. Usually that person starts out as -- and too often remains -- a figment of our imagination. What we’ve done is what Alan Cooper calls in his book, The Inmates are Running the Asylum, “bench development.” That’s where the “user” we’re coding for resembles the guy sitting at the next bench. A guy who may be writing another part of the same app as you are, and likely with a vastly different user in mind. Instead of developing applications for one or more well-defined and well-understood personas, that guy and we each go our separate way, never taking the time to communicate and agree on what and who our true user is.

The major malfunction is that we as developers and designers have forgotten a basic, immutable fact: we are not our users.

Enter Personas

When a problem arises that lends itself to a computer solution, there’s usually a specific business need underlying the problem. It follows that there must be a diverse and yet specific constituency for that solution. A computer program useful to a mechanic will be useless to an animal trainer…and vice versa.

A persona is a representative archetype that models the kind of people who will be really using our application. An archetype which is qualitatively and quantitatively validated so that we know that we can rely on it. An archetype described in such detail that every developer on the team feels like they had lunch with that persona just last week.

The first step in creating a persona is to unambiguously decide on what kind of person(s) would be included in the constituency for your application. Then you go find several of those kinds of person and talk with them. You ask them about all the things that would be helpful in designing an application that would be useful for them. For example, what exactly do they see as being their occupation? What are their goals as they perform their work? What information do they need to do their job, and in what form? What are their day-to-day frustrations and pain points? How, and with whom do they communicate to get things done? What you end up is a list of characteristics and attributes that you consolidate into one or more personas.

One final thought: to create a persona and to create fiction are two disparate things.  For a persona to be reliable and actionable, it must be a truly representative archetype, with nothing about it pulled out of thin air.  You can consolidate characteristics and attributes, certainly.  But they must first actually exist in the group of people you interviewed to get the data to create the persona.