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 too! What do you do with this mess? How do you turn a hundred little insights into  knowledge  that you can to inform your design process? And what form should that knowledge take?

Ultimately, any effort to make sense of a problem is one of  interpretation  and  synthesis . Your goal in reflecting on your insights is to try to understand several aspects of the data you have:

• What  patterns  do you see in the way people describe their problem?
• What do you know about what’s  causing  the problem?
• What are the various  consequences  of the problem?
• Which aspects of the problem seem  changeable ?

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  and  values  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 ^{1,5 1}

Adlin, T., Pruitt, J., Goodwin, K., Hynes, C., McGrane, K., Rosenstein, A., and Muller, M. J. (2006). Putting personas to work. ACM SIGCHI Conference on Human Factors in Computing (CHI).

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 eating habits:

(Yes, that’s me.)

A persona is only useful if it’s  valid . 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 what you’re imagining will be fantasy.

In addition to personas, you can also define  scenarios ^{3 3}

Bødker, S. (2000). Scenarios in user-centred design—setting the stage for reflection and action. Interacting with Computers.

For example, here’s a simple dinnertime scenario:

(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 scenario 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 ^{4 4}

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).

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?

• We want to make it easier to make dinner.

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.

• Few people have time to make a healthy dinner.
• We want to make it easier to make a healthy dinner.

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:

• Millions of Americans get home from work with little time to cook a meal, let alone a fresh healthy meal.
• The result is that many Americans and their children eat unhealthy meals on most weeknights.
• This contributes to many chronic diseases such as obesity, heart disease, and diabetes.
• It also means that few Americans can enjoy the true pleasures of tasting fresh, local food.
• We’re going to design a service that addresses all of these problems...

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? Which one captures the essence of the problem you’ve observed in your community? 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. They help model the causality of a problem, revealing factors that influence, events that trigger it. They also highlight the consequences of the problem, surfacing what about the situation is undesirable to the people you’re trying to design with or for.

Capturing these models of problems is essential in design contexts where designers are separate from stakeholders; the models can act as a form of  boundary object ^{2 2}

Barrett, M., and Oborn, E. (2010). Boundary object use in cross-cultural software development teams. Human Relations.

It’s also key to surfacing who precisely is benefiting from design, which is key to ensuring that design efforts are equitable, helping to dismantle structures of oppression through design, rather than further reinforce, or worse, amplify them.