Smart teams begin new design projects by getting to know their customers through design research. The best ones build models of those customers, their goals, their behaviors, and/or their environments. Models like personas do an awesome job of describing what the customer’s world looks like today. However, building models of customers and their work is only a means to the end of designing great products. Many teams struggle with using research models to inspire design. It’s just too big of a jump from a persona writeup to a new product concept.
The context scenario bridges this gap. A good context scenario clearly articulates a working hypothesis of how the customers’ lives will improve when the new product* exists. Unlike a workflow or task analysis, a context scenario is an act of design—it imagines the future, rather than describing the world as it is today. Because context scenarios can be created and iterated on very quickly, they are often the first design act the team undertakes.
(* – for the purposes of this article, “new product” could be a new physical product, a new service, or a major enhancement to a product or service the customer already uses. The details of the context scenario will likely be different in these different cases, but the form of the context scenario remains the same.)
The scenario is a series of steps describing how the customer first hears about the product, becomes compelled to try it out, and uses it to achieve his goals. The scenario ends when the customer becomes convinced that the product is of value to him, choosing to purchase it, recommend it, or perform whatever other action the design team is hoping for.
A good context scenario has three properties:
- Customer-focused – The context scenario is written from the perspective of the target customer. Well-researched personas make this much easier – the scenario simply stars the primary persona. However, a context scenario still has value with hypothesized or “provisional” customer models, there’s just a much greater risk that the scenario will be inaccurate.
- True to character – The behaviors, needs, and desires of the target customer expressed in the scenario must be compatible with his goals and personality. For example, a very busy stock trader isn’t likely to spend all afternoon exploring a photo editing tool for his side hobby. Again, this is much easier to determine with research-backed personas.
- Goal-directed – The context scenario describes how the customer discovers the product and uses it to accomplish his main goal in the most compelling way possible. It avoids edge cases and detours designed only to show off features. A context scenario should be similar to a movie script—it introduces the characters and defines the action and narrative structure, but leaves the bulk of the creative decisions to the director/designer.
A context scenario has four parts: the setup, the hook, the narrative, and the resolution. I’ll explain each of these in detail, using the context scenario for “Talaria”, a side project I’m working on, as an example.
The setup describes the customer and her problem. It lays the foundation for the rest of the scenario by articulating the customer’s need, how the customer is addressing that need today, and why this should be improved. If you’re using personas, describing the customer can be as simple as referencing the persona’s name.
Jessica is a 28-year-old marketing professional working for a mid-sized startup in San Francisco, CA. She has an active work and social life and frequently travels around the city, but she doesn’t own a car. It’s expensive, parking is a nightmare, and Jessica would like to try to be environmentally-friendly whenever possible. However, because she lives on top of Nob Hill and is skittish about traffic, she doesn’t ride a bike. Instead, she takes Muni just about everywhere.
Unfortunately, Muni is often unreliable and suffers frequent meltdowns. Jessica uses an app on her iPhone to show arrival times for her favorite routes, and switches between that and Google Maps to figure out what routes she needs to take. But its tedious, especially when a bus breaks down and she has to figure out the best alternate way to get to her destination. Since this happens with some regularity, Jessica is worried she’s getting a reputation for being regularly tardy to appointments and social events.
The hook covers how the customer discovers the new product and how she becomes convinced to try it out. Sometimes, this involves exposing the customer to marketing material, but it could also occur through word of mouth, the product appearing in search engine results, etc. Remember that the scenario must be true to the customer’s character – e.g., if she is expected to hear about the product through word of mouth, then she’d better be the sort of person who has friends who would tell her about products like yours.
Many teams treat the hook as an afterthought – they believe that selling the product to the customer is the job of marketing. But understanding the hook is key for both marketing and design, for it tells us which of the product’s capabilities will serve as the greatest draw and must be made most straightforward to a new customer. For example, if customers are coming to your product to easily share photos with friends, the sharing functionality better be front-and-center in the product’s design!
Jessica downloads Talaria in the hopes that it will save her time when Muni is having a bad day. She’s also intrigued by Talaria’s promise of a full refund if she experiences a Muni meltdown that Talaria can’t help her out of.
The narrative will compose the bulk of most context scenarios. It describes how the customer acquires the product, how she completes the tasks she chooses to perform with it, and what parts of the product serve to delight, impress, or intrigue her. The narrative will inevitably make some claims about the features, functionality, and design of the product, but it should avoid details about how the artifact works in favor of describing how the customer experiences the product and her emotional reactions during that experience.
During the narrative, the product should solve the problems the customer was experiencing during the setup. A good context scenario makes it clear exactly how the product improves the customer’s life.
Jessica opens Talaria to find her way to a doctor’s office. She’s never been to this particular doctor before, but she has the address from Yelp. Talaria determines her current location automatically using GPS and presents her with a means of entering her destination. As she types, Talaria offers autocomplete suggestions based on destinations that are close to her current location, so Jessica doesn’t have to type much before Talaria knows where she wants to go.
Talaria displays a short list of route options that will get Jessica to the doctor’s office as fast as possible. Jessica chooses the first one – the bus stop is four blocks from her house and will arrive in 13 minutes. Talaria promises to notify her when it’s time to head out the door.
Seven minutes later, Jessica’s phone buzzes. She grabs her purse and hits the pavement. When she arrives at the stop, she checks Talaria which tells her the bus is arriving in 2 minutes.
And so on… you get the idea.
The resolution brings the context scenario to the conclusion sought by the design team. During the resolution, the customer forms an overall opinion about the product and takes action accordingly. These actions should advance the business goals of the product – perhaps the customer pulls out her wallet and buys the product, perhaps she recommends the product to her friends, or perhaps she merely continues using it daily, gradually earning the business ad revenue.
Jessica dashes off the 22 and up McAllister street to catch the 24. Fortunately, she makes it just in time, arriving at the stop while the bus is waiting at a stoplight. Jessica breathes a sigh of relief. She’d never taken the 24 before, so she would never have realized she could use that route in time to make the transfer.
Pleased that Talaria helped her reach her doctor’s appointment on time despite the delay on the 22, Jessica resolves to use the app for all her Muni-riding needs in the future. She’s hopeful that with Talaria’s help she will lose her reputation for frequently showing up late!
Context scenarios are usually prose. However, researchers and designers with strong sketching skills might choose to create the scenario in a low-fidelity “comic strip” form, combining words and images to make the ideas more succinct and engaging. The same principles apply, however – the context scenario must still be quick to create and should avoid design details in favor of focusing on the customer’s expected reactions to the product.
Good context scenarios focus and channel the creative energy of the design and development team towards solving the most important customer problems identified by the researchers. Far from constraining the team’s ideas, context scenarios give the team more time to innovate by eliminating much of the churn caused by fleshing out features and workflows that matter less. Even a “wrong” context scenario helps teams create prototypes of their hypotheses quickly, allowing them to continuously test and revise the context scenario and the product, getting to success much faster than teams that spend their time debating design details that may not matter to customers.