Use Empathy Maps to build better software

Building Awesome products requires a deep, emphatic understanding of your users. What do they need? What drives them? How do they experience a particular product or process? In this post I explain how to use Empathy Maps and interviews with users to build this understanding.

About Empathy Maps

Empathy Maps are a simple, powerful tool to build understanding of your users. It is no wonder that they are the nuts and bolts of UX-designers and are commonly used in Design Thinking. The name derives from 'Empathy', which refers to the ability to understand what another person feels and thinks. A search on Google yields many different templates, but I find the one below (from EventModelGeneration.com) the most practical and complete:

You can create one Empathy Map for all users, or multiple maps for different segments or individual users. In any case, the best Empathy Maps are based on real data. Not on conjectures or assumptions that you make as a team. This means that a good Empathy Map requires that we go out there and talk with real users.

How to make an Empathy Map

  • With your (Scrum) Team, identify users or customers that you can interview for a period of 30 to 60 minutes. If you interview multiple users, try to find different types of users. Include unhappy users whenever possible. Their perspective often yields intriguing insights;
  • Prepare the interview with your team. Create a list of open-ended questions that help you understand users. Although we are ultimately interested in building a good product, Empathy Maps are not intended as a way to test product ideas. So focus on the user; what kind of work do they do? What are the challenges they face in their work? What frustrates them? What would they expect from a product? The Empathy Canvas shown above offers ideas for the kinds of questions that you can ask;
  • If this is the first time you're going to interview users, it might be beneficial to practice the interviews within your team first. Take turns and practice asking open-ended questions and taking notes at the same time;
  • Interview the users. You can do this with the team or you can break up into pairs. Make sure that everyone in the team is involved in the process. Take notes during the interview or record it (with permission from the user, obviously);
  • When you’re done conducting the interviews, gather with your team to synthesize the information and extract key insights. Using large printouts of the Empathy Map, write down insights, quotes from users and behaviors on post-its and put them in their corresponding areas of the map;
  • When you're done creating the maps, reflect on them as a team. What do they tell you? What insights have we gathered? You can either use the maps themselves as input for idea-generation, or you can proceed with other techniques (like brainstorming, visualizing the customer journey, etc);

A team at ProRail, creating personas to build empathic understanding of their users

How to make good use of Empathy Maps

There is no point in creating an Empathy Map that never gets looked at again. Empathy Maps allow us to look at our product through the eyes of our users. This perspective is easily lost as time progresses, making it all the more important to keep the users tangible and visible. Below are a couple of tips:

Empathy Map in a picture frame, by Paul Boag (Boagworld.com) Empathy Map in a picture frame, by Paul Boag (Boagworld.com)

  • Empathy Maps can easily be turned into Personas. A Persona is a fictitious (or sometimes real) user. They describes key traits, behaviors and expectations. One way to do this is described here;
  • Some teams frame their Empathy Maps into picture frames and keep them somewhere visible. I once coached a group of teams at ProRail who did this. They also created Personas based on real people, and invited these people to (occasionally) attend the Sprint Reviews;
  • In the absence of real users, Personas and Empathy Maps are useful during Sprint Planning or Sprint Reviews. Because they make users tangible and visible, they help us to look at our product through their eyes. Would they understand a new feature? Would they like it? What might be frustrating to them?;

Good luck building Empathy Maps! Let me know what your team has learned through the process of building them. I'm always looking for great examples of real Empathy Maps as well. So if you've got one, let me know in the comments.

Christiaan Verwijs
Christiaan Verwijs

Scrum Master, Trainer, Developer & founder of Agilistic