Crafting User Scenario Hypotheses
A workshop tool for capturing givens and creating alternatives to guide creating plausible, probable hypothetical user scenarios
Good user scenarios are based on user research. But what do you do before you conduct research? You make a hypothesis.
Hypothesis: a supposition or proposed explanation made on the basis of limited evidence as a starting point for further investigation.
This is a tool I created for a workshop where we were creating potential scenarios for a new product concept. The workshop was the beginning of a process to determine what interaction paradigms the new platform should be support. We seeded the workshop with an existing app that works on a different platform.
The Five W’s: Who, What, Where, When, and Why
With this framework, instead of jumping straight into writing scenarios, we first gathered the ingredients that would make up the scenarios. I went back to the basics here with the Five W’s:
- Who was involved?
- What happened?
- Where did it take place?
- When did it take place?
- Why did that happen?
I modified them a bit to help spur the discussion specifically for product oriented user scenario building. The goal is to first list out all the possible alternatives for the Five W’s, and then start building scenarios using combinations of those answers.
Process Note: I printed out individual sheets for people to take notes, but we worked through the Five W’s together on the whiteboard before individually writing scenario hypotheses.
Who — describe the person using the system
- Age?
- Profession?
- Physical abilities?
- Alone or with others?
- Are they the owner of the system?
For example, in our workshop we ended up with a teenage student, a teacher, an engineer, and an mechanic on our list of who’s.
What — describe what that person is doing with the system
- What type of thing are they doing? Is it for entertainment, education, productivity, etc?
- Get specific, what are they doing? “They are [verb-ing] [noun]”
- Is it a snack, a task, or a job?
I recently started using the categorization of snacks, tasks, and jobs to describe the duration and depth of an interaction a person has. A snack is like quickly checking notifications and maybe using a quick reply to respond to an email. A task is something that takes more time, be it 5 minutes or an hour, that has a start, activity, and an end. And finally a job is describing a type of activity that spans the duration of the day.
Where — describe where the person is in relation to the system
- Physical location? (home, work, retail, etc)
- Within that space, where is it? (kitchen counter, desk in cube, store window display, etc)
- Height of the system (ground, desk, table, counter)
- Is the person standing, sitting, lying down?
The tech world is moving beyond just screens, so the “where?” question gets more interesting than just physical location when thinking about how this affects the use of a system. Time to get familiar with lots of human factors and ergonomics!
When — describe the person’s interaction with the system over time
- In one session, how long are they interacting with the system?
- Is it a one time interaction?
- How frequently do they interact with it?
- When during the day do they interact with it? When during the week? The month? The year?
Why — describe the goal of the person
- They are successful if…
The why might feel redundant, but it’s actually critical for writing up the user scenarios. Without the why there is no purpose behind the scenario.
Scenario Hypothesis Sketching
After walking through all the Five W’s, then you can start scenario building. What I ended up doing for this workshop was have everyone take five minutes and silently write down scenarios. A scenario included a bulleted list of which who, what, where, when, and why was being addressed and a descriptive name for the scenario. We ended up with only a handful of overlaps in scenarios, and generated additional scenarios after we came back together and reviewed them as a group.
From here, the next step is to flush out the scenarios into something that I referred to as a storyboard thumbnail sketch. Focusing more on the content of the storyboard than on the visual drawing of a storyboard. The first panel is the setup, the second panel is the action that happens, and the third panel is the resolution. Actual visual sketching isn’t necessary here, the storyboard “sketch” can be bulleted notes. Now you have multiple scenario hypotheses can then be prioritized for user research.
This is a new workshop tool and it’ll need tweaks and refinements, but so far I’m feeling good about the results we got from the first use and I’m excited to see how we continue from here.
