A step by step guide to scenario mapping

Scenario mapping

Scenario mapping is a really quick, easy and dare I say it even fun way to collaboratively create, discuss and communicate user scenarios. Scenario mapping will help you to think about your users, to think about their tasks and most importantly to think about the sort of user experience you want to provide. It will also help to ensure that your designs are grounded in the real world because scenario mapping forces you to consider the context in which a design is likely to be used. In this article I walk you though step by step how to go about creating scenario maps and why they’re so damn useful in the first place.

What’s a scenario?

Before we start looking at scenario mapping I thought it would be useful to very quickly define what I mean by scenarios. In the world of user experience design a scenario is basically a story about someone (usually your users) using whatever is being designed to carry out a specific task or goal. For example, a scenario might outline how Paul uses a website to order flowers for his mother’s birthday, or how Sarah buys a train ticket on a kiosk machine for her journey home (goals and context are important). Scenarios can be very detailed, all the way to very high level but should at least outline the ‘who’, ‘what’, ‘when’, ‘where’, ‘why’, and ‘how’ of the usage.

Scenarios are typically used to provide a picture of the intended user experience (i.e. what ideally should happen), but can equally outline what currently happens. They can take many forms, including written narratives, visual storyboards, comic strips or even videos. The form that I’m going to be discussing is scenario mapping, although it’s also know as design mapping, as outlined in The Persona Lifecycle – Keeping people in mind throughout product design by John Pruitt and Tamara Adlin.

What’s scenario mapping?

As I’ve already mentioned scenario mapping is very simple and in many ways is very similar to task analysis (although you’re typically looking at the ‘to be’ rather than the ‘currently’). Like task analysis you’re basically attempting to map out all the steps that a user will take to complete a task, with an initial focus on what your user will do, not necessarily how he or she will do it. Along the way you’ll also be capturing good ideas, questions and other stuff that is important for the design. Sounds interesting? Here’s a quick step by step guide to carrying out scenario mapping:

1. Find a good room or area that you can use for 2-3 hours (for each session)

You’ll ideally want some wall space that you can use and certainly enough room to accommodate everyone that needs to be involved in discussing the scenarios.

2. Send out your scenario mapping invites

You’ll want to invite the design team (developers, graphic designers, business analytics etc…) or at least a good chunk of the design team, along with the product owner(s) and any domain experts. Of course the size of the design team can vary from project to project but try to avoid inviting too many people. I’ve found that 3-5 people works well for most scenario mapping sessions because you’ll get a good coverage of ideas, opinions and expertise. It can also be a good idea to give people an overview of what you’ll be looking, including a list of the scenarios you’ll be mapping out so that everyone has an opportunity to think these and to prepare for the sessions.

3. Grab as many different coloured post-it notes as you can

You’ll be using post-it notes to capture user steps, questions, ideas and comments so you’ll ideally want 4 sets of different coloured post-it notes so that you can assign a unique colour to each. If you can get your hands on some super sticky post-it notes (yes, such these do exist) then all the better because regular post-it notes can sometimes struggle to stick vertically to walls or paper.

4. Grab a roll of brown packing paper and some blu tack

Unlike the post-it notes these aren’t strictly necessary, but are handy for being able to transport your scenario maps when you’re done. By sticking long strips of the brown packing paper up on the wall and sticking the post-it notes to these you can easily take your maps away with you when you’re done.

5. Introduce the scenario mapping session

At the start of your scenario mapping session briefly talk everyone through what you’re going to be doing. Don’t forgot to emphasise the fact that you’re initially concentrating on what will happen, not necessarily how it will happen and that you don’t want to get too bogged down in the detail. Sometimes you will have to park discussions for later and move on and it’s good to set people’s expectations for the session.

6. Start mapping your first scenario

Take one of your primary users (for which you’ll hopefully have a persona) and the key, or one of the key tasks that they will be undertaking. This is hopefully the ‘raison d’être’ (or ‘reason for existence’ for those like myself who don’t speak French) of your site or application. What must someone be able to do? What are the really key tasks from a user and business perspective? For example, for an ecommerce website you might use buying an item as the primary scenario to initially map out.

7. Outline some context for the scenario

You’ll want to note down some context for the scenario. For each scenario that you map out it’s important to consider and make a note of the: who; what; where; why; and how often of the scenario.

8. Walk through the steps the user would take

