Personas

Personas are useful when real users are not available or are too numerous to interview all of them. The persona is a virtual character that substitutes for the human users.

A persona is an invented personality, an imaginary user for whom you are gathering requirements for your product. Why an imaginary character when there are potentially thousands of real users out there? Because, for a mass-market product, you don't know, and can't get to know, all of the real users. But you can know one really well, and that imaginary user's attributes guide your requirements. This is your persona.

You invent your persona, and give him or her characteristics that match the intended audience for your product. Although personas are imaginary, they are an accurate archetype of the many people who would buy and/or use your product.

Why use a persona? When it comes to determining the requirements for the product, it is more effective to have a single, albeit imaginary person as the target user than to try and find all possible requirements for all possible people who might come in contact with the product. Take, for example, the shoes you are wearing at this moment. Unless you are reading this book in a very unusual place, it is likely your shoes were not designed with mountain climbing or ballroom dancing in mind. Nevertheless, there are peopleand conceivably people who would read this bookwho would undertake such activities. So why did the shoe designer design for you and not everybody? Because a shoe suitable for everyone will be suitable for no one.

Now think of a piece of software whose requirements were gathered with a target audience of everyone on the planet. The final product would include so much functionality that finding the actions you want would take most of the day. Its usability requirements would be unbelievably complex and, in the end, ineffectual; its security requirements would drive everyone nuts. Now think of the software you really like to use. You know, that application where it seems the requirements analysts had you in mindeverything works in a manner that seems natural to you, and the functionality does just what you want it to. This software does what you want because its requirements were gathered for someone just like youa persona with your attributes.

Cooper, Alan. The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity. Sams Publishing, 1999. Cooper describes how his product design company uses personas as the driver for specifying new products.

In fact, the book you are reading was written with a persona in mind. Your authors invented a character: Pam is 34 years old and works for Bank of Scotland IT department, where she has been a business analyst for three years. She reads a lot, is interested in her job and wants to be better at it, dislikes people who take too long to say something, enjoys movies and music, is a bit of a gadget freak (she changes her phone every year), and wants to spend more time with her six-year-old son. Precision is important when developing a persona. We found a photograph we thought of as Pam (see Figure 5.9) and taped it to the wall. Whenever we were stuck when writing some part of this book, we would imagine what Pam would want to know about the topic. If you find this book useful and interesting, it is because you have a similar knowledge, background, and curiosity to Pam's. It is not that we don't care about you, dear readerwe just don't know you personally. Conversely, we know our persona intimately and, as it happens, she shares many of your characteristics.

Figure 5.9.

We used a photo of our persona to help write this book.

(Source: Photo Dreamstime/pichunter.)

When we talk about requirements for software, we often speak of "user requirements." The problem with this term is that requirements are gathered for anyone who could be a user. The result is often too many requirements, many of which conflict with one another, and a product that satisfies none of its intended audience. The way to build a successful product is not to gather requirements that mete out something for everyone, but rather to thrill a selected audience.

Norman, Donald. The Design of Everyday Things. Doubleday, 1988. Despite the relative age of this book, Norman's words on clarity of purpose hold true today.

Define your audience by defining your persona. Don't say, "someone in the acquisitions department"; say, "Bob (always, always give your persona a name), 32 years old, has been in the job for 18 months; has a picture of his wife, Terri, in his cubicle, and also has a picture of his hero, Isambard Kingdom Brunel; loves baseball and Bruce Willis movies." Find a photograph in a magazine of someone who you and your teammates agree looks like Bob. Now when you are gathering requirements and cannot get interview time with the real users, ask, "Is this a requirement that Bob wants or needs? Is this something he will use? Or is it just another good idea that Bob will ignore?"

Creating more than one persona may prove helpful because it helps you to think about different viewpoints on the importance of specific requirements. For example, suppose you have another persona called Sally. Sally has ten years experience, is manager of the department, and is very ambitious. She lives in a loft apartment in Docklands and leads a very glamorous social life. She is interested in skiing, opera, and going to restaurants. Do you see how you can already start to know Sally, and recognize that she is not going to agree with all of Bob's requirements? How many personas is it practical to have? We find that a maximum of three personas is manageable and helpful. Any more than that is often an indication that you are trying to please too many people or that you do not yet know the detailed business goals of your project.

A maximum of three personas is manageable and helpful. Any more than that is often an indication that you are trying to please too many people or that you do not yet know the detailed business goals of your project.

Having a persona means that you start to assign priorities early in the project. Once your persona is fully described, your requirements activity focuses on satisfying that persona, with the resultant clarity of purpose and product. The scope is clearer, the usability requirements are sharpened, and it is generally easier to know which requirements you must pay attention to and which can be safely ignored.

After a while, the persona becomes a real person to the team. We worked on a project where the team brought a framed photograph of the persona to every meeting and talked about him as if he were real. That's not unusual. People will refer to Bob in conversation, and the arguments will shift from whether "someone" might use a feature to whether Bob wants the feature. The result is a product with a clarity of purpose and a consistent way of presenting that purpose.