How To Create Personas for Goal Driven Development

How do we create personas?

We mentioned the creation of personas in our overview of the interaction design process. In this post we will talk in more detail about how to create them. We will cover identification and prioritization of the personas, defining the practical and personal goals for the personas, and creating the anecdotal stories that give each persona an identity against which we can make design decisions. Scenarios are also defined for the primary personas, which drive the creation of the functional requirements specification.

Identifying the personas

The first step is to identify who all the users of the application will be. For enterprise or corporate (internal use) software, this process is pretty straightforward. Identify the roles that are expected to interact with the software (sales, tech support, accounting, engineering, etc). Then figure out if there is a homogenous population within each role.

For example, tech support may have tier-one support (users who are measured on call-throughput, and start with “is the computer turned on?” questions) personnel and tier-two personnel (the people tier-one support calls in <5% of their calls, when the tasks are too complex or too involved for them to resolve). Tier-two support people may have a very different interaction with the software, as the problems they are addressing have already been vetted (and probably don’t have an answer in the online database).

The tier-one folks may have interactions that are primarily customer-relations and look-up-the-answer scenarios. The tier-two folks have much more of a trouble-shooting role, and may primarily do external research to find solutions, and also add new solutions to the database of known solutions. If the roles are significantly different, then create seperate personas for each.

Defining the practical goals

The practical goals for a persona are the goals that our representative user needs to accomplish for his employer. The employer has corporate goals, and an individual persona will have a set of relevant to them practical goals that represent how they help achieve the corporate goals. Gaining market share, increasing profitability, and growing profitability are all great corporate goals. These goals, however, are too nebulous to be actionable.

Our tier-one support person, call him Jim Turney, may have a practical goal of handling 15 support calls per hour. Our tier-two support person may have a goal of addressing 90% of her calls without deferring to tier-three support.

Defining the personal goals

The personal goals of each persona represent the motivations of the individual. These goals are distinct from corporate or practical goals. “Don’t feel stupid” and “Get a promotion” are personal goals. These goals help to identify the individual, and provide insights to the designers that help them design the most intuitive, usable interfaces for the application. All users are not created equal, so it is imperative that we capture the essence of the persona using the computer before attempting to design the perfect user interface for her.

Defining scenarios

Each persona will have a set of scenarios that represent the activities that they perform with the software we’re designing. We don’t capture every activity that the user performs, only those that involve interaction with the software. The frequency of occurance of the scenario is represented by classifying the scenario as daily-use, necessary-use (infrequent, but required), or edge-case (very unlikely to occur).

We previously explained the categories as follows:

• The edge cases are immediately discarded by the interaction designer – these happen so infrequently that the penalty of enabling them outweighs the benefit. The penalties are not just measured in implementation costs, but costs to the user of having to understand, ignore, or otherwise work around the added capabilities needed to support the edge cases.
• Necessary use scenarios are scenarios that must happen, but happen very infrequently. The requirements specification will include the functional capabilities needed to support these scenarios. Interaction design effort will not be spent on optimizing these scenarios, however. The theory is that since they are so infrequent, users will tolerate whatever implementation exists to make them happen.
• Daily use scenarios are the ones that the primary persona performs most often. Most users will have one or two daily-use scenarios. More than three is rare according to Cooper. This is where new users must get up to speed the fastest, benefits from good design are reaped the most, and the lion’s share of interaction design effort is applied.

The daily-use and necessary-use scenarios drive the functional requirements specification.

The daily-use scenarios drive investment in interface design decisions.

Prioritizing the personas

After we’ve created the personas representing all of the users of the application, we must select the primary persona. We will design the application for the primary persona. We can make this selection based upon the inherent value of the persona’s practical goals and their associated scenarios. We have written previously about using ROI to prioritize requirements with value-based prioritization. We can apply the same general techniques to selecting the primary persona.

The practical goals of each persona represent their personal ability to help the company achieve its corporate goals. Corporate goals are enabled via the practical goals. These practical goals embody the particular business processes that are being created, enabled, or improved with the new software project [background on software migration projects]. Each persona achieves their practical goals through scenarios. The frequency of each scenario can be combined with the number of users represented by a particular persona to identify the magnitude of the impact. A project that will reduce the cost of submitting a quote by $1 per quote, for example, is worth $1,000,000 per year if 100 people each submit 50 quotes per day.

Select the persona who’s practical goals represent the greatest impact on the corporate goals. Another way to think of it – pick the person who stands to benefit the most from the software.
Creating a sense of identity

There are two ways that we create a sense of identity around a persona. First, find a picture of a person that superficially has the characteristics of the persona. This becomes the face of the user. Or find a picture that “matches” the name you give the persona. The following pictures might represent a tier-two tech support person and an executive assistant. Pick a face that represents the persona to you.

The second thing we do is tell stories about the persona. The more detailed the stories, the better. Relevance of the story to the software is irrelevant. What we are trying to do is characterize the individual in a way that will inspire good design decisions. We might write a story for our tier-two tech support person as follows:

Sam is an avid video-game player, and values the level of knowledge she has about her favorite games. Sam reads all the forums, knows the cheat codes, and plays the games against herself. Sam’s latest trick, to save time, is to focus on perfection. Sam plays Galaga, but only plays the first level, and tries to achieve a greater than 100% hit ratio for shots fired (which is possible only if she gets a ship captured and can kill two aliens at a time). Sam is also an avid frisbee golfer, and plays every Saturday with a regular team. Sam’s also the one who keeps a website running with all of the stats and schedules. The only thing Sam doesn’t like is talking to new people. Sam’s friends describe Sam as someone who ‘takes a while to warm up to.’ Sam would much rather answer someone’s questions on a forum than over the phone.

How do we use the personas?

We use the personas to identify the primary user(s) of our application. These users drive the development of requirements and features needed to support the persona’s daily use scenarios. Interaction designers will also use the details of the persona (captured in stories and personal goals) to drive design decisions in the creation of the user interface, and more generally the interactions that the user will have with the software.

We often rely on the persona to prevent internally-driven scope creep. When a team member suggests that someone may want to browse the database of tech-support call logs, organized by the tier-one person who received the call, we can respond that Sam wouldn’t do that. And if Sam would not do it, the software won’t do it either. This is a great technique for focusing on the most important requirements.

This focus helps us create software that helps the most important users achieve mastery of the software the fastest.