The complete guide to scenarios – part two

Welcome to part two of this complete guide to scenarios. If you’ve not yet read part one of the guide then I’d thoroughly recommend that you do so, because it helps to explain what scenarios are, and why they’re such an important design tool.

Hopefully by now you’re sold on the idea of using scenarios. You can see the benefits, but perhaps you’re not sure where to start. Well help is in hand. I’m going to go through everything you need to know to start using scenarios to design products and service that really perform in the real world.

Doing your homework

If you’re going to use scenarios and tell the story of how a product or service is going to be used in the real world, you need to know what that real world looks like. You need to know, or at least be able to guess (and then check afterwards that you’re guess is correct) who your users will be, what they will be trying to do, where your product or service will be used, when, and perhaps mostly importantly of all why.

The best way to answer these questions is through user research – ideally shiny new first hand research, but second hand will often do. You might go out and meet users (or potential users) in their environment. You might speak to people who can tell you some of this information, such as customer-facing staff. You might include a question in a survey asking people to describe a scenario, such as the last time they did what it is you’re interested in. Anything you can do to better understand your users and the context in which your product or service is used or is likely to be used. You don’t have to go crazy, but keep in mind what the author Mark Twain (writer of The Adventures of Huckleberry Finn) sensibly said, “Supposing is good, but finding out is better”.

Choosing the type(s) of scenarios to use

You’ve done your homework. You’ve hopefully left the safety of your office to see what your users are really like and you now have a much better understanding of the problem you’re trying to solve. Now it’s time to decide on the type(s) of scenario to initially define. I say initially, because sometimes you’ll create multiple versions of a scenario. For example, you might initially create a detailed narrative scenario, and then put together a more cut down storyboard for showcasing to stakeholders.

I generally start by collaboratively creating a scenario map (more on how to do this that later) and then flesh it out to create more of a narrative scenario. If communicating with wider stakeholders is really key then creating a more visual storyboard based on the scenario map can be a great idea. When choosing the type(s) of scenario to create you should also think about your own strengths. If you’ve a gifted writer, then a narrative scenario might be the best idea. Alternatively, if you’re a skilled artist then a storyboard might be best. There really is no right or wrong approach, and of course every project is different, so experiment and see what works best for you. If you’re starting with a more narrative scenario then you might find this narrative scenario template (Word doc) useful.

Example scenario map: Thomson

Deciding on your scenarios

As any writer will tell you, writing a story is often the easy part, it’s coming up with a good story in the first place that’s the really hard part. When deciding which scenarios to start with consider the key high level goals that your users have, and the key tasks that they will need to undertake to reach these goals. For example, in my story my goal was to entertain my children (or at least stop them from causing anymore chaos in the house). To reach my goal I wanted to put a family friendly film on, which was my key task. Always start with goals and then try to identify tasks. Tasks will tell you ‘what’ someone is trying to do, but goals will tell you ‘why’.

I always start with the key users for the product or service, and their goals and key tasks. Of course these illusive ‘key users’ are often very hard to pin down, and will vary depending on who you speak to. It’s not uncommon for example for the marketing team to have a very different definition of the key users than say the product team. When identifying key users consider the product strategy (including marketing strategy), where the product or service is in its lifecycle and who the product or service needs to really excel for. For example, if it’s a new product or service then you might need to think about early adopters, because if you can’t get these people on board your product or service might is unlikely to gain any traction in the market.

Defining your characters

All stories need characters, and so do scenarios. Hopefully you’ve already identified some of your characters in the form of your key users. Ideally you might even have some personas that you can use to really bring your characters to life. If you don’t already have some personas then it can be a good idea to bring your characters to life by providing a bit of a backstory. What is their name? What do they look like? What is their background? What sort of goals and needs do they have? You don’t have to give their complete life history, just enough to enable someone going through that scenario to understand what is driving a character’s behaviour and more importantly to empathise with that person.

Example persona

Like personas, your characters should be fictional, but very much based on fact. Try to make your characters as realistic as possible, ideally by basing them directly on your user research. If you do have to make up parts of your characters that’s fine, just remember to verify that any assumptions you’ve had to make are correct. After all, a character plucked completely out of thin air looks to all intents and purposes the same as a character based directly on solid user insights.

Planning your scenario creation process

Like so much in life, I’ve found that creating your scenarios is best done with other people. A good starting point is to set-up a time boxed workshop of 1 or 2 hours and then to flesh out some high level scenarios with a small group. A scenario mapping workshop is a great way to do this.

Your small group should ideally be between 3 to 5 people and should include people with knowledge of the users, the domain, the technology and the product or service. For example, the group might be made up of a UX designer, UX researcher, domain expert, product manager and tech lead. Keeping the group small helps to minimise death by discussion and hopefully ensures that you can come up with at least 1 or 2 scenarios by the end of the workshop.

If setting up a workshop is going to be tricky, then an alternative might be to flesh out some scenarios yourself, or with a partner in crime, and then to share and discuss these with a wider group.

Defining your scenarios

Right. You’ve done your homework. You’ve decided on the scenarios to tackle and you’ve defined your characters. Now’s the fun part – coming up with your stories.

