Personas, Scenarios and Stories, Part 1

Personas are a tool to develop an understanding of a user’s needs. There are a number of ways personas can be used as teams develop and deliver value. The well-trodden path between personas and value is through user stories. The most effective way to navigate that path from personas to stories is using scenarios as a stepping stone. In the following two essays we will walk through a process to create personas, scenarios and user stories using the example of a beer glass logging app we have used in the past to describe Agile testing. The example is not meant to be complete, but rather to illustrate of the process the path form personas to user stories can take.

Generating Personas

Many articles on using personas to generate user stories begin with a step that is very close to saying, “get some personas.” When Alan Cooper introduced personas as archetypical users of the product or system being developed, he indicated that personas were to be generated based on research done on target or audience of the product. Unfortunately with out guidance on how to create a persona the idea of doing research has gotten lost. What most people need is a lean process for developing personas. A simple process flow to develop personas is as follows:

1. Brainstorm an initial set of potential personas
2. Gather data through research and interviews
3. Refine list of potential personas
4. Create the initial persona profiles (use template)
5. Review, sort and prioritize personas
6. Finalize (-ish) personas
7. Post or share personas

Step 1 Gather a cross section of the parties impacted by the system or product. For small teams I generally recommend using the Three Amigos (product owner, lead technical and lead testing personnel), while in larger projects with multiple teams the group tends to grow to include product owners and leads from each team. Use one standard brainstorming technique to generate an initial set of personas. This list will be refined as the process progresses. Common seed questions for the brainstorming session include:

1. What type of people will use this product or system?
2. How will this product or system be used?

The goal of the session is to generate an initial list of persona names; however these sessions typically expose a huge amount of information. Write everything down; it will be useful later. The list of personas will not be perfect, nor will it be complete. Do not be concerned as the process uses a review and refinement process to ensure the end product is solid.

Step 2 Gather background information using the initial set of personas as a guide. Research can take many forms, including behavioral surveys, interviews and accumulated team knowledge. If you are going to use surveys to collect data to enhance your persona and you going use the data for product decisions, hire a market research firm or organizational psychologist to construct and execute the survey. The most common technique for internal IT projects is interviews. The technique is fairly easy, cheap and generally effective. I recommend creating a formal set of questions before beginning the interview process. The goal of all of the research techniques is for the team to develop a deeper understanding of users and how they will interact with the system.

Step 3 Refine the list of potential personas. Synthesize the original list with the research gathered in step 2 to update the list of personas. The consolidated list should weed out any personas that show substantial overlaps and expose gaps in the original list. In circumstances where the team does not know much about the system or product being built step 1 many not be possible until research is done therefore step 2 may be the entry point in the process.

Step 4 Create the initial personas by filling in the standard template we documented in Personas: Nuts and Bolts. I generally find that the process of completing the template continues the refinement process by identifying gaps and overlaps.

Step 5 Review the personas with the WHOLE team(s). Use this step to continue the refinement process and as a mechanism to add detail to the descriptions and behaviors documented in the template. Do not hesitate to add, change or delete personas at this stage. In larger projects with multiple teams begin by doing individual team reviews then consolidate the personas based on the input. The review process allows the team to share a broader perspective. A whole group review also creates a common vision of “who” the product or system is being built for.

During the review process prioritize the personas. Prioritization reflects the truth that not all personas are created equal, and some types of users are simply more important to satisfy. Prioritization provides the team with a mechanism to make decisions. Some of the personas represent critical stakeholders and others represent those that are less involved. Consider using a 3 level approach, with the top or primary persona being the most important to satisfy. The second level persona is important but not as important as the primary persona. I often find personas at this level provide direct support to the primary persona. The final category of personas is involved, but perhaps in a secondary support role. For example, a pilot would be a primary persona for an airline flight, the ground crew would be a secondary persona and the TSA agents would be a third-level role.

Step 6 Develop an agreement across the project that the personas that have been captured make sense and are as complete as they can be at this point. Always recognize that the personas can evolve and change. The act of generating a public agreement helps teams (or teams of teams) start on the same page.

Step 7 Post the personas on the team wall so that everyone can use them as a reference. In distributed teams post the personas on the wall in each team room and one the team’s homepage (Sharepoint, WIKI or any other tool being used).

Here is an example persona based on the Beer Logo Glass tracking application:

Persona Name: Tom “The Brewdog” Pinternick (primary persona)

Job: Day job is QA manager, but at night he is a home brewer.

Goal: As a home brewer, Tom likes to visit microbreweries to get a broad exposure to different styles of beer. To mark visits to microbreweries, Tom buys logo pint glasses. Logo pint glasses can be expensive and it does not make sense to collect the same glass twice, therefore he needs to make sure he keeps track of the glasses he has purchased.

Personality: Brewing collectables, including pint glasses, is a badge of honor. Microbreweries without logo pint glasses are an anathema to the “Brew Dog.” A visit without evidence is a visit that never occurred (regardless of memories).

Lifestyle: Tom “The Brewdog” Pinternick lives with his foot on the accelerator, whether family or work, he tends to be single-minded. The balance between work, hobbies and family is important, but so is keeping score.