Stories captivate us. They draw us in and help us imagine new people, new places, and new situations. Telling stories, we draw others into the visions we hold in our mind. This is true not just of fictional worlds, but also of the experiences we imagine for our users. Through scenarios, we can tell stories about our users to help shape the products that we envision.
The parts of a story
Stories are more fun, and therefore more effective, than a long, technical design specification.Jared Spool, UIE
Good scenarios, like good stories, are made with a few key ingredients:
- They focus on a person (or people). In scenarios, these characters are our users. The characters should be based on real users or well-researched personas that represent certain roles or characteristics. Different scenarios for a job search product might focus on a hiring manager, a small business owner, someone looking for a job, or even a friend looking to recommend a job. Each will have different motivations and goals that inform the story you craft.
- They take place somewhere. The setting is our users’ environment. As we describe the environment, consider how it may affect the story. Is our user in a loud, crowded bar? Do they live in a rural setting with limited Internet access? Far from a passive detail, the environment often has a tremendous impact on the user’s experience of our product.
- The character(s) overcome a challenge. This is our user’s problem. How do they currently solve it? How can our product help? In some cases, the best solution may never involve an interface, and that’s where scenarios can really shine. Disney’s Magic Band has no interface, but Disney has crafted a compelling experience despite that.
- Stories also explore motivation and emotions, and scenarios relate the users’ goals and feelings as they progress. We can use scenarios to portray the user’s current experience to help build empathy and understanding of their problem. Telling the stories of how a user struggles with tools they currently use can get our team fired up to build something better. Explaining the motivation behind solving a specific problem can open up new vistas of possible solutions.
Once we have these basic elements, it’s time to write our scenario.
The scenario process
A good, realistic scenario starts with good research. It reflects our users’ problem, motivations, and reactions to drive our team to work toward (or possibly away from) the outcome the scenario conveys.
- Talk with real users. Get to know what motivates them and better understand their problems relative to our product or business.
- Observe their environment and make note of current practices, potential obstacles, and common assumptions.
- Create personas based on the user types observed. These become our primary characters.
- Choose a specific moment to focus on for a specific persona. Scenarios shouldn’t portray the holistic experience of using our product. Instead they should detail smaller individual interactions for specific people.
- Write the scenario. Don’t just focus on our product’s place within it. How did the persona arrive at our product? What do they think and feel as they use it? What do they do afterward?
- Test our scenario. Once we’ve written a draft, run it by the team. Are we proposing something feasible? Run it by some users. Does it seem valuable, realistic, and achievable?
- Refine the story. Now take what we’ve learned from testing it and clean it up. Make it better.
- Use the scenario to help others see the full story. Share it with our team, clients, or stakeholders. Refer to it in planning, add it to documentation, and post it alongside mockups.
Now that we’ve created a scenario (or scenarios), how can we use them to shape our product? There are plenty of opportunities!
- Share them widely, within the team, with clients or stakeholders, and with others in our organization. The power of stories comes from sharing them.
- Attach them to user stories so that our development team has more context for where the user is coming from, what they are trying to accomplish, and why.
- Compare them with the product. After we’ve features based on our scenario, compare the real life experience with the story we told. Where did we succeed? Where did we miss the mark? How can we improve the product or the scenario to achieve a better result in the future?
- Revisit them as we continue to research. Are we still focused on the right assumptions? Was our original scenario based on an outlier or a trend?
- Build journey maps from a collection of scenarios. How does one scenario fit alongside others? What can we do to smooth transitions between different scenarios?
- Explore alternate stories to the scenarios we’ve crafted. What happens to the story if a different persona participates or if it takes place in a different setting? What happens when things go wrong? Consider how our scenarios should adapt in emergency situations or when our assumptions are otherwise subverted.
Ready for more?
Here are a few great resources to dive in further to the world of scenarios:
- Scenarios and Journey Maps Help Designers Become Storytellers from UIE
- A step by step guide to scenario mapping from UX for the Masses
- How to Perfect Your UX with Persona Scenarios at Web Designer Depot
- Personas, Scenarios, User Stories and Storyboards: What’s the Difference? from Justinmind
- Scenarios on Usability.gov