Back to table of contentsCredit: Oxford English Dictionary
So you've done a bunch of interviews, contextual inquiries, observations, and research. You have a big pile of data, insights, and thoughts. You probably also have a big pile of design ideas. What do you do with this mess? How do you turn it into knowledge that you can use for design? And what form should that knowledge take?
The how here is a form of interpretation and synthesis. Your goal in looking through the data is to try to understand several aspects of the data you have:
In answering these questions, you can generate many forms of knowledge that will help you organize your understanding and evaluate which ideas you generate will be effective. Let's discuss some of these different forms, what they are, and what they're good for.
One simple form of knowledge is to derive goals from your data. What are people trying to achieve? For example, let's say you did a bunch of interviews about trying to find a place to rent in Seattle. One person talked about trying to afford rent, another person talked about trying to save time by finding the right location, another person had a physical disability that made the layout of the house important. You need to extract these goals and represent them explicitly and try to understand what they are. Different designs may serve different goals, and so understanding the space of goals that you might design for is critical.
Another form of knowledge to distill is who you're designing for. Many designers will capture this in the form of personas, which are fictional people that you've described that attempt to capture the different types of people you might design for. They include demographics such as education, income, technical background, job description, goals, needs, desires, current tools and frustrations, likes and dislikes, and hobbies and interests. For example, here's a persona about someone and their music listening preferences:
Andy Guo is a professor who works long, long days. He really values fresh, flavorful food, but he rarely gets home before 7, and by then, he has barely enough energy to get house chores done, let alone cook a fresh meal. He's also usually quite hungry by the time he gets home, since he eats between noon and 1. Instead, he ends up eating a frozen dinner or leftovers or just eating out. He's frustrated how poor he eats and how much money he spends eating out. He certainly doesn't want to spend more time cooking.
(Yes, that's me.)
If these details are accurate with respect to the data from your research, then you can use personas as a tool for imagining how any of the design ideas might fit into a person's life. If you just make someone up and their details aren't grounded in someone's reality, your persona will be useless, because your imagining will be fantasy.
In addition to personas, you can also define scenarios, which capture what a person might attempt to do with something you design. A good scenario defines, who, what, when, where, why, how, and how often someone tries to accomplish a goal. A good scenario is specific, it specifies goals, but it does not specify interaction details (leaving those to be filled in with design ideas later). For example, here's a simple music listening scenario:
It's Friday at 7:30 pm and Andy is really tired after work. His wife isn't home yet—she had to stay late—and so while he'd normally eat out, he's not eager to go out alone, nor is he eager to make a big meal just for himself. He throws a frozen dinner in the microwave and heads to the living room to sit down on his couch to rest his legs. Once it's done, he takes it out, eats it far too fast, and spends the rest of the night regretting his poor diet and busy day.
(Yes, that's me too.)
Scenarios are closely related to the idea of use cases, but differ in when they're created. You create a scenario before you have a design, to capture the problem context you want to address. You create use cases after you have a design, helping you specify the intended use of a design.
It's very unlikely that one persona and one task is going to faithfully capture everything you learned about the problem you're trying to address. Create as many as you need to capture the diversity of the the goals, the people, and the scenarios you observed. And if you really want to be rigorous about scenarios, use methods such as claims analysis to trace your scenario details back to data.
Once you have defined goals, personas, and scenarios, the final challenge is to try to explain the problem you're solving to other people. If you can't do this, you can't convince them you have a real problem to solve, you can't convince other people to help you solve it, and you certainly can't convince a boss or an investor that you should spend time on solving it. Therefore, you'll want to take all of the knowledge you have and try to write a simple argument that articulates the problem.
As an example, let's assume we're trying to solve the problems in the persona and scenario described above. How can we explain the problem in a persuasive, logical manner that's grounded in all of the research we did on the problem?
That's a pretty lousy argument. The whole problem is bundled up in the word "easier". We're not going to convince anyone with bland, vague statement like that. Let's try to break it down.
That's marginally better, as it breaks down a problem and a solution space. But who are these people? And why don't they have time? And what does "easier" have to do with time? Let's try again:
Better, right? It shows the scale of the problem and it shows multiple consequences of the problem. It even adds a bit of context to the problem, talking about weeknights specifically and the types of food that Americans can't enjoy. It leverages the detail from the scenario and persona, but integrates them into a logical argument.
Now, compare it to the first one we wrote above: which problem are you more excited about solving? Which one would you green light if you were a manager? Which one would you fund if you were an investor? The beginning (and end) of any good design process is an impenetrable argument for the importance of what you're doing.
Notice how a good argument actually looks something like a scenario. The difference is in the structure and the intent. The scenarios are structured as narratives and you create them to help you envision and test design ideas. Arguments, in contrast, are inherently about the causality of a problem and you write them to persuade someone that a problem is real and important.
Because problems are about causality, before you try to write a problem argument, it can be helpful to model the causality of a problem. What are the factors that influence a problem? What events trigger the problem? By making these explicit, perhaps by drawing a diagram, the task of writing a problem argument becomes easier, because you can see the problem you're trying to describe in words.
Adlin, T., Pruitt, J., Goodwin, K., Hynes, C., McGrane, K., Rosenstein, A., & Muller, M. J. (2006, April). Putting personas to work. In CHI'06 Extended Abstracts on Human Factors in Computing Systems (pp. 13-16). ACM.
Bødker, S. (2000). Scenarios in user-centred design—setting the stage for reflection and action. Interacting with computers, 13(1), 61-75.
Carroll, J. M., & Rosson, M. B. (1992). Getting around the task-artifact cycle: how to make claims and design by scenario. ACM Transactions on Information Systems (TOIS), 10(2), 181-212.