Using Personas To Discover Requirements

Date: Nov 29, 2002

How do you gather requirements? How do you really find out what people want? Stewart Baird explains how you can use a mix of personas and visual make tools to uncover and generate high-level user requirements.

This article explains how to use persona maps and visual make tools when discovering high-level user goals and requirements.

It's All About Getting Started

A while ago, I was interviewing a prospective employee. We were in the middle of the interview and things seemed to be going well. Then I asked a fairly basic question: How do you gather requirements? Of course, he made all of the right sounds—documentation, requirements, functional specifications, models, and so on. He was rambling on, but my mind was a thousand miles away. How do you really find out what people want? How do you start?

Extreme Programming uses the "Exploration" phase to capture high-level requirements; they are in the form of user stories. How does this work in practice? No single person can be expected to speak for the entire organization; there can be many voices, each singing a different tune or lyric. If you're handed down requirements on stone tablets, you can skip this article. For the rest of us, I'll explain how you can use personas and visual make tools to drive-out requirements.

Using Personas and Make Tools

The approach I use combines a few concepts into a user requirements workshop event. I should come up with a snazzy consulting name for this—playing with toys is what my son calls it. At the outset, I'm interested in goals, both for the organization and the individual. Goals are interesting for a number of reasons; one is that they transcend the tasks that users perform and pull together both technical and business angles. Tasks are the servants of goals, and discovering what the goals are should be the first step. I take personas or user roles through user stories that describe how they interact with features.

One method I use to help users develop their features and user stories is to use make tools. This is an approach that encourages users to design the solution using visual representations of ideas, goals, feelings, and behaviors. They are called make tools because the user is making or creating the solution. This differs from a classic requirements-gathering approach in which users "say" what they want—this might happen in the context of focus group. Visual tools—such as pictures, objects, and models—fit particularly well within Web development, which is a medium in which experience is everything. You could say we are not designing for users; instead, we are designing with users.

Combining persona maps with make tools, I hold a workshop with the following outline:

Brainstorming high-level goals
Creating and decide on key personas
Breaking into groups, taking personas
Fleshing out personas: their goals, features, scenarios and behaviors
Reporting back and refining if required
Summarizing a feature list
Plotting features on a value map

Planning Workshop

I'll explain how this works by walking you through one of my recent workshops. This client is a distance-learning institution with around 300 teachers and 20,000–30,000 students (depending on time of year). I've been retained to help guide their Web developments: Internet, intranet, and extranet. The workshop example here is from the intranet subproject, so my audience includes teachers, support staff, managers, and IT resources. I'll be talking about the goals and needs of the organization because my example has an internal focus; the process works equally well for product development. Your persona will be customer types in the case of an externally facing development.

