The Paradox of Empathy

If I’m ever asked what’s most important in UX design, I always reply “empathy”. It’s the core meta attribute, the driver that motivates everything else. Empathy encourages you to understand who uses your product, forces you ask deeper questions and motivates the many redesigns you go through to get a product right.

But empathy is a vague concept that isn’t strongly appreciated by others. There have been times when talking to product managers, my empathy driven fix-it list will get “We appreciate that Scott, but we have so much to get done on the product, we don’t have time to tweak things like that right now”. Never do you feel so put in your place when someone says that your job is ‘tweaking’.

The paradox of empathy is that while it drives us at a very deep level, and ultimately leads us to big, important insights, it usually starts small. The empathic process usually notices simple things like ineffective error messages, observed user workarounds, or overly complicated dialog boxes. Empathy starts with very modest steps. However, these small observations are the wedge that splits the log, it’s these initial insights, if you follow them far enough, opens up your mind and leads you to great products.

The most exciting phrase to hear in science, the one that heralds the most discoveries, is not “Eureka!” but “That’s funny…”
— Isaac Asimov

The problem designers have is that we lead with our gut, we never say “we’re exploring new product concepts”, but “that error message is confusing”. We start design conversations with the empathy equivalent of “That’s funny…” No wonder we are accused of ‘just tweaking’ by people who don’t understand design: we’re burying the lead.

Designers will be the first to admit that not every empathic observation leads to a miraculous insight. However, it’s called “Design Thinking” for a reason: it’s how we process and explore, taking a complex problem and breaking it down before we build it back up. Product managers seem to expect a designer to walk up to a product, say something brilliant, and drop the mic. Experienced designers deeply understand a simple fact: design isn’t a deliverable, it’s a process. A process paved with dozens of small empathic observations that lead you, slowly, iteratively to a better product.

The problem for us designers is that our fellow teammates don’t always think this way and unfortunately, we as a community don’t reflect on this difference. It’s ironic that designers are passionate about how a product interacts with people but not how they themselves interact with their team.

Because, if we’re honest, many of these initial empathic observations often lead no where, we end up of having a bit of a credibility problem. When are we recommending a critical fix and when are we fixing a corner case that really doesn’t matter? It sounds blasphemous but not every design problem deserves precious developer resources. The paradox of empathy is that it is both our greatest strength and our biggest curse. We need to upgrade how we use empathy, keeping it as our core internal super power but learning how to expose and communicate that ability to the rest of the world.

Empathy is too broad of a concept, it’s a state of mind, not a specific technique. It’s helpful to frame empathy within the product context.

Design Empathy

Early in the product process, empathy is what turns your ‘users’ into ‘people’. You don’t just ask them what features they want but what they are trying to accomplish. This type of empathy has nothing to do with the specifics of your product. It’s just trying to understand what users want and need.

Bridging is where you are allowed to put on your product hat and come up with solutions for the very real people you now understand better. A classic design aphorism is that many people don’t want a quarter inch drill, they just want a quarter inch hole. We so often forget “the why” and bridging empathy leads to market insights that help define the very nature of a product.

Once you have a product concept that meets a real need you have to get the flow right. Where do they start? How many concepts/icons/choices must they understand? How does the product flow? Without clear empathic understanding of what your users need, products tend to throw the book at them, offering every possible option. This is indeed powerful, but the flow is overly complex and you’ll confuse and loose many.

Refining is where delight happens. An auto filled dialog box that saves you typing, a clean structured layout making it clear what to do next, or a simple animation to indicate the task is done are all little things that save people time but also make the product feel professional and trustworthy.

Break out of Refining Observations
My plea is simple, let’s stop leading with our internal process, exposing our initial observations and instead focus on the end result. Stop making lists of everything we don’t like, as I did with that product manager, and instead move up the intellectual stack and start framing our concerns as flowing, bridging, or understanding tasks. Of course, refining fixes are important too! That dialog box really is ugly/confusing/misleading but keep that to yourself, at least for a little while. Trust your gut, that cretinous little dialog box is likely hiding a much bigger problem. For a good example of this, read Don Norman’s Error Messages are Evil. Notice how he takes a simple problem and upscales it near the end.

The paradox of empathy is that our gut is usually right, that tiny little thing really is a big deal. We just need to step back, frame the problem not as an observation but the direction we’re headed.