Scenario Space: Covering every angle of Usability within your app

By Paul Laberge October, 16 2012

This post is Part 2 of a larger series that dives into the concept of Consistency of Experience.  Through this series I will explain what Consistency of Experience is defined as, building great app experiences on the Windows platform ecosystem (including Windows 8, Windows Phone and the web) and how to drive these apps to successful adoption by your users.  By the end of this series, you will have a firm understanding of why it is important to implement your apps in a modular or patterned way to leverage similar or same code bases across platforms and also to differentiate to platform-specific functionality by addressing each platform with a UI that is catered to the right form factor.  For a list of the other posts which will be published over time, please visit the anchor post for this series.

So you have a great idea for an app.  You likely have a vision of the way it will work and look, even across multiple screens (phone, PC, TV, etc.).  If you’ve created a UI by this early time in the ideation process, however, you’re doing it wrong.  Even if it’s just chicken scratch on a napkin, that’s not the blueprint you should end up following for your app.  The reason why this is true is because you really haven’t thought through how your app will really be used by the end user.  Sure, you can take a stab at what you think will be the right UI and flow for your app to best serve the user, but I’m guessing that if you go through the process the right way, the end result will be at least slightly different than the UI and flow that you had originally envisioned.

Starting the process off right

So what’s the right way of building the usability and flow of your app?  You start with identifying the scenarios of how your app will be used.  A scenario in the parlance of usability of software, is the study of how your solution will interact with the user, or more specifically, defining the interaction patterns of your app with various roles of users. 

The major anatomy of a scenario

A scenario is not atomic in nature.  What I mean by this is that a scenario is built from a number of components, each of which requires you to think about how they fit together.  Ultimately, each scenario has what is called a story.  The story defines the Why of a scenario (as in why a user would be using the app in a certain way).  Think of it as the history or background of how a user gets to be using your app a certain way.

A scenario also has what is called a storyboard.  The concept of a storyboard is interesting and has many of its roots in animation.  The storyboard in that context was a way to describe a scene in a rough context, basically laying the framework for the situation.  You can see how this concept is easily transferrable to app design.  The situation is the use case or scenario and the context and framework (storyboard) are defined by a series of actions or states that the app can be in at any point in a given scenario.

Another important component I will highlight here is the goal.  The goal can be considered the end state(s) of a scenario.  All goals define a state for the app to be in at the end of a scenario and are meant to provide even the entry level inputs to any new scenarios that a user may present the app.  It is important to  note that a scenario may multiple end states, so take care in thinking through the scenario properly so that you have a handle on what those states will be to ensure every inevitability is covered.  Please also note that an end state to a scenario may act as an input to another scenario as well.

There are many other components to a scenario that are not covered here (otherwise this post would actually be a book!).  That said, if you are looking for details on scenario components this book might be a good place to start.

Tying a Scenario to an App

There are some really great examples of how to tie a scenario to your app on the web.  An example of this is found on the Designing Windows Store Apps site.  There is a section on this site that talks about scenario building and storyboarding here.  The site makes you think about the following things (and in this order):

  • What is your app great at?  (hint:  if you can’t clearly answer this question within 30 seconds, either the app is too complex or you don’t yet have a good understanding of the problem space)
    • If you want some great guidance on this, I encourage you to check out this post authored by my colleague Marc Gagné.
  • What types of activities will your app support? (this is your cue to start thinking in terms of scenarios and fitting the puzzle pieces together)
  • Decide what features to include (more on this below)
  • Think of your business model (what are your factors for success for your app and how will you achieve them?  More on this in an earlier post I wrote here)
  • Create your UI (notice that your UI doesn’t come until after you’ve figured out how your users will interact with your app?  We’ll leave this to a later post)
  • Prototype and validate your app’s design and flow (we’ll leave this subject for a later post in this series)

Scenario Mapping

