What's a Persona? Ask Erik

The first book that I co-authored (Complete Systems Analysis, Dorset House, 1994) took almost ten years to write. It could have taken longer if we had not stumbled upon a way to focus our efforts and finish the book. Our problem as authors was we kept trying to include more and more new ideas and discoveries, and to include a wider and wider readership.

We had conversations like: "I think we should include all the different notations for data models, after all there are lots of analysts out there and they need to know all the possibilities". "Yes and we should explain all the different viewpoints we can take of business processes and how we can represent them". "And don't forget the project managers, we need to make sure we cover their concerns". Each conversation increased the scope of the book and, as a result, our direction grew more and more uncertain. In the end our problem was solved by a fortuitous accident.


Suzanne Robertson Suzanne Robertson

On a flight to Denmark, whilst idly leafing through the airline magazine, I came across a picture of a pleasant looking fellow standing in a factory next to a pallet of cartons containing fruit juice. This fellow was neatly dressed in a shirt and tie and was wearing the wire-framed glasses that look so good on Scandinavians. His expression was kind and interested; he looked like someone who would be a good communicator. Not too high powered, a practical person who wants to get things done. In short, he looked like the systems analyst for whom we should be writing our book.

I decided that his name was to be Erik, and thus he became our persona.

We kept the photo of Erik on our notice board. Now, whenever we reached an impasse — will we or won't we include it? What's the best way of explaining it? — we would look at Erik's photo and imagine what he would want. Given the way Erik needs to work, will this be helpful and relevant? Or are we diluting the benefit of the book by including a topic that has little interest for Erik?

Erik became very real to us as we imagined his life: he lived in Jutland, had a wife called Mette, two sons and a dog. His hobbies were hiking, carpentry and listening to jazz. At first glance this might seem a trifle crazy — talking to an imaginary person in order to make decisions about a product — in this case a book. But the technique proved very successful and, with Erik's help, we finally produced the practical workbook for systems analysts.

Recently I realised that our "Erik technique" is used in the fields of marketing and product development to determine the best set of features for the intended market. The product developers use interviews and observation to gather preferences and behavioural data from a representative sample of the market. Then they analyse that data looking for clusters of preferences. Each cluster forms the basis for inventing what they call a persona — a real person with a name, goals, environment and personality. In his book The Inmates are Running the Asylum, Alan Cooper describes how his product design company uses personas as the driver for specifying new products. We can make use of many of these ideas to help discover the relevant requirements for software.

Requirements for a software product are often referred to as "user" requirements, and subsequently requirements are gathered to satisfy anybody who could be considered to fall into this category. The result is usually that we end up with too many requirements, many of which are in conflict with each other, and a product that often satisfies none of its intended audience.

The concept of personas takes the opposite approach. Instead of trying to please anyone who might fit into this generic "user" category, the persona represents an imaginary but specific person with specific requirements. Having a persona means that you move your prioritisation to the beginning of the project. Start the project by bringing to life the specific persona for whom the product will be built, then your requirements activity is focused towards that persona, with the resultant clarity of purpose and product.

The act of defining the persona involves the key stakeholders, and means that you make some critical choices before going into the detail of requirements. There may be more than one persona ­ but more than three is an indication that you might be falling into the trying-to-please-everyone trap.

Keep your persona (a drawing or photograph, and a summary of their characteristics) with you. When you are stuck, use him or her to guide your decisions. Ask your Erik — do you care about this requirement? What benefit will it give you? How much does it matter in your environment? The remarkable thing is the project stakeholders very quickly start to treat Erik as a living breathing human being. But maybe it is not so remarkable after all — we like to know people and to communicate in a practical and realistic manner — Erik helps us to do that.

— Suzanne Robertson, London