- It's All About Getting Started
- Using Personas and Make Tools
- Planning Workshop
- Where to Next?
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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.