How To: Scenario-based Design

For software to be successful, it is no longer enough that it works well. She must feel good feel. Successful companies such as Google, Facebook and IBM therefore anchor design thinking deeply in their corporate culture in order to guarantee this good feeling for the customer. They use extensive data from users, run AB tests and consider steps to further improve the user experience. But how do you start?

Scenario based design, or SBD for short, is a method of user-centered design. It takes advantage of a simple toolbox Personas, Scenarios and Claims, in order to consider very different user groups and situations when designing the interface. SBD is an iterative process. The process is divided into three rough phases, but scenarios and claims from earlier phases can be revised without further ado so that new insights are gained.

The process is broken down as follows:

• Analysis
  • User analysis, creation of personas
  • Problem scenarios - What is happening now?
• Design
  • Activity Scenarios – What does the user want?
  • Information Scenarios – What do I show the user?
  • Interaction scenarios - How does the user interact?
• Prototyp
  • Implementation
  • Evaluation based on user feedback

For this post, I will use a simple example to show the meaning of the terms. My (fictional) company wants to develop a fitness tracker to encourage customers to lead a healthier lifestyle. The tracker should record the daily steps, allow daily goals to be set and provide information on the progress. The results of our user analysis suit us in this document .

Personas – Tangible user data

The basis for the design process is the Person. Personas are fictitious personalities and embody the characteristics of user groups. They are worked out in detail to make user data tangible and to give a face. They can make mistakes like any normal person and have only imperfect knowledge of the system.

Personas are important because they allow the team to put themselves in the shoes of different users to better understand their wants and needs. A development team has different expectations of a fitness tracker than a passionate runner or a housewife. Likewise, it has other skills. For example, the team has statistically significant better computer skills than 60-90% of all German users. These users might put the tracker aside in frustration if it gets over-complicated.

Several simple personas are described in our user analysis. It's important to design multiple personas. On the one hand, the team recognizes the needs of different user groups instead of focusing on a single one. On the other hand, it reduces the temptation to keep the persona too general or to tailor it to design wishes.

A persona needs the following characteristics

• name and portrait
• Motivation
• Character traits, habits, social environment
• Skills or Disabilities (Limitations)

All of this data is used to shape the persona into a character that the team can identify with.

Example: Diana Haller - Competitive Couple

Diana Haller is a medical student in Munich and wants to become a brain surgeon. She currently uses an old StepTracker every day and shares her daily steps and achievements with her volleyball team and family. She would buy a new tracker if it had better features. Diana is an ambitious person, does a lot of sports and is very focused on her studies. She cycles to university, to swim and to volleyball practice every day.

Scenarios - Concrete narratives

Scenarios are fictional stories about personas, their goals, and activities, mostly related to the application. A scenario can describe a concrete daily routine of Diana and the handling of her current StepTracker.

A scenario highlights the following aspects:

• How does the application affect the Set of the user?
  For example, does the fitness tracker encourage them to climb more stairs and walk shorter distances, or does the persona feel frustrated because the battery died on a long walk?
• What services is the user looking for from the application?
  Does the persona want to increase their step count for a week or two after Christmas to shed the holiday pounds, or set them to get a progress update every day at 12pm?
• What Interpretation follows application feedback?
  How does the user interpret the data when I display it as steps, calories, or mini muffins? How does the persona react when the tracker addresses them like a drill army officer, or like a motivating personal trainer?

Strengths of scenarios are easy to name. It takes little to write a scenario and they are written quickly, making them flexible and easy to refine are. They specify the actual functionality of a system application context, which can have a significant impact on the requirements for the user interface, but is not covered by classic methods such as use cases. And they put the focus on Goals, plans and understanding of users, instead of pure functionality.

types of scenarios

There are four different types of scenarios, some of which have a very different level of detail.

• problem scenarios explore the current practice. They serve to uncover current problems, but also to find positive aspects in current processes. The actual product is not yet available.
• activity scenarios describe which typical and critical services users expect from the application. You focus on them pure functionality and leave out details about feedback and operation of the application.
• information scenarios build on and refine the activity scenarios. They describe how data of the application are presented to the user and how they are presented Information be interpreted by the user.
• interaction scenarios are complete design specifications, which contain the results of activity and information scenarios. In them are supported tasks, the coding of the information and the Application feedback specified, as well as the influence on the actual user.

Like the structure of the personas, problem scenarios are part of the analysis of an application, while the other three scenarios are used to design the application.

Example: problem scenario

Diana Haller is a student and gets up at 7 a.m. She freshens up quickly, eats a bowl of oatmeal for breakfast, and then goes swimming. The swimming pool is a few kilometers away from her dorm, so she bikes there. After swimming, she drives to the university to listen to her lectures for Monday.

On the way to the lecture, she checks her tracker. Since Diana only walked a few steps that day and rode her bike more, it shows a frustratingly small number. So Diana purposefully walks up the stairs to the lecture hall and accepts a few detours. To increase her strides, she even pushes the bike to the library, where she joins a study group.

In the evening Diana trains with her volleyball team. She and her best friend compare the steps they managed that day. Diana's number is still much smaller than usual, and Diana is frustrated that her kilometers on the bike and her strokes are not counted. After being raised by her friend, she tries her best to win the volleyball round.

Claims - pros and cons

Claims are the characteristics of the scenario that affect the user in a positive or negative way. Claims are listed for each scenario. The end result is a list of tradeoffs that can be used to discuss features, situations, and requirements.

A claim analysis for the above problem scenario would look like this:

• Sharing the step count with friends is a social activity and increases Diana's engagement with the fitness tracker.
• Tracking and checking the number of steps leads to healthy behavior in Diana (climbing stairs, running).
• Diana is frustrated by the limitation of her pedometer. She moves slower than necessary to increase step count (walk instead of bike) to increase her objective progress.

How to proceed...

Based on the problem case and the rough user analysis, we developed a persona and wrote a problem scenario in which we examine current practice. We analyzed the scenario Claims. However, as already written, several personas would be required, with which we can then also look at the current practice. We can then check these for claims and incorporate our findings into drafts. Anyone who would like to practice is invited to create a persona for, for example, the Steady stepper (Slide #7) and share it with us.

Further reading:

• UX Without User Research Is Not UX – Why the users should be brought to the table.
• Design Thinking 101 – To bring actual substance behind the advertising term “Design Thinking”.
• The 5 best guides for creating customer personas - For more guidance on creating Personas.
• The Design Sprint Kit by Google – To learn more design frameworks.