Empathy: It’s Not Just for Users Anymore

Tips for writing research reports that meet your teammates where they are.

Published in

Meta Research

5 min readApr 23, 2018

We researchers are experts at empathizing with users. We go into the lab or the field and leave our own experience at the door. We turn our focus onto the needs, aspirations, lives, and pains of the people we’re building products to serve.

And then we come back to our desks and communicate that empathy to our stakeholders.

In a deck.
With bullets.
Sometimes
many,
many
bullets.

It can be easy to throw all of our thoughts into a wordy deck, but this format is difficult for nearly anyone else to read.

We think there’s a better way.

What if we turned our empathy chops onto our teammates, producing reports that take their experience into account, just like we do for the people using our products?

When we apply that same empathetic attention to the people building our products, we can identify four basic facts of life for our teammates — call them pain points. We can also see four things we can do to create reports that address those pain points — call them product recommendations.

Let’s take them one by one.

1. Our teammates are busy, so be concise

Your teammates trust that you did your research thoroughly. Now they want to learn from it, as quickly as possible. There’s a whole landscape of information you could share with them. But your job is to focus on what’s important to your team.

Many researchers come from academia and are used to writing extremely detailed, comprehensive, and jargon-y reports meant for other researchers to read. But on a product team, we face a different audience. Keeping the message short is more important than being comprehensive. Imagine that you had to boil down your findings into a single, powerful insight: what would it be?

2. They’re overloaded with info, so be memorable

It’s great to make our reports pithy, focusing just on what’s important. But we want our ideas to be remembered, not just read. Our teammates are flooded with information all day long. To be memorable, we need to be direct, catchy, and relevant.

Strategies for making your reports more relevant include mapping out a larger narrative or journey you want your reader to go on, using visuals wherever possible, and breaking your reports up with informative headers that answer questions as they arise. For example, instead of the dry and jargony section title “Methods,” try a short description that will be more meaningful to stakeholders: “Why we interviewed small business owners in India.”

3. They need to make decisions, so be actionable

Collecting and synthesizing data is often the thrilling part for user researchers. We learned so much! We have so much to tell you! But what should the team do about it? There’s often plenty to say about all the things that are wrong with a product; how do we help stakeholders make them better?

We like to think about getting actionable in three steps.

First, articulate the problem: something isn’t working for your user. What specifically is the issue? For example: “Navigation is challenging, and users struggle to find the controls they need.”

Then, we can zero in on a user goal: the user experience we want to achieve. Often we can articulate the goal simply as the inverse of the problem. For the above problem, a goal might be: “Users feel confident when they navigate the product and empowered to find the controls they need.”

Finally, we make concrete suggestions. This point can be controversial: some user researchers prefer to offer insights but leave the solutions up to the stakeholders. We think concrete suggestions are important for a couple of reasons. First, they provide another way to illustrate the disconnect between the problem and user goal. They also help start the conversation about possible ways to approach the issue. You may not provide the solution your team ends up going with, but by providing some possible ones, you get the ball rolling. For example, you might suggest that to make the needed controls more discoverable, they need to be highlighted in a more noticeable color. This likely won’t be the ultimate solution, but even a bad idea can be helpful if it gets people to think: “I can come up with a better solution than that!”

4. They have their own constraints and concerns, so be open

Building product solutions is a team effort. Our insights and suggestions are powerful starting points, but it takes the whole team to come to the best ultimate solution. Everyone on the team will do better if we as researchers are genuinely open to their constraints and concerns.

At the end of a study, we may have a lot we want to share. So many insights! And stories! And ideas! A great first step is to write it all down. And a great second step is to talk to your teammates about what information is actually going to be useful to them. Our reports can pack way more punch if we deliver a narrative that meets them where they actually are, rather than where we think they are.

From Empathy to Action

Being concise, memorable, actionable, and open isn’t easy. Writing reports with these principles in mind often means more work for us. But the more we help our teammates understand, remember, and apply our work, the more we can ensure that our original empathy for users gets transformed into real improvements.