Designing with Scenarios: Putting Personas to Work
This article is an excerpt from the podcast that Adam and Kim recorded after her virtual seminar, Designing with Scenarios: Putting Personas to Work. You can hear the full podcast or read the transcript on the podcasts page.
Adam Churchill: Is it a true that scenarios only work if you have have data-driven personas? Have you seen scenarios used effectively, even if the research can’t be funded?
Kim Goodwin: Great question. I think that you can do scenarios without data.
It’s better to have data if you can because it has a few benefits. One is, you’re more confident that you’re getting to a good answer. And it makes it a lot easier to make design decisions because instead of wondering how a person would react, you actually know. This is assuming you know them well.
Think of it like you’re planning an event, or buying a gift for someone close to you, versus, say, buying a gift for your child’s teacher or an acquaintance you don’t know well.
The first one is a whole lot easier than the second one, and data gives you the confidence that you’re doing the right thing. Secondly, the data helps you persuade stakeholders. It’s not you, the designer, who is probably pretty low on the totem pole, saying this is how it should be. It’s you, the designer, channeling the users and saying, “Look, based on our data, here’s how people think and act, and so here’s why this is a great solution.”
So, data is best, but not always necessary. I definitely do scenarios without data. A few weeks ago, I was working with some subject matter experts on an idea for a medical device. Four of us sat in a room, and we didn’t have data. The point was to get to some design ideas fairly quickly, so that they could explore the feasibility of this idea.
It didn’t make a lot of sense for us to go get data, and we said, “OK, let’s build some shared assumptions about the kinds of users we’re talking about.” We came up with what I call provisional personas, which are like sketchy representations of what we think the usage patterns and goals are. Then we used those to create scenarios just as we normally would.
Regardless of the absence of data, scenarios are a design tool you can always use. You’re just going to be making decisions and communicating with a bit less confidence when you don’t have data. But the tool still works great.
Adam: Can you explain the difference between scenarios and a storyboard?
Kim: A scenario is the story, it’s the script. It’s the words that describe the action. A storyboard, on the other hand, is the graphic depiction of that action. For instance, the movie extras on your DVDs or your Blu-ray where they show scenes building or sketches stuck on the wall. That’s what I mean when I talk about a storyboard.
It’s essentially at a thumbnail level, but the key to storyboarding is the depiction of sequence over time, right? A storyboard can be a very rough napkin sketch. If you’re talking about a high-level service design, like getting through the airport, you might have stick figures walking through physical space. If you’re doing just a screen-based design, you probably won’t storyboard your first pass at the scenario because it’s so high-level, you’re not really getting into solutions.
But then as you start to get into more detail in design, you’re going to keep storyboarding at the whiteboard, drawing multiple instances of a screen and how it changes over time. As you start to express that design and share it with stakeholders, you can have storyboards at that wireframe level, where they’re pretty much content and control complete, but you haven’t really incorporated any visual design.
You can still use that storyboarding approach down at the pixel level where you’re showing changes in screen state over time like putting them in a PowerPoint presentation or something similar and flipping through them. It’s similar to keyframing, like they do in the movies. So storyboarding is essentially a sequence of pictures that tell a story, and the scenario is the text of the story itself.