Like writing any story, defining scenarios can be a somewhat messy affair. I’ve generally found that scenarios are best tackled in a linear fashion. In other words, start with the beginning, the trigger for the scenario and then work your way through to the middle, and then the end. You don’t want to include too much detail, really just enough to tell the story, but do try to include some little details that can help to bring the scenario to life. For example, perhaps mention some of the emotions that the characters go through, or some of those little key moments of truth that someone experiences when using a product or service.

A good way to prevent things from getting too bogged down in the detail is to outline what a character does, rather than how he or she does it. For example you might state that Sarah registers on a website but not the exact steps that Sarah goes through to do this – you can worry about designing these steps later.

As you go through a scenario lots of questions, ideas and discussion points will invariably come up. Try not to get too sidetracked but it’s certainly a good idea to capture any relevant information. Also, keep a note of any assumptions that you’ve made as you will want to check these at a later date. ‘AssUMe’ makes an ‘Ass’ our of ‘U’ and ‘Me’ and all that…

There are always a million and one ‘what if’ decisions and discussions as you go through a scenario. What if Sarah has a problem? What if registration fails for some reason? What if Sarah suddenly realises that she’s forgotten to close a window and the mother of all storms whips up? I’d recommend to start with that you keep things simply by starting with sunny day scenarios. By sunny day scenarios I don’t mean some Hollywood-esque fabrication of reality but scenarios when everything goes perfectly to plan. Like one of those days when the sun is shining, all the traffic lights you go through are green and everything just seems to go right.

Sunflowers in a field

Having defined sunny day scenarios it’s then a good idea to think about what happens when things go wrong. What happens when the lights are not only red, but you get a puncture on the way home? What does a rainy day scenario look like? You often won’t need to create separate rainy day scenarios, just think about what can go wrong within a sunny day scenario. What would a character do? How would a problem be resolved? Don’t consider each and every eventuality but it’s certainly worth spending a bit of time thinking about the most likely problems that could occur.

It will vary from project to project but you’ll typically have one or two sunny day scenarios, and one or two rainy day scenarios for each key user. You want just enough to cover their key goals and tasks. Don’t go crazy creating umpteen different multi-universe scenarios, but equally don’t try to create one uber scenario that covers all usage scenarios.

Reviewing & sharing your scenarios

Having defined some scenarios you want to review them to check that they are realistic. The first way to do this is to go back to your user research and insights and ask yourself, would this actually happen? Would a user actually do this in the real world? Having done this it’s then a good idea to go through the scenarios with a domain expert. For example, you might go through them with a researcher or someone that has spent a lot of time with users of this sort. You could even go through the scenarios with some users. However, be mindful that just because people say that they can see themselves (or worse, others) doing something, it doesn’t necessarily mean that they would actually do it. I’m reminded of an old story of a focus group where participants could either be paid in money, or receive the product being evaluated. Despite lots of people saying that they loved the product, and the fact that the product was worth considerably more than the money on offer, all the participants went for the money. Actions speak louder than words, or to put it another way- it’s not what people say they would do that really counts, it’s what they actually do.

Scenarios, especially in their more visual guises, such as storyboards are a great way to communicate how a product or service might work. They can help to build a shared understanding, not to mention stimulate dialog and discussion. Scenarios are also a great way to show the sort of design thinking being applied. You might share your scenarios by walking stakeholders through them and asking them for their feedback. You could stick the scenarios up on the wall and ask people to add their comments. You could write a blog post featuring a scenario story and ask people to post their comments. You could even create a short video like this storyboard video from a redesign of the University of Pittsburgh’s intranet.

A Lifetime of Engagement with Pitt video

Identifying features and UX requirements

Features are too often the starting point for a design. Our product must have this feature. Users must be able to do all these things. This is bad idea. It really is. It’s like packing your bags for a holiday, before you even know where you’re going to go, or for how long. You end up packing lots of other stuff that you don’t need, and neglecting to pack lots of stuff that you do need. Design should always start with the problem, and have features naturally emerge from the solution to that problem. The good news is that scenarios help to encourage this sort of design thinking. By going through the scenarios you can very quickly identify the sorts of features that will be required, along with other UX and technical requirements. For example, if we were to create a scenario for redesigning the NowTV experience, some of the features identified could include the ability to use AirPlay to stream a movie from an iPad to a TV, along with the ability to show a password on entry.

Having identified the features you can start to flesh out the ‘how’ for each scenario. Exactly how will users accomplish what the scenario sets out? What sort of interactions will be required? Given that you will already have considered the users and the wider context of use, you’ll be in a much better position to tackle these challenges. After all, blindly diving in to the design of a particular feature or interaction is not the best way to design a great product or service.

Reviewing designs against your scenarios

Even once a design is well underway scenarios are still hugely useful because you can evaluate a design against the scenarios that you’ve identified. Would this design perform against this scenario? Would this design make this scenario a reality? By continually going back to real world scenarios you can ensure that the design of your product or service really performs when real people, in real places use it to do real things.

Source: UX for the Masses

This entry was posted in Uncategorized and tagged , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *


4 − three =

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>