I call my session a "planning" workshop, even though it is primarily used to gain understanding about high-level requirements. The reason for this is that the output (feature list) forms the input into the XP Exploration and Release Planning sequences. Before the meeting, I communicate the meeting outline and a sample persona map through the project Web site. (By the way, I use the blogger application MovableType to manage the content on the site. You can find this application at http://www.movabletype.org the tool is free for personal use or with nominal charge for commercial users. My content changes every other day or so, and using MovableType allows me to upload documents, as well as gain feedback from the wider user community.)

I asked attendees to bring along magazines (nice ones, please, such as People or Good Housekeeping) and some small toys. Needless to say, a fairly puzzled crowd shuffled into the meeting room at 9 a.m. I was armed with stationary items, including the following:

Large flipcharts
Permanent markers
Multiple colored sticky notes
100 or so clip-art images (printed)
Sticky tape
Blue-tack
Whiteboards (3)
Index cards
Sample persona map

I've included a sample persona map (PDF), shown in Figure 1.

Figure 1 Sample persona map.

The next thing I do after the obligatory introductions is to explain the process: where we're going and what the end result will be. In my case, I also take a few minutes to plot the history of the project. I fade into the background after my PowerPoint show and I remain there through the session, hovering around the groups.

Brainstorming High-Level Goals

I make a start by asking the whole group to list the organization's main goals. These goals include a mixture of high-level corporate goals, department goals, and personal goals. This might take around 15–20 minutes, and can be a very revealing; agendas and biases are quickly seen. It's alarming how many people don't know what the organization's goals are, let alone their personal goals and objectives. A common trend is to confuse tasks with goals. Quite literally, you might hear the following: "My goal is to take customer orders." I try not to be too pedantic here and will let some "false" goals slide by as long as we've captured the key ones. There'll be time enough for fine-tuning later.

The group captures the goal list on a printable whiteboard (use a digital camera if you're stuck). A small but important point is that I don't write these down (yes, I can write, after a fashion). I want the group to own the goals from the outset, so they pick a scribe for the purpose. I'm fading into the background again and only pop up to help guide them from false goals to real ones. Now, we have a list of goals (but even better, the group has heard other staff members express his or her goals).

"Maybe there is a world outside of my department, after all?"

Creating and Deciding On Key Personas

One more task before the coffee break; decide on the key persona for the organization or product. Don't be surprised if silence falls when you ask the group to list personas, even if you have prepared them with samples and presentations. They'll pick it up soon enough, and the hardest part can be getting started. I help them by suggesting the obvious ones; in my case, that would be manager or teacher. Immediately, I have a conflict as the teacher representative's object, passionately so it would seem, to the "manager" persona. Some hangover from a bad experience with a bank manager, I expect.

I'm looking for summarized roles, in which there is some degree of convergence. After 10 minutes or so, we have a list that includes the following persona:

Manager/leader
Teacher
IT developer
Resource developer (research, digital media, and content)
Support (HR, finance, administration, and so on)
Enrollment support

The next step is to break into groups and then to flesh out the personas.

Fleshing Out the Personas

By now, you've probably downloaded the persona sample and are wondering who that handsome mug shot belongs to. I cannot tell a lie; for copyright reasons, I used one of my latest Hollywood shots. Inserting a photograph, even if it's from an online library, is important because it adds to tangibility. You could use "real" photos if you're basing personas on actual customers or users. I have the following areas on the persona:

Area	Description
Profile	Describes personal background, history with the company, character traits, or attributes. Give your persona a name, age, and photo to help form a visual image of the persona. Don't get too lost in developing personal profile information—leave that for your next novel!
Goals	These goals can cover personal, life, experience, departmental, and short-term goals. Emphasis should be placed on experience goals when developing a Web solution. The solution's features should aid the persona in achieving these goals.
Scenario	The scenarios are typical situations in which the users may find themselves as they take steps toward their goals. At times, the goals can seem buried in the scenario because they read more like a series of tasks.
Feature	The feature is the general product feature of functionality that can be used by the user in the scenario. These features are very general at this stage of development: A feature such as "data warehouse" is a complete system. Refining these features can come later as the team returns to the personas during early product development.
Behavior	The behaviors are the way the users interact with the features to solve problems. Solving these problems moves them closer toward their goals.

Breaking into small groups can happen quite naturally as attendees are drawn towards a related persona. In my case, teachers worked on the teacher persona, IT worked on developers, and so forth. This works well with an internal focusing project, but you will need input from your target audience for external product development.

The team is now ready to start working on its persona. But how do you start? Easy: start anywhere, go anywhere. This means that you don't have to work from left to right or from goals through to behavior. Sometimes, you have an idea of a feature, so that is where you start. I encourage attendees to draw a simple 2-by-2 matrix on large flipchart paper (Figure 2 illustrates this). Then, they can use either visual tools or sticky notes to begin to fill in the squares. (I leave out the profile information because it can be easily jotted down at the start of the session.)

Figure 2 Capturing persona data with a grid.

Using the sticky notes approach, group members discuss and brainstorm each of the four areas. You'll discover that each group has its own dynamic, and tends to work on each square until it runs dry of ideas. In the intranet workshop, I see that some groups wrestled with the idea of "go anywhere" and were more content to think linearly—this is fine, too. I came across one group that had trouble getting started; the visualization or imagining part seemed to be a roadblock. My suggestion in this situation is to ask the person to think of himself or herself—they become the basis for the persona and then move from there. Let them ask themselves the following question: "What do I do when I get to work?" This breaks the rule about not focusing on tasks, but do it anyway if it helps to get them rolling.

The most interesting and colorful groups are those that combine the use of pictures and objects to capture ideas. Figure 3 is an overview picture that shows paper divided into quadrants and littered with paper, toys, and objects.

Figure 3 Visual persona map.

Objects such as the hammer also have labels attached to help explain them. (The hammer is something about the "clobbering machine" and refers to the need to get it right or else.)

To give you a clearer view, see Figures 4—7, which are the goal, feature, scenario, and behavior sections of the persona map.

Figure 4 Persona goals.

Figure 5 Persona features.

Figure 6 Persona scenarios.

Figure 7 Persona behaviors.

Although this team is busy expressing themselves courtesy of the toy box, another team jumps right in to interface design. The team members must not have been listening very hard when I explained the "right" way to do it! It turns that they were simply solving the problem from another angle. They do eventually fill in their persona map, but not until they brain-dump all of their ideas. Figure 8 shows the group scribe explaining the modular, personalized nature of their solution.

Figure 8 Describing the persona using features.

After about 45–60 minutes, the teams are beginning to run out of steam, so we pull them back in to report and explain what on earth they've been doing with Mickey Mouse and Co.

Reporting and Refining

The workshop gathers back and we listen while each group walks us through their personas. Each of the five groups has arrived at quite similar sets of features, but from a totally different route. The various methods used by each group fit well within "start anywhere, go anywhere" concept. In part, the methods chosen or favored reflect the makeup of each group; for example, the manager persona group is very focused on solving the problems of information and management. Individuals who normally work alone found that working from left to right on the persona suited them best. And yes, the media guys gravitate toward the visual map.

The lesson to learn here is that you need to allow multiple paths for your workshop to follow. Be happy as long as you walk away with a feature list and a stack of personas.

Next, we move on to summarizing the feature list. At times, you might find that personas are incomplete or serious holes have been uncovered during report time. In these cases you need go back into groups and continue.

Summarizing the Features List

Summarizing the features takes only a few minutes. Do this by asking each group to list its features and aggregate them as you go. I have about four or five "links" type of feature: update links, my links, partner links, and so on. Agree to give these features an easy-to-remember name; otherwise, you'll discover that "update links" are not that clear after all. That's another good reason to work on documenting your personas and findings as soon as possible.

Plotting Features on the Value Map

The last step in the workshop is to take a stab at assigning some kind of priority to each feature. In my case, it is important for the process alone. Let me explain: The client culture is very egalitarian and the expectation is that everyone's features or wishes will be accommodated in system design. Alas, this cannot be the case. So, asking the group to assign a value to each feature sends a clear message that some ideas are more important than others. "You had a great idea, but it looks like its very low in value."

Being a true consultant, I never leave home without 2-by-2 chart, and the value map is a perfect place to use one. Look at Figure 9.

Figure 9 Plotting features on a value map.

We plot these features in about five minutes as time is nearly up on the clock. Are they cast-iron? Not at all. The management team will apply further measurement to them as we continue to refine.

Literally, with seconds to spare, I have features, personas, and values. Whew.

Where to Next?

The workshop succeeds in churning up some great ideas, opens communication, and leaves everyone involved with a sense of direction. Features such as integrated calendar and content management are high on everyone's list, whereas as access to applications sounds cool, but has a less-perceived benefit.

After the workshop, I gathered up each team's notes and converted them into the same format as shown in the sample persona. I also documented the findings in the Product Specification. My documents, pictures, and news are always placed on the project Web site for feedback. Incidentally, the comments were pretty positive; looks like I'll live to fight another day.

From here, we head into the XP exploration phase using the feature list as raw input.

Take whatever ideas you can from this article and tailor them to fit your situation. You might be surprised at the results you can achieve with the use of personas and maps.

My son wants his toys back, so I better go.