The Agile Modeling (AM) Method

Menu

Personas: An Agile Introduction

Personas, first introduced by Alan Cooper, define archetypal users of a system, an example of the kind of people 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 a bank, potential personas could be named Frances Miller and Ross Williams. In other words, personas represent fictitious people who 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 archetypal 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.

Image of a lady for a personas example

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 lakefront when the weather is good. On bad days, she’ll go with her neighbour 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 she 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 staff (support staff often have a very good idea of what end users need), or talking 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, as they act as “user stand-ins” 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 accessible 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 modelling techniques which you want to have in your intellectual tool kit.

In The Inmates Are Running the Asylum, Alan Cooper suggests the following techniques for writing effective personas:

  • You don’t “make up” personas; you 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.