So now that we know how to tie a scenario to an app and the theory of what a scenario is, how do we actually formulate a scenario?  There is no one, right answer to this question.  If there was, every type of app would frankly be the same.  The beauty of formulating a scenario (also known as scenario mapping) is that it allows for an amazing amount of creativity in the process, thereby guaranteeing you have freedom to define how your app will interact with its users in a manner that allows you to express your innovation but also help guide you to the right end states.

Scenario mapping can appear to be a chaotic process, and in some ways it is.  It’s a bit of a brain dump that you (and others on your team, including focus groups of potential users of your app!) can use to start figuring out how to put the pieces together in a cogent way (i.e.  mapping out your thought process and interaction interface to the app). 

One of the more common ways that scenario mapping is done is through post-it notes.  Post-it notes typically allow you to only write short, to-the-point thoughts or reminders and that is why they are useful in the scenario mapping process.  The intent is that each post-it note will provide a quick burst of inspiration, or a question, or a concern. 

If you go the route of post-it notes, you should consider using multiple colours.  Each colour can represent a type of thought process.  Yellow notes could represent the tasks that a typical user might take in a certain scenario.  Ideas that pop into mind from you and your team could be represented by purple notes.  Green notes could take the role of questions and pink notes for any comments along the way (by the way, those are the colours I’m using for this example.  The colour you choose could be different – there is no “industry standard” for this).

Now that you have your colour taxonomy for the mapping, pick an axis for steps a user will take (typically horizontal but I’ve seen it done vertically as well).  The first post it on the axis pivot you’ve chosen should always contain the steps a user will take to get to the end state/goal of a scenario.  When you create or identify each step a user takes in the scenario, always try to understand the situation the scenario will be in.  Neil Turner talks about this in his blog post about Scenario Mapping as the context:  make sure to understand and consider the who, what where and why of each step.

For each step, team members can add ideas, comments and questions along the way to every task.  This process is surprisingly analogous to agile software development in that it allows the team building scenarios to iterate quickly and change the process as needed without extraneous process interfering before an agreed to scenario mapping is finished.  In other words, as comments, ideas and questions arise for each task of a scenario, that feedback can be taken in realtime and a task or chain of tasks can then be modified to meet the new line of thinking.

An Example

In this (admittedly mocked up) example, the app my team is building is a financial portfolio app.  The scenario we will specifically choose in this instance will be a user wanting to add a stock watch to his/her portfolio (a stock watch is when the app will monitor a specific stock to determine if a certain minimum or maximum price is met at which point an alert will be sent to the user).  Below is an example of what the early scenario map might look like for this scenario:

 

What does this have to do at all with “Consistency of Experience”?

You may recall that this is the second post in a series where I discuss the concept of Consistency of Experience and how you should think about building your apps to best leverage this concept.  I can forgive you if you feel a little confused as to the relation.  The reason why the concept of scenario mapping and task identification is so important here is because there are some things that are absolutely the same regardless of what platform or “screen” your app targets as well as some fundamental differences.

Take the financial portfolio app example that I used above.  Say my intent was to create a Windows Store app as well as a Windows Phone app.  Fundamentally, a Windows Store app is hosted on Windows 8 and fundamentally different than a Windows Phone app, even though they may share some similarities in look (using the Modern UI style).  At the same time, however, many of the goals of the Windows Store app and Windows Phone app are shared.  Ultimately, you want to make sure that the goals of any shared task across both apps is the same, because although the form factors between a PC app and a Phone app are different, the information or results a user expects from these two apps can be the same.

Scenario mapping is a very important process to undertake when building an app, especially if you are building companion apps between disparate platforms.  By using the concepts of Scenario Mapping, you are increasing the likelihood that your app will cover the appropriate use cases for the form factor in question as well as having a much better understanding of how your app will actually be used by your user base.


Add A Comment

Comment

Allowed HTML: <b>, <i>, <u>

Comments

© 2013 Microsoft Corporation. All rights reserved.
This site is hosted for Microsoft by Agility