Good software design starts with a clear problem statement
Getting a development team in the user’s headspace is half the battle toward good software design. In the double diamond method, we discussed the value of finding out what problem a user is facing before trying to build something. A product without a clear pain point to alleviate will have trouble finding an audience.
Defining a problem statement puts you on the path to building something people will use. As your team continues on the next convergent and divergent paths of the double diamond, you will use this problem statement as the guidepost for your users’ point of view. One of the best ways to help define the problem statement is by building an empathy map.
User interviews give good software design its empathy
Before developing an empathy map, you need to conduct user interviews. They give you the information you need to re-frame the user experience and get your mind in the same place.
Often in the ideation phase, we assemble a team with a wide array of subject matter experts from a single company. Thinking through user needs and finding solutions isn’t necessarily something they’re used to. An empathy map gives them something to follow as they think strategically from a user’s perspective.
In a lot of ways, it’s like wearing someone else’s glasses (or stepping into their proverbial shoes). Hopefully you get to a point where you see what they are seeing, feel what they are feeling and generally sense all the other senses they’re sensing. The goal is to experience what a user experiences — an empathy map helps center you in a situational context. It shows you where the pain points are, and those pain points are each opportunities for disruption.
The characteristics of good software design are the same as any other design work: put yourself in the shoes of the end user and work toward what they need.
Find a new product in 5 days? Learn how with our free Google Design Sprint ebook.
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.
Published by Product Design in Design Thinking|User Research