This is where the fun begins. As a group you’ll want to walk through all the steps that you envisage a user taking to carry out their task. For each step you’ll want to capture the following on your different coloured post-it notes (don’t worry if you don’t have 4 different colours, you can always use notation such as ‘(s)’ for a step and ‘(q)’ for questions to distinguish the different types of information):

  • What the user does. Remember to focus on what happens, not necessarily how it happens. For example, Paul brings up a larger image of a bouquet of flowers that he thinks his Mum would like.
  • Any comments or information that you feel is important at this step. For example, you might want to make a note that there might be alternative images available for a bouquet of flowers, such as a front and side shot.
  • Any questions or assumptions that arise are this step that you’ll want to resolve. For example, will the images for flowers all be the same size and aspect ratio?
  • Any ideas or good suggestions that people have. For example, it would be good to allow Paul to zoom in on an image so that he can see the bouquet of flowers in more detail.

9. Stick your post-it notes for the step on the wall

The basic idea is to map out steps horizontally, from left to right and detail, such as comments, ideas and suggestions vertically below the associated step. It’s important to stick steps at the top so that someone can follow the scenario by reading the top row left to right.

An example scenario map

A section of a scenario map for someone ordering some flowers for this Mum’s birthday

10. Repeat for the next step until the user has completed their task

When mapping out scenarios don’t worry about initially capturing all the minute steps a user would take, otherwise you’ll drown in the detail and never get your scenario maps completed. Initially you’ll want to keep the steps relatively high level. For example, one of your steps might be “Paul fills out his address details”. At some point you might want to map out exactly how Paul does this (Paul enters his name, his house number and street etc…) but this is probably too much detail for a first pass.

11. Repeat steps 7-10 until you’ve mapped out all the key user tasks

You’ll want to create scenario maps for all, or certainly most of the key tasks that users will be undertaking. Initially I’ve found it easiest to concentrate on ‘Sunny day’ scenarios. These are scenarios where everything goes according to plan (like that ever happens), as opposed to ‘Rainy day’ scenarios where unexpected problems occur. For example, a ‘Rainy day’ scenario might involve an address not being found or a preferred delivery date not being available.

12. Take photos of your scenario maps

I’ve found it a really good idea to take digital photos of your maps when you’re done as post-it notes have a nasty habit of falling off and going missing. This also gives you something you can easily save in a digital repository and send on to other people if need be.

An example scenario map

An example scenario map – in this instance posting a blog entry using a blogging application

13. Get feedback

Having put together some scenario maps it’s a really good idea to ask users, domain experts and key stakeholders to walk through the steps so that you can get feedback as soon as possible. Are there steps missing? Are they able to answer any of the questions? Does the scenario hang together? By getting feedback early on you can easily change and refine your scenario maps before you get too far along with the design.

When is it best to use scenario mapping?

Scenario mapping is mostly used to provide a picture of the intended user experience (i.e. what ideally should happen), but can equally outline what currently happens, much like task analysis. Creating a scenario map on the fly as you run through tasks with users, or even observe them (obviously with their permission) as they undertake a task can be a very effective way to explore and document what currently goes on.

When used to capture the intended user experience I’ve found that scenario mapping is most effective very early on in a project to help flesh out user journeys, likely product features and possible screens for a UI. For Agile projects it can be useful for helping to put together the product backlog and for more traditional projects (i.e. more waterfall in nature) for defining the functional requirements. Scenario maps are also a really good precursor to sketching screens for the UI or even creating a sketchboard.

For most projects you won’t be able to map all your key scenarios out in one sitting. These sorts of exercises always take longer than expected, especially if you’ve got a sizable group, so expect to carry out a number of scenario mapping sessions. Also don’t forget to allow time for gathering feedback and for further refining the scenario maps. It also helps if you’ve carried out some domain and user research beforehand, otherwise you typically end up with loads of questions that need answering or having to make lots of assumptions (although these will give you an indication of the areas of the domain and design that you need to explore further). Finally don’t forget that with scenario mapping you’re not trying to capture everything, just enough to work out what should happen or currently happens, to give you enough to move forward with the design. So don’t get too carried away!

Finding out more about scenario mapping

Scenario mapping is outlined in much more detail in the excellent The Persona Lifecycle – Keeping people in mind throughout product design by John Pruitt and Tamara Adlin. In the book the technique is called ‘reality mapping’ when used to look at what currently happens and ‘design mapping’ when used to look at what could happen. Since both are effectively the same technique I prefer the simpler ‘scenario mapping’ label for the two, but of course you can call it what ever you think will make most sense to your team.