A persona, first introduced by Alan Cooper, defines an archetypical user of a system, an example of the kind of person who would interact with it. The idea is that if you want to design effective software, then it needs to be designed for a specific person. For the bank, potential personas could be named Frances Miller and Ross Williams. In other words, personas represent fictitious people which are based on your knowledge of real users.You’re likely familiar with actors. Unlike actors, personas are not roles which people play. In use case modeling actors represent the roles that users, and even other systems, can take with respect to your system. For example, in a banking application we would have actors such as Customer and Credit Card Processor. Actors are often documented by a sentence or two describing the role. For example the description for Customer might read “A person or organization which does business with the bank.”Personas are different because they describe an archetypical instance of an actor. In a use case model we would have a Customer actor, yet with personas we would instead describe several different types of customers to help bring the idea to life.It is quite common to see a page or two of documentation written for each persona. The goal is to bring your users to life by developing personas with real names, personalities, motivations, and often even a photo. In other words, a good persona is highly personalized. For example, Figure 1 depicts a persona description for Frances Miller. Notice how it includes a photo which helps to make the persona more real.Figure 1. An example persona.
Frances Miller
Sixty-seven year-old Frances is the mother of four children and the grandmother of twelve. She lives in her own home, bakes a pie once a week so that she has something to serve for Sunday visitors (usually one of her children and their immediate family), and has two cats. The cats’ names are Fred and Wilma, names given to them by four-year old grandson Bobby. She likes to knit and do needlework, which she either gives away as presents to her family or donates to the annual sale to raise money for the church she belongs to.
Every morning she goes for a one hour walk along the lake front when the weather is good. On bad days she’ll go with her neighbor to the local mall where a group of senior citizens “Mall Stroll” each morning before sitting down at one of the restaurants for coffee or tea. For breakfast Frances prefers a cup of Earl Grey tea and two slices of whole-wheat toast with her own home-made preserves. Lunch is typically a bowl of soup or a sandwich and then she’ll have the opposite for dinner.
She is a middle-class retiree living on a fixed income. Her mortgage has been paid off and she has one credit card which she seldom uses. She has been a customer of the bank for 57 years although has never used an automated teller machine (ATM) and never intends to. She has no patience for phone banking and does not own a computer. Every Monday at 10:30 am she will visit her local bank branch to withdraw enough cash for the week. She prefers to talk with Selma the branch manager or with Robert, a CSR who was a high-school friend of her oldest son.
You will want to develop several personas, perhaps seven or eight initially for the banking system, to ensure that you explore all the needs of your user base. To write personas effectively you will need to do some form of user community research to ensure you truly understand your users. You might want to consider holding a focus group with potential users, talking with your customer support people (support staff often have a very good idea as to what end users need), or with product managers whose job is to understand your user community.
Personas are incredibly useful when you don’t have easy access to real users because they act as “user stand-ins”, helping to guide your decisions about functionality and design. Questions like “How would Ross use this feature” or “Would Frances even be interested in this?” can start great conversations within your team, getting you to think the way that your users actually would. Personas are often used when building publicly accessed web-based software, such as the Amazon or eBay systems, as well as shrink-wrapped software. In fact, personas and usage scenarios are very popular at Microsoft and are one of the artifacts described in their Agile MSF process. In short, personas are one of a range of modeling techniques which you want to have in your intellectual tool kit.
You don’t “make up” personas, but instead discover them as a byproduct of your requirements investigation process.
Write specific personas: you will have a much greater degree of success designing for a single person. The “generic user” will bend and stretch to meet the moment, but your true goal should be to develop software which bends and stretches. Your personas should “wiggle” under the pressure of development.
You want to know what the persona’s goals are so that you can see what your system needs to do, and not do.
Sometimes you want to identify negative personas, people that you are not designing for.
A primary persona is someone who must be satisfied but who cannot be satisfied by a user interface that is designed for another persona.
If you identify more than three primary personas your scope is likely too large.
You want a finite number of personas, your goal is to narrow down the people that you are designing the system for.
