Empathy and (Dis)content

It’s easy to write off empathy for our clients and colleagues as just a way to go soft: a way to talk about feelings instead of the work, to keep things vague, to avoid the complexities of information and interaction. I get why people hate this stuff: it’s squishy, squirmy, and vague. UX and content strategy have already spent the past decade just trying to Define The Damn Thing, thankyouverymuch.

Too bad: we need it.

Or at least, I do. Because I’ve seen what happens after. After the report. After the big strategic deck is delivered. After the launch.

I’ve presented plenty of work that was well received. I’ve seen clients gush over voice and tone guidelines, praise the audit recommendations to high heaven, get enthusiastic as hell about a strategic framework, worship at the altar of a sensible taxonomy. These are so useful. This is so clear. We know what to do now.

And then.

The CMO didn’t “get it.”
The PR team wasn’t consulted.
The business model changed.
The workflow wasn’t adopted.
The CMS couldn’t be upgraded.

And the work? It sits. In a desk drawer, on a server, on a shelf. The plan? It goes to seed, gets overruled, falls apart two months after launch. Everything stalls.

That sucks.

But that’s not my fault.

You’ll rarely get blamed when your work doesn’t stick. People are so quick to assume it’s their fault—to tell you how sorry they are they couldn’t implement your amazing recommendations.

If you’re a consultant or a contractor or an outside agency, you’ll rarely get blamed when your work doesn’t stick. People are so quick to assume it’s their fault—to tell you how sorry they are they couldn’t implement your amazing recommendations. To look at their organization’s flaws and say “we must be the most screwed-up team you’ve ever worked with.”

(Yes, that’s a real quote, and I’ve heard it—nearly verbatim—way more than once.)

As an external person, it’s not all your fault, either. Not exactly. But it’s a weakness in our work—a weakness that, if we’re being honest with ourselves here, we haven’t had a lot of impetus to get rid of. Because we keep on getting away unscathed.

Our deliverables were great, after all. Everyone said so!

This is why empathy for the people your work affects is actually important. This is why it’s worth talking about, in all its squishy, squirmy, messiness. Because it’s only when we foster—and regularly practice—a deep compassion for the challenges people inside the organizations we work with are facing—the challenges large organizations themselves are facing—that we can find out where our expertise is really needed. That we can distinguish where change is most possible, and what it will take to make it happen.

That we can help people get excited about their progress, not depressed as hell about their failures.

But I make websites!

Sure, practical skills are important. But our work isn’t really just about the interfaces we design, build, and help people use. Peter Merholz recently wrote about this when describing his experience moving from being an external consultant at Adaptive Path to an internal design leader at Groupon:

A month or so into the job, I became part of discussions to evolve our site navigation… As I dug into it, though, I felt a little like I was peeling an onion. Every layer presented new layers beneath. And I quickly left the realm of site navigation, and found myself engaging in conversations that went deep to the core of Groupon’s operations. Because, it turned out, our taxonomy influences everything we do—the deals we strive to get, the operations of our sales force, the presentation of our offers across devices and channels, heck, it even determines where some people sit.

Peter’s conclusion was that “IA needs to free itself from being seen under the umbrella of UX.” I understand the feeling: I’ve never seen content strategy as being wholly a UX discipline, either (and I am neither the first nor the only one). But I don’t buy that the problem here has anything to do with titles or disciplinary boundaries.

The real issue is what our jobs should actually be—because, as Peter states, “information architecture, when approached with the depth and rigor that is warranted, is a deeply seated operational and organizational function.” But so is content strategy, I’d say. So are pretty much all pieces of user experience and design work, too.

This wasn’t always the case, as Jonathan Kahn wrote this week in A List Apart:

Back in the day, we could get by with technical skills alone. If you could get HTML and CSS to work across browsers, you’d find work, and you might even break new ground. Technical skills still matter, but today making digital services that meet users’ needs also depends on our ability to collaborate.

This might feel fluffy as all get-out, but it’s not. Collaborating across disciplines, departments, and channels is probably the most practical skill we, as web workers, can learn right now.

When the internet was a smaller part of our world—a new place to communicate and sell products, but not the very backbone of how organizations operate—we could get away with roles that were limited to caring about what the website said and how users interacted with it. And the companies we worked for could go about their days, happily working on “the business” and leaving all that “web stuff” to us. There was the organization, and then there was the website. Distinct. Separate.

Not anymore, not with every department using the web for something. Not with cross-platform, multi-channel everything. Not with entire business models getting upended online.

But the ways we’ve historically thought about and designed our roles, business models, and sales pitches haven’t prepared us for this change. We haven’t accepted that our projects’ successes rely on us being empathetic to internal struggles. We haven’t made learning to listen for the fear in our clients’ voices a priority. We haven’t considered identifying the right “in” into change, or collaborating with people who don’t know the things we know, as core skill sets for our professions.

We’ve been too busy codifying our sets of documents, masterminding “perfect” solutions, focusing on product or site launches.

Empathy for our colleagues and clients is the first step in “peeling the onion” and getting to the core of our problems. It’s what turns our attention away from terminology and turf, and toward the much harder—but more satisfying—job of leading people through the “organizational, operational, and technological change” Peter rightly notes is needed.

It’s what ensures the strategic documents and design deliverables we create actually make a difference.

