What is this technique about
A scenario is a written plausible narrative of the future based on a coherent set of assumptions. Scenarios specify how and why users carry out their tasks with a solution in a specific context to reach a particular goal. A goal is a final purpose or aim, an objective driven by a need. Future users with their needs, goals and their motivation are described with the use of “personas”. Personas are not real people, but they represent them throughout the design process. They are hypothetical archetypes of actual or possible users. Although they are imaginary, they are defined with significant rigor and precision.
Scenarios can have different levels of detail (Sutcliffe, 2002). A high-level scenario is a story or example of events taken from real world experiences and may include details of the usage context. A detailed scenario is a future vision of a ready designed solution with sequences of behaviour and possibly contextual description. In this case a scenario comes close to a design mock-up.
Where does it come from
The scenario technique has its origins in military planning and strategic foresight. The technique was first developed by the RAND Corporation in the 1950s, a nonprofit organization that originally provided research and analysis for the US military.
The scenario technique was initially used by the military to explore different possibilities and outcomes in the event of a nuclear war. The technique involved creating a set of scenarios that described how different countries or actors might respond to different military strategies, and then analyzing the potential consequences of each scenario.
Over time, the scenario technique was adapted for use in other contexts, such as business planning, public policy, and environmental forecasting. Today, the scenario technique is widely used in a variety of fields, including strategic planning, risk management, innovation, and design.
While the origins of the scenario technique are rooted in military planning, the approach has been adapted and refined over time to be more inclusive, participatory, and creative. Modern scenario planning often involves engaging stakeholders and experts in the scenario creation process, using a variety of research methods and data sources, and emphasizing the importance of imagination and creativity in exploring different possibilities and outcomes.
For which purposes it is used (why in your engineering teaching)
Building “Scenarios” is a quick but rigor method to vision an idea or solution. It can be done in a workshop lecture are as a groupwork for single teams. The strength of the method is that it focuses on the users´ goals and needs, when visioning an idea. The groups can use scenarios to test and refine their designs, by imagining different scenarios and exploring how users might respond to them. Still the resulting scenarios serve as a boundary object for the communication of the idea to the various stakeholders within a project.
How to use it
A scenario (Goodwin, 2009) is a textual description of a persona´s interaction with the future solution, may it be a product, service or process. Each scenario begins with a specific situation, then describes the interaction between the persona and system from the beginning of a task or session through its completion. A scenario describes the actions of the persona and any behaviour or actions of the product, service or process evident to that persona to reach her intended goal. Along the way, a good scenario explains the persona´s motivation and emotions for particular behaviour and indicates what persona goals the solutions’ behaviour achieves.
In the early phase of the design process, the scenarios are high level and optimistic, focusing on ideal solution behaviour in situations that will happen. Scenarios do not include specific internals of a solution. Rather, they describe an entire session or typical task based on what the persona would see as the task´s beginning and end. This could involve a single function or several dozen.
The method allows three degrees of freedom to play with:
- The context in which the future solution is reasonable and will be successful
- The persona, the target user, for whom the solution will be valuable and usable
- The goal to accomplish meets a certain need of the persona
For example, the idea is to invent a special scent in order to prevent cats from chasing mice because cats bring the dead mice into homes. The target users would be families, which own cats as pets. But what is the real goal? To prevent mice from chasing, their natural behaviour? The goal of the families would rather be not to have dead mice in their homes. So, another idea supporting this goal is to invent a special cat lock, which only allows cats to pass and no mice. Such a lock would also be useful for bird conservation areas to prevent cats from entering. This second, derived scenario supports a very different goal.
All three attributes, goal, persona and scenario, should result in a meaningful sequence. The scenarios typically contain lots of requirements for the solution. It may be useful to extract these requirements for the detailed design and implementation phases.
How to implement this techniques online
- Split the class in groups or teams, if not already done.
- Each group will work out scenarios for either their design problem or a given set of ideas.
- Prepare a digital whiteboard for the groups.
During application, i.e., while giving the session
- Explain the method to your class.
- Stress that the scenarios shall cover a user goal, a context and the interaction with the future solution.
- Sometimes it helps the students to first draft the scenario skeleton with sticky notes.
- Let the students do groupwork for around one hour to write down a set of scenarios.
Follow-up, about what to do after the session
- Debrief and wrap up, e.g. let each group or team present their scenarios.
- Store the whiteboard.
- The scenarios typically contain lots of requirements for the solution. It may be useful to extract these requirements for the detailed design and implementation phases.
Examples and/or testimonials
Below is an example from the course “User Experience Design” at Hochschule der Medien of Prof. Dr. Christoph Kunz. The scenario shows how the persona “Daniel, 25, hobby skater” uses a bonus program app for credit cards.
- It’s Sunday evening. Daniel wants to buy new skate shoes and looks at various models on his smartphone in his favourite online shops. He puts some of them on his watch list.
- Since he wants to have the shoes as soon as possible, Daniel decides to stop by the skate shop around the corner during his lunch break on Monday to see if a few of the models are available.
- Daniel sees that he still has a voucher for the skate shop that he could use. There is also a longboard on sale for which he would get 4 points.
- On Monday, Daniel finds his favourite pair of shoes in the shop and sees that he can get them even cheaper than online when paying with the app. In addition, he sees a preview of his points balance after the purchase.
- He buys the shoes and uses the voucher. He hesitates about the longboard because the offer is still valid for a while. The information about the purchase and the score are updated immediately and saved in the app.
- Meanwhile, he gets an invitation to a skate event. This could also be paid for with bonus points.
You will need a platform to share screens and communicate with the participants, such as: MS Teams, Zoom or similar. You will also need a white board solution with digital sticky dots such as Miro or Mural:
- MS Teams
- Timer (phone, watch, computer)
NNgroup. (2019, August 23). Scenario Mapping for Design Exploration. [Video]. YouTube. Available at: https://youtu.be/dmlFRCZI9gQ
Goodwin, Kim (2009): Designing for the Digital Age: How to Create Human-Centered Products and Services, Wiley, ISBN: 470229101.
Star, Susan L.; Griesemer, James R. (1989): Institutional Ecology, ‘Translations’ and Boundary Objects: Amateurs and Professionals in Berkeley’s Museum of Vertebrate Zoology. In: Social Studies of Science 19, No. 3, pp. 387–420.
Sutcliffe, Alistair (2002): “User-Centred Requirements Engineering: Theory and Practice”, Springer, ISBN: 1852335173.