Empathy: Not Just for Users

I was reminded by a few different but curiously similar events over the past few weeks of a simple but striking fact:

The vast majority of people do not understand design.

At least not in the way designers do, and at the very least not as well as designers tend to assume they do. I don’t think this is a bad thing. I don’t even think it’s a very surprising thing, given the vast number of far simpler concepts people don't understand for a myriad of different reasons. It is, however, a fact of life we as designers tend lose sight of, thanks kindly to the bias bugs in our brains.

We like to believe that designers are somehow more empathetic and aware of how others think than your average person, but I haven’t found that to be very true.

Designers are, on the whole, quite average human beings on the dimensions of psychology, habits, abilities, and innate talents. We just happen to have a set of learned tools that let us remove ourselves from our own perspectives for a bit and implement empathy for short bursts to make our work more successful. On the whole, we’re good at doing that, but even in our design work we forget all the time. It takes structured methods to jolt ourselves out of our biases—and we have to make a conscious effort to apply them. It’s not easy.

We often fail to give that same methodical empathetic approach a shot with our peers and colleagues, and it shows. We assume too much about what people know and care about, and expect them to make giant leaps in trust and investment without a clear path. We expect people to “just get it." Things turn black and white, frustrations rise, nothing gets solved, and we resign ourselves to complacency and push forward “advocating for design” in limited ways often without much success, all compounded by the friction of working without that shared-understanding grease. It can get difficult.

One time, I was in a cross-functional get-together with all the different roles working with the same product. It was a group of about 30 people: PMs, designers, engineers, the team supporting it, the sales team selling it, the marketing team messaging it. I had the opportunity to talk about what other teams should know about our work, and to kick things off I asked, “how many of you are familiar with the design process?” Two people raised their hand—I think it was the PM and the marketer. In a room of around 30 people—some of whom had been in the industry for decades—almost no one knew what designers really did.

Empathy doesn’t come out of thin air. Neither does trust. They come from understanding and familiarity—seeing inside someone’s head, understanding how they think, what they consider important, why they do what they do, the challenges they face and the success they seek. Deep understanding helps us all build a clearer picture of who someone is and why they behave the way they do. We know this from the practice of user research—we use it skillfully and know the joy it can bring when we reach those moments of clarity.

How can we expect other teams, functions, and levels in our own companies to trust us and our work—or be empathetic toward us as coworkers—without understanding who they are, what they do, and why they feel it's important?

What if we were to aim our design process internally and practice what we know how to do best?

How would we start? I’d start with understanding the problem and the people: the first phase of every good design process. It's something I constantly repeat to our teams: never lead with the solution—but if design is the solution, what are we doing exactly by advocating directly?

Designers and design itself are in a particular formed shape, already in high fidelity; we are the solution that’s ready to go into production, and sometimes we can get in the mindset that people just need to be convinced that the ready-packed design we're selling is the answer and they should buy it. They should just get it.

If you came to me with that argument in a critique, I’d make you go back to step one. “Don’t show me a solution when you haven’t understood the problem yet.”

I mean, imagine it—I’m not going to go a level down and apply the whole design process to design right now—but oh, the questions you could ask! I'm sure you'd build a clearer picture of what design really is in your company, for your product, and for the people around you—beyond what’s in your head.

We’re surrounded by our context at work. It’s one of the most biased and engrossing situations we could possibly be in. We give ourselves to it for 8 hours a day, and sometimes we can get sucked into the same kind of deep awareness wells we work so hard to get out of in the practice of design itself.

If you think it’s hard understanding customers, try understanding your own sales team. No, seriously, try it.

Design advocacy starts with understanding the people around you, and helping them understand you. The good news is that we have a ton of great tools to do that in our repertoire. Build the relationships, do that user research, sketch those journey diagrams, make those simple and gorgeous high-fidelity posters that help people understand things at a glance as they walk down the hallway.

Maybe most importantly, we'll build our own understanding of why we're here and what's so important. It's a virtuous cycle—understanding how we can help others helps us understand our own work better, and build a better story we can then share with others.

I know that design really does fill a giant hole that all products and businesses tend to have—a very important one. I know this through a lot of observation and communication. It took me fifteen years of product and design work to just begin to get a clear picture, and I'm by no means close to done. People in other roles don't have near the same context. You are not your user.

I truly believe that most people have good intentions. They're doing their best with what they have. By no fault of theirs, they just haven’t discovered, learned to use, or understood the sometimes opaque and complex interface that design presents to them. Those sound like problems we're well equipped to handle, so let’s not blame our internal users—as tempting as it may be to default to that. Let’s understand them and help them.

Tristan Harward

Tristan Harward