OK, but when do we get to the real work?

Ah, yes. The “real” work—we all want to get there: to the tasks, the implementation, the checklist of a project plan. Getting shit done is important, and no amount of conference-table pontificating is going to launch a mobile app or build an intranet or revamp a marketing campaign. As Ahava Liebtag wrote a few months back, “empathy is not a deliverable, and clients are focused on deliverables.”

Perhaps so. But isn’t that because it’s what we’ve trained them to expect? As consultants or agencies, though, our job has never been to be order-takers for our clients. Even in the old-school advertising days, agencies sought to take what a client said they wanted and reimagine it—help them see their message differently, and convince them to work up the nerve to take a chance.

If all we’re doing is giving clients the deliverables they ask for, regardless of whether they’ll make a difference, we’re being paid way too damn much.

If all we’re doing is giving clients the deliverables they ask for, regardless of whether they’ll make a difference, we’re being paid way too damn much. We have to be more—we have to be educators, advisors, facilitators, and guides.

But we can’t guide anyone until we go to where they are, and see the world from their perspective. This means getting real up front about what our work can do, and what it will require from them. It means asking questions about what’s hard in their jobs, where they feel stuck, who they need to convince. It means worrying less about whether a project fits our vision, and more about whether it fits their reality.

Thinking this way has actually, dramatically, changed my own practice. My projects are built with more flexibility—for my clients and for me. My strategies are always backed by something tangible—by one thing they can do, and I can help with, right now. I’ve started thinking of deliverables as tools, not repositories—a change that can be as simple as moving a style guide from a PDF to an intranet or wiki.

This effort isn’t one-sided: my clients have to come along, too, and embrace working with me, not just waiting for the results to roll in. This requires give-and-take, mutual understanding, and a commitment to collaboration. But because I’ve taken their feelings serious, because I’ve looked into their organizations and reassured them that their challenges are normal, because I’ve helped them see that successes can be small, they’re more likely to give it a shot.

That’s empathy at work.

It’s not always easy, though—not for people like me at least, people who got into this work because they like defining and refining things, who strive for clear-cut answers and solved puzzles. I suspect more than a few of you can relate. Letting go of my wish for pat answers in a tidy bundle is hard.

But clients don’t need one more reason to feel bad about their progress—which is precisely what happens when you hand over a stack of documents they can never live up to. They don’t need to apologize to us that their organization hasn’t adapted. They’re already “sick of the internet.” Blame and shame aren’t going to help morale. They’re not going to help their content get better or their navigation get less convoluted, either—which means they won’t help their users.

Sure, you’ll still get paid. You might even get a glowing LinkedIn endorsement. But I didn’t get into this business to make people feel bad for a living.

So call it squishy. Call it not-really-a-thing. But getting better at acting empathically is the only way to get close enough to your clients to figure out which deliverables and processes are worthwhile, and which are destined for another desk drawer. It’s the only way we’ll stop delivering endless recommendations that don’t have a chance of gaining traction—documents full of “shoulds” and “right ways”—and start offering real help, where our clients really need it.

Nope, it’s not a deliverable, a line item, or a process. It’s a way of being. And I’m still working on it.

3 thoughts on “Empathy and (Dis)content

  1. Sarah,

    This is a really relevant article and I agree it’s important to emphasize the collaborative aspect and using our skills/involvement to help move things along.

    I can say that this perspective tallies with my own experiences as both a UX consultant and developer. Of course empathy is really important when we engage in user testing or interviews. Right off the bat we say “we’re not testing you, we’re testing our design” just to put them at ease, and we go from there, watching carefully, feeling their pain, grasping at implications of their behaviour. I also find empathy plays a huge role in discussions with clients around planning a project. If we can’t get a sense of the business (and other) pains they are trying to resolve then we are not contributing anything.

    There are so many websites and products out there that look like they fell of the back of the ‘deliverables truck’. A collection of technical solutions to assumed problems that ultimately mean nothing to anyone. As a developer I know it can be tempting to approach solutions from the technical end, because that is the language of engineers. And clients often believe (or are told) that creating websites is primarily a technical problem. It’s not. It is, as you say, a matter of deeply empathizing with the clients objectives, hopes, aspirations, fears and all manner of real life factors.

    Thanks for pointing this out so clearly.

    Michael Keara

  2. Great thoughts, Sara.

    If I may chime in from the “other” side of the fence (though I’m now at an agency, I worked in-house exclusively for over a decade), the in-house team may feel bad and screwed up when we see consultants’ blue-sky recommendations — but sometimes we also need those recommendations.

    I think the tough thing for a consultant or agency is knowing when to innovate and create something drastically better, and when (and how) to guide a more constrained client to incrementally improve an experience. Empathy is required for this, as you rightly point out.

    Even for the client who can only improve incrementally, knowing that there is a much wider world of amazing user experiences out there provides a goal, and hope that that they can get there someday.

  3. Managing the implementation from beginning to end, providing support for the client, is essential. Small wins are important, and small solutions can be the answer to big problems. Content structure and organizational politics go hand in hand, so we must be change managers as well as content strategists. I’m a puzzle person too, and have come to terms with the unending, evolving puzzle that is never quite complete by reveling in incremental changes.

    Our commitment to successful change can make all the difference to a visionary client without the bandwidth to make it happen alone.

Leave a reply