8
Traditional Contextual Design Models
Abstract
The Traditional Contextual Design Models introduced with Contextual Design are still viable and offer insight, but we have found that we rarely use some of them. In this chapter we discuss the Traditional Models that we do use regularly and their variants: The Sequence Model; the Decision Point Model, derived from the Cultural Model; the Physical Model; and Personas.
Keywords
As-is model; Business analysis; Cool concepts; Data visualization; Design; Design thinking; Ethnography; Human–computer interaction (HCI); Human–machine interaction; Marketing; Mobile design; Personas; Product design; Requirements elicitation; Requirements gathering; Scenario-based design; Scenarios; System design; Usability; User-centered design; User experience; User research; UX; Work models
The Traditional Contextual Design Models were introduced in the first version of this book. As we said in Chapter 5, they were designed when teams were composed primarily of developers to help them understand the human context of a task, generally for business. The models use a visual language borrowed from modeling approaches familiar to developers and so were easily adopted by them. Developers liked the detail of the users’ world and wanted to dialogue with it through their own inquiry—not the summary of a UX professional.
But the field of UX grew, and teams and communication styles have changed dramatically since then. Products and the scope of products have also changed. Our use of these models has changed too. Some we have honed to make them more accessible and focused. Some we use rarely—but they are still useful for some projects. And some we still use regularly. Here we touch on some of the traditional models and their use. For more detail on the original models and their consolidation, see this website: http://booksite.elsevier.com/9780128008942. The Traditional Contextual Design Models are:
The Cultural Model captures the cultural influences within a population which affect the target activity: formal and informal policy, business and legal influencers, interpersonal friction, and values which affect choices. It reflects the constraints and support people feel while doing the activity. The Cultural Model is valued by teams representing their internal organizations for IT system projects. Today we usually represent cultural aspects that the team must consider in notes in the affinity or with the Decision Point Model. We won’t describe the classic Cultural Model here.
The Decision Point Model looks at the influences that affect a key decision. Where the decision is critical to the project focus, it provides a good summary of the factors that must be considered.
The Physical Model captures the structure, use, and particular insights about the environment within which the activity takes place. It is important when the product is a physical environment such as a vehicle, when it lives in and interacts with the physical environment such as a device or appliance for a home, or when designing a service or technology which lives in real space, for example, a retail environment.
The Flow Model is used to represent complex processes such as those within enterprises. It highlights the roles and responsibilities multiple people take on while they coordinate within a work process. It is still relevant for complex processes and brings insight when collaborating with process reengineering efforts. But the Collaboration Model discussed in the previous chapter has replaced it as the representation of choice for revealing communication and coordination of a target activity. We won’t describe the Flow Model here.
Personas were not one of the original Contextual Design Models but have become popular. They are used to characterize the behavior, values, and attitudes of the target population as a set of archetype characters. We describe how to create them from rich field data in detail in Rapid Contextual Design.1 We’ll touch on them below.
Traditional Contextual Design Model techniques for consolidation are guided by the same principles as the Affinity Diagram and the Experience Models: use induction, label groupings to evoke story thinking, consolidate into a background structure, and create a graphic guided by principles of communication design. You will see, however, that as a consequence of when they were designed and who they were to be used by, the communication design element is much more basic than the new Experience Models. Feel free to apply a more exciting graphical treatment when they are important to helping your designers understand the data. We discuss the traditional models we use now below.
The Sequence Model
The Sequence Model is a basic task analysis, capturing users’ actions while doing a task. Many teams create these models to guide detailed design. Sequences help define the scenarios of use that the product must support and identify lower-level usability issues. They are not “big picture” models that help open up innovative thinking, the way the affinity and experience models do.
Sequences represent the way people do a task or accomplish an intent. Activities are ordered; they unfold over time. The steps people take aren’t random—they happen the way they do because of an underlying intent or habit of the user. They start because something in the user’s environment or inner experience triggers them to act.
A commuter pulls into the parking lot at his office, but he doesn’t get out of the car right away. Instead, he pulls out his phone and spends a few minutes checking messages and Facebook. It’s a break, a quick check-in, before diving into the business of the work day. And it helps him clear away any quick requests.
Watching the detailed actions people take in doing a task reveals their strategies, their intent, and how tools help or hinder. Understanding the real intent is key to improving any practice—you can redesign, modify, and remove steps as long as the user can still achieve their underlying intent. An intent is stable: people have had the intent of communicating over a distance for ages. The steps, the way that intent has been achieved, have changed over time—from hand-written messages to email, the telephone to mobile phones, videoconferencing to Skype, instant messaging, and so on. Our inquiry when collecting, interpreting, and consolidating sequences is to find the core intents implied in the steps.
Our design challenge is to help the user achieve the intent more directly and recognize how technology might help or get in the way. If doctors look at their email and calendar in the parking lot to see what is coming up in their day but the electronic medical system won’t let them see it directly, an opportunity to delight the user will be missed.
Collecting the data
Collecting the data for a sequence is easy. Just watch the activities targeted in your project focus and write each step down in order as they unfold. Or during a retrospective account, write the steps as you hear them—leaving space to write in steps you find out about later, because you’ll get them out of order. Remember to pay attention to the overall intent of the task and the intent of each step. See if you can find the trigger—what got the user started doing the task. If you see breakdowns in the practice, put in a lightning bolt breakdown sign.
Remember, in real life people do things in liner order—no looping, no alternative strategies. These will come out in consolidation. So write it all in order. If you hear about alternative ways to do the same things, just note it in the margin of the page.
Sequences may be studied at any level of detail, from the high-level activities to accomplish an overall task, to the detailed interaction steps with a particular user interface. For new product concepts or feature sets, capture steps at the level of the action. Only capture observations at the level of the clicks for a project focused on usability fixes.
Capturing during the interpretation session
Sequence Model capture during the Interpretation Session is straightforward: Capture every step as it happened just as you did during the interview, putting it on a flip chart or into a document. Don’t just write up your notes in advance—capture the steps while speaking them to the team. Their questioning will trigger more memory, identify more intents and breakdowns, and truly share the events with them. See the example sequence (Fig. 8.1) from the Travel Project.
Remember the steps don’t usually come out in perfect order, particularly with retrospective accounts. Triggers and intents may require some discussion to identify. If the interviewer discussed intents with the user, it’s easy—just capture them. Otherwise, the team may identify intents which are clear from context even though they weren’t captured in the interview. The interviewer is the last word on whether an intent really was experienced by the user.
Consolidating the data
As we have been discussing, every Contextual Design model represents the structure of the practice from its own point of view. Fig. 8.2 is a partial consolidated sequence to illustrate the idea. It’s enough to show how the structure is revealed in the levels and colors.
• The Title of the sequence tells us what it is addressing. Most projects benefit from 2–8 sequences defining the things people do in service of the target overall activity.
• The green bar denotes an activity chunk within the overall activity—a set of steps that hang together to achieve a coherent intent. The first activity section—“Have idea for trip” in this case—shows the triggers for the sequence as a whole.
• The blue steps are consolidated step (or trigger) descriptions. These step labels are generated by collecting similar observations from across all users doing that same activity, just like bringing notes together under a blue label in the Affinity.
• The pink notes are the intents, placed next to the step that achieves that intent. Intents can also go with the activity—put those right below the green bar.
• The notes with lightning bolts are breakdowns.
The process of consolidating a Sequence Model is much like the Affinity Diagram. Analysis of the specific sequences reveals the activities that comprise the action of the sequence (Fig. 8.3). So if we look at our captured sequence above, we can see the activities within it:
It is helpful to consolidate 4–6 sequences on the wall to get the basic structure and then check the rest for additions. Once you find all the activities by looking at these sequences, put them in a reasonable order that reflects the data. Now you are ready to consolidate steps into them.
Working with one activity at a time, look across the individual sequences and group the specific steps into abstract steps. Write the abstract step to describe what people are doing, as in Fig. 8.4.
Figure 8.2 This is a partial view of a consolidated sequence from the travel project. The green bars mark off activity chunks; they contain blue consolidated steps with their associated pink intents and red breakdowns. Backing up the blues are the actual steps from individual Sequence Models which defined that step.
Figure 8.3 The actual sequence model from U06 with activity chunks identified, ready for consolidation.
Consolidate the abstract steps in each green activity, including their intents and breakdowns, and add them to your emerging model. When there is more than one way to do the same thing, you have found a branch. Branches may indicate that different users have different strategies, they may be options based on intent, or they may simply reflect different situations (Fig. 8.5).
Repeat for the other activities, check the other individual models and add additional data, and you are done!
Figure 8.4 A set of steps from different sequences all doing essentially the same thing being consolidated together, and the consolidated step written from them.
If a small teams work on parallel sequence, consolidations in the same room they will be available to each other for consultation and sharing the data while they work.
Communication design
Sequences are steps of an action in order; designing for a Sequence Model means changing the steps and giving people better ways to achieve their intents. So put your consolidated sequences in a graphic tool such as Visio. You may show only the abstract steps or you may pick representative observations for each step to bring home the real experience and keep the sequence grounded.
Figure 8.5 Consolidating a branch. Here, we’re using a spreadsheet so the different strategies are laid out vertically. On the wall, we’d be using sticky notes, and they’d be laid out horizontally.
For the most part Sequence Models are a tool for design, rather than something that inspires new product concepts. The detail, the intents, and the strategies in a Sequence Model are a good guide for storyboarding and detailed design: don’t design out things that work and do overcome things that don’t. Support every intent, even if it is in a new way or with new technology.
The level of detail in a Sequence Model can sometimes overwhelm the team—but they are great for making sure that the I’s are dotted and T’s crossed when you are doing detailed interaction design.
Decision Point Models
The Decision Point Model has superseded the Cultural Model we introduced in the first edition of Contextual Design. The Cultural Model reveals values, standards, constraints, emotional and power relationships between people and groups, and how they all intermix. It is the only Traditional Contextual Design model that concentrates on feelings and how different people and groups influence each other. The influencers in culture must be taken into consideration when designing.
For example, in one profession we studied the people said they never worked at home—that they worked so hard during busy season that they actively avoided work at home. This was their cultural value. But a close look at their life revealed that, nevertheless, they did check email, respond to critical requests, and prepared for the day using their mobile devices—they just thought they did nothing! Knowing this helps our clients think about market messages and what kind of mobile support will be accepted by a culture that denies its use.
In the past, we would have captured this data in a Cultural Model, but because we are now designing for life this data is naturally captured in the Affinity Diagram, in the Day-in-the-Life Model, and as Identity Elements. Since the new models are capturing feelings, values, motives, and their impact on behavior the Cultural Model is redundant.
Today, we do not use the Cultural Model very often,2 but we do use a variant: the Decision Point Model. Companies want to know what influences choices—to buy a product or service, to stay in school or leave, or to choose one delivery option over another. It can be interesting to see all the influences on a choice brought together in one diagram.
The Decision Point Model is a very simple model with a simple structure. At the top is the decision to be made. Influences on the left of a center line push the person positively toward making the choice; influences to the right of the line push the person away from that choice. Once a company sees what is influencing the decision they can decide how to design their product, service, or market message (Fig. 8.6).
The Decision Point Model is easy to build and consolidate. In the interview, collect data about what influences a choice. In the Interpretation Session, capture the influences as they appear over the course of the story. Then consolidate the influences, bringing together the ones that go together. Write a phrase that summarizes the influence in the language of the user, in the same way as a blue label in an Affinity. Finally, choose which influences are most important to raise up to the team if there are too many. Put it online and you are done (Fig. 8.7).
The Physical Model
Life happens in a physical environment which either supports and enables activities or gets in their way. Luckily people are adaptive. As they live their lives within a car, when they shop in stores, when they work in their office space, they tailor how they do an activity to fit the space and they rearrange their spaces to best suit themselves. So you want to understand how people use their space; and if you are doing service design you need to understand how the space, the service providers, the layout of items, and more affect the customer. When this is your project focus, use the Physical Model.
Think of the idiosyncratic ways in which people arrange their cars: cell phones are stored in cup holders, on passenger seats, and in other slots; wires are draped this way and that to get a charge; the cell phone used as a navigator obscures the car’s built-in navigator—which becomes a great place to lean the phone.
In grocery stores people only use the aisles they need, based on their shopping strategy, values, and intent on each shopping excursion. And then they adapt their use to the environment. For example, “I’m a perimeter shopper. I go around the outside to the fresh vegetables, meats, and bakery—no unhealthy packaged goods for me.” Or they let the environment help their process—so they hang out in the spaghetti aisle thinking about what to make for dinner and what else they might need if they make pasta. And now, more of the outside world is available in the store. People can take and send pictures (“Is this the pizza sauce you’re talking about?”) or make calls to significant others (“How do you feel about pasta tonight?”), and get information from Google (“Is this brand really organic?”).
If you are studying service workers or the role of kiosks, then you will need to interview the service workers directly and also watch people by stationing yourself at the kiosk. Then use your Physical Model to show activity around the kiosk, and the presence of store workers affects the shoppers (Fig. 8.8).
Figure 8.8 A Physical Model showing the interior of a car and how all the things people use fit into the space.
When the design and use of space is central to the product or service, we create a Physical Model. Studying the users’ space ensures that the product accounts for their behaviors, workarounds, and intents. Studying the way users organize and cluster their space tells you how to improve the space—and how to cluster things online if you are creating a parallel online space. Studying the movement and actions of attendants, the reaction to displays and in-store information, and any technology in the space gives you an overall picture of the real customer experience from a service perspective.
The Physical Model captures this information and is easy to build and consolidate. In the interview, collect data on how space is used—just draw a picture mirroring the physical environment they are in. Write down where the user puts things, moves them around, organizes them, and how she moves through the space. Look for intents and note them.
In the Interpretation Session, start with a drawing of the user’s environment as we described in Chapter 4 on Interpretation Sessions. Add detail as it unfolds in the interview and check that it’s complete at the end.
Now you have a set of individual models to consolidate. As always, pick the six most detailed to start with. To consolidate, look for the structure of the space. There is always a natural structure: the dashboard, seats and center stack of a car, the aisles and special sections of a grocery store, or the rooms and furniture in a home or office. These are your physical spatial areas. Lay them out as a background, mimicking the real space.
Then review, select, and clarify the insights by looking at all the individual observations within each area. Create one or two descriptive statements as an overview to that area and include stories to illustrate what happens in each one. (This is most like consolidating the DIL.) Finally, step back and look at the whole model. Clarify your insights and the message you want your model to show. Represent the stories as you would in a DIL—add color, small pictures, and challenge questions. Put it online and you are done (Figs. 8.9 and 8.10).
Personas
Personas3 are a way of communicating who your users are in a way that is familiar and easy to understand. Personas provide a quick introduction to your users that is easy to share outside the team. They help the team have a character to think about when they are designing and can help target market messages. Our teams have found them valuable over the years. We review our process for creating and using personas briefly here; see Rapid Contextual Design4 for more detail.
Figure 8.11 This persona from The Cool Project exemplifies the attitudes, values, and behaviors of young people relative to their cool tools.
A persona describes typical users of a product as though they were real people. They are presented on no more than a page, so they are easy to scan in a single pass. A persona has a name, description, and photo to make them real for the team. They emphasize goals and key tasks, so the team can see what motivates each type of user. And they have a narrative which provides some of the key details about how the user approaches the task. See Fig. 8.11 for an example from The Cool Project. We chose not to build personas for the travel project as we find the Identity Model to be better at helping teams focus explicitly on aspects of character that matter for design. Doing both the Identity Model and Personas is a way to get the best of both approaches.
In Contextual Design, personas are built from the interview data. This gives them unmatched depth and richness—you have plenty of stories and examples to draw from as you build your personas. This is critical for personas to be useful in the design process—a common complaint of personas is that they simply are too sketchy to drive action. All the data you collect in a Contextual Design project is present for you to incorporate when building your personas.
Consolidating data for personas
As with all models, in Contextual Design, we build personas bottom-up. Start by walking through your users and identifying the job role and key distinguishing features of each person. The key distinguishing features should be related to your project—e.g., they use a device, site, or product you care about. Your personas should not be overly driven by demographics, but note demographic information—you want to show the range of people who fall into each persona. If you have a lot of users, flag the most interesting ones—the ones where it was a rich interview, the user is important to your project focus, and provides a unique perspective. This will let you focus on the most useful interviews first and then you can add the rest.
Now group the users into potential personas. Users should group together if they do the same job, have similar attitudes toward it, and similar strategies for getting it done.
Expect to have four to eight personas for a project—more than that is rarely helpful to focus design. Each persona should be obviously distinct from the rest. You should be able to identify one primary persona for each person you interviewed. If personas start to fragment people, you are probably identifying identity elements, not personas. So don’t try to make fine distinctions—you can show minor variations in the same persona. Do not allow yourself to be driven by demographics and market segmentation—it may be useful to show how a persona cuts across segmentation types.
Shuffle the groupings, clarifying core attributes of each persona until you have a clean set of personas. Give each one a title which captures the key differentiators of that character type. (The person planning travel might fall into “Hobby Planner” and “Just-Enough Organizer” personas, for example.) If you can’t come up with a clean title, or if you can’t say that each user in the persona could be given that title, your persona thinking probably isn’t clean. In that case go back and look at your groupings.
Then collect the detail for each persona. Walk through the data from the interviews of each user in that persona and pull out key data: Strategies, intents, tasks, quotes, and characteristic stories. This will be the raw data for your narrative.
List the key goals, tasks, and demographics from each user in a persona. For consumer products you may want to show attitudes and values as well; you may want to track devices they use. This will be winnowed down in the next step so don’t worry about keeping the lists short for now. Just be sure to keep the distinctions clear: A goal states what the user is trying to achieve. A task is a specific action they take to achieve some goal.
It’s often easiest to base your persona off one main user. You’ll use this user as the basis for your descriptions, adding details from others and leaving out anything especially idiosyncratic. The main user should be one of the rich interviews that cover much of what the persona is to reveal. Choose your base user at this point.
You’re finally ready to do the actual writing. First decide what sex to make the persona and give it a name. Choose a sex based on the users—if all the users were female, don’t make the persona male. For a name, just choose something unobtrusive. We often go for alliteration so they are easier to remember: Harriet the Hobby Planner; Joe the Just-Enough Organizer.
Start with the narrative, taking 3–4 paragraphs to summarize the key information about the persona, writing as though the persona was a real person. Use specific stories to add color. Once the narrative is written, it’s easy to come up with a 1–2 sentence summary and a characteristic user quote. The quote doesn’t have to have been literally said by a user, but it should capture what they would say if they were talking straight. For example, for an operating room nurse: “The patient is in the doctor’s hands—but the doctor is in my hands.” The writing is much like that we discussed for the Identity Model.
Finally choose a photo and clean up your lists of goals, tasks, attitudes, and demographics. Choose the most important 3–5 of each. For demographics, just show the range of age, job title, and anything else you care to track that you saw in the user population. The photo should be characteristic of the users you saw.
Remember, a persona is characterizing the whole person’s life—they are not single identity elements. In our experience, although they help focus ideation, personas do not generate many design ideas in a Wall Walk. But when coupled with the other models, they are a powerful way to introduce the type of person the team will design for.
The Power of Models
Graphical models depicting the life and stories of the users in your population are powerful drivers of insight and ideation. Each model presented in this part—Affinity Diagram, Experience Models, and Traditional Models—reveal a different perspective on the users’ lives. Taken together, these perspectives provide a full view of the world your users are living in while doing the target activity you want to support.
The more you know the better you can design—you can see opportunity for new products, challenges for new technologies, constraints you must consider, practices that already work and that you do not want to break, and how technology is infused into users’ lives now. Stepping back and looking at the models together reveals all the different aspects of the practice of life and how they relate to each other. They communicate the whole world of your users to anyone who engages with the data. They can be revisited time and time again, added to for updates, and most importantly be the living representation of your users’ world. They expose the team and stakeholders to the realities of life in your users’ world. So they are the best way to drive data into design.
In Part 3, we’ll see how to use these models to drive ideation.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.