Recently, I rediscovered Scenarios as a tool in the design process.

If you don’t know scenarios: They are mini-stories with possible users as characters. Take this very short one as an example:

A parent is worried about a ten-year old refusing to drink milk and wants to know if it really makes a difference that the child is getting very little calcium.

Scenarios on usability.gov, under public domain

You can leave gaps to fill in later

Particularly useful and interesting is that you can deliberately include or exclude information in that stories – You can be very general (like in the scenarios above) or be rather specific on the user’s actions and experiences:

KalBin, a new Wikipedia editor from Lagos, has started a new article on a famous Nigerian televangelist who has received a great deal of news coverage for his political activism in Nigeria, in other African countries, and beyond. However, KalBin has just received a message on his user talk page saying that this person is not notable enough…

From Wikimedia Teehouse Research

Same goes for the users’ interactions with the product you are designing. For example, if you communicate your research findings, you describe the current interaction the product in detail.

Sam wants to upload a new file so Anna (who works remotely) can give feedback on his creation. To do that he copies the file to the whatever-folder and adds it to the projects. This sometimes goes wrong: He forgets…

However, if you want to search for future solutions, you leave out the specific interactions with the product and focus on the general activity or even just motivation:

Sam feels that the draft is in a good stage, but he wants Anna (who works remotely) to have a look at it, too. After Anna reviewed it, she gives some suggestions on…

The way Anna gets to see Sam’s draft is left open, but the story still works; we fill in the gap and we can do it in various ways, imagining a web platform, a file sync, teleconference or a visit of Anna.

Combine with other forms

Scenarios do not need to be just a story: They can be well combined with other forms of communication. For example, here a very eclectic one from wikidata user research:

Intro: This is a relevant scenario for list generation using utilizing Wikidata since data needs to be complete (at least for a given usecase) to generate a good list from it. Though this is part of creating lists, it happens only on Wikidata and the list creation itself is not part ot this.

Example scenario: John notices that his hometown does not have a mayor listed on the hometown’s item. He wants to see which other towns and cities also lack this property and wonders if he could fix it, at least for the places in his county.

Example quote: “I could quickly find out what I wanted to know and correct the data”

Workflow we assume:

1. You “Request a query” or write a query yourself to find to find all places which are municipalities but lack a mayor
2. You find out who the current mayor of every (or some) places is
3. You add that person’s item to the property “head of government” of the city’s item
4. If no item for the major exists, you create the item.

This cockpit project scenario (see opensourcedesign discourse ) is similarly combined of several forms.

And you can also use graphical representations, like this one:

1* the search interface of the library's computer | 2 remembering the code. Is this character a zero or the letter ›O‹? | 3 I can’t find the right shelf! | 4* I'd better ask somebody… …now I know where I need to go!

Scenarios are understandable and robust

Scenarios are meant to be intuitively understandable for the people who need them. I assume this works, otherwise people who are not part of the product development team could not use them for being guided in usability tests (like in tests for XWiki or shotwell usability testing) or in questions to the community (like on lists at wikidata)

Scenarios are rather robust. Even if a scenario is used »wrong«, it is relatively transparent. Let’s say, a person makes up a scenario based on how he/she wants the user to behave. It is easy to ask: »Is this actual behavior we observed or is this a scenario of a possible future product?«. Contrast this with personas. If a persona is invented in wishful thinking, it is often hard to question: »Is this [entire persona] research based?« – »No, but…«.

So, if you search for a way to bridge research, ideation and implementation, scenarios are worth a try.

Literature:

If you are interested in some background information, I recommend:

• General: Carroll, John M. Making use: scenario-based design of human-computer interactions. MIT press, 2000.
• General: Carroll, John M. "Five reasons for scenario-based design." Interacting with computers 13.1 (2000): 43-60.
• On interplay of scenarios and personas: Blomquist, Åsa, and Mattias Arvola. 2002. “Personas in Action: Ethnography in an Interaction Design Team.” In Proceedings of the Second Nordic Conference on Human-Computer Interaction, 197–200. NordiCHI ’02. New York, NY, USA: ACM. doi:10.1145/572020.572044.
• Practical use of scenarios: Hertzum, Morten. 2003. “Making Use of Scenarios: A Field Study of Conceptual Design.” International Journal of Human-Computer Studies 58 (2): 215–39. doi:10.1016/S1071-5819(02)00138-6.
• Uses of stories in making sense in organizations (Chapter "the substance of sensemaking", p129, »Stories are Mnomics that enable people to reconstruct earlier complex events«): .Weick, Karl E. 1995. Sensemaking in Organizations. SAGE, ISBN: 978-0-8039-7177-6.

Using scenarios at different stages

An overview with examples*

• User Need Research:
  • Make your assumptions explicit: Write scenarios how you think users behave. Also good as a team task: Inconsistent assumptions between peers might make interesting research tasks.
  • Document what how and why users do what they do in scenarios after the research
  • Use scenarios as a research input for users to give feedback on, something we did at Wikidata to gain feedback on how people generate lists
• Ideation
  • Write scenarios focusing on activities and motivations to leave the way of implementation open
  • Write scenarios with possible solutions to user problems. By that assumptions can be made explicit. Might work well together with sketches, roleplay or anything else which is lightweight and graspable.
• Implementation
  • Communicate the intended use, as done in this cockpit project scenario (see opensourcedesign discourse )
  • Find possible problems or conflicting assumptions by going through implementation suggestion and scenario.
• Testing
  • Write scenarios leaving out the implementation and needed steps, so they can be used as input for users who test the product while providing some context. See examples for XWiki, with follow up process and examples for shotwell usability testing

This post builds on examples by members of the opensourcedesign community

Using scenarios in design by Jan Dittrich is licensed under a Creative Commons Attribution 4.0 International License.