Good software design starts with a clear problem statement

How an empathy map is built

The image below is the elements of the empathy map laid out visually. Let’s cover each section’s goals and how they add the end goal of user understanding.

Tasks: What is the user doing?

What is the activity they are undertaking? It may seem elementary to lay out in this level of detail, but your team is trying to do everything possible to immerse themselves in the worldview of the users. Starting with a stray assumption or two here can throw off everything that comes after. The more specific you can get, the better.

Feelings: How is the user feeling about the experience?

What emotions come up around this task or activity the user is undertaking? The way a user feels is important for how you approach a solution. Do they feel negative towards a task? How does your team alleviate that negative feeling? Do they feel good about a task? How do you increase the amount of positive feelings?

Influences: What people, things or events affect the user?

Tracking all of the outside forces that can alter how a user feels or acts in a certain situation shows you where your model might break down. For example when working with Tyson foods to develop a high protein snack food on the go, we found the users (parents on the go) were highly influenced by the need to get their kids healthy food that wouldn’t make a mess in the car. Without seeing the paint point from that users point-of-view we wouldn’t have been able to know the outside influences that affect their decisions. This can be an important way to connect the dots between feelings, goals and pain points.

Goals: What are they trying to accomplish with this task?

No goal is too small. While your user is likely working toward one particular outcome, there are likely several smaller goals along the way that make it possible. By finding the goal in the task at hand, you are finding the user’s truest motivations.

Pain points: What makes it hard for the user to achieve their goals?

This is often where your eventual problem statement starts to emerge. As you lay out the tasks, feelings, influences and goals, you’ll find the obstacles that complicate the path. Listen for an unmet need, a conflict or an ongoing annoyance that is taxing for the user.

Building the problem statement as a “how might we…?”

Once the empathy map is built, your team will have all of the details necessary to think like a user. With their point of view in mind, we can build a problem statement that starts with a “how might we?”

This format opens up the range of possible answers so we can think more creatively about solution generation. The verb directly after “how might we” should be actionable. Something like “how might we teach..” or “how might we provide…” gives context and intent to the problem statement.

You’ll likely generate a lot of potential problem statements — there are many ways to think through an obstacle. When we have a solid list, we usually turn to dot voting to help us decide. Everyone can democratically offer their insights and support so you can choose the statement that best fits for the most people. That statement will become a beacon for the rest of your goal of good software design.

Your next step will be to tackle the second diamond of the double diamond method.

If your company needs help breaking down big ideas into manageable problem statements — like we did with Tyson Foods and Brink — let’s start a conversation.