Empathy for colleagues: why UX Design is a leadership skill | by Pavel Samsonov

This is part of an article series (starting here) exploring how every participant in the software design process can apply design decision-making methods to the way we organize teams, plan work, and build products, rather than just to the products themselves. I hope to make these tools useful and relevant to readers — if what I am describing doesn’t fit your experience, don’t hesitate to drop me a line.

I started my tech career in UX design. At the time, design was already experiencing something of a personality crisis, and the solution most practitioners aligned on was to fence off the things Design owns: we are responsible for the desirability leg of the stool; we are the champions of the user’s needs.

And implicit to those sentiments: nobody else represents those interests, except for us. Nothing matters but user outcomes, and since we own user outcomes, nothing matters except our work.

Designers are storytellers — and the story we were telling about ourselves was “if only the other roles would understand our contributions, we would be able to do some amazing things.”

And I might have gone on believing that, if I hadn’t found myself in a product management role later in my career, and learned that PMs see themselves the exact same way — as the misunderstood people who are trying to deliver value to their customers, beset on all sides by stakeholders who want something else.

And of course, product management exposed me to the Agile Manifesto and one of its four key principles: “satisfy the customer through…valuable software.”

All three legs of our stool share the same desire: delivering value to users. So how come each thinks that the others are getting in their way?

And if UX design is truly the discipline responsible for empathy — what should we be doing about it?

It’s not controversial to say that we are in a job satisfaction crisis, and have been in one for quite some time. People in every industry are fed up with doing pointless work delivering outputs that don’t matter. Even in companies that ostensibly create a useful product, employees across all levels of seniority don’t know how their contribution fits into the big picture and believe they spend most of their time on low-value tasks.

The layoff environment adds another impetus for every role — not just design — to prove their ROI. Every function is afraid that if they don’t demonstrate their value, they will be the next ones out the door.

And so we set the stage: everyone wants to do the same thing, but everyone wants to own doing that thing. Whether or not we have empathy for the user is not a convincing argument to upend this dynamic. In a head to head battle, UX — unarguably the role with the least political capital — always loses.

But in this particular battle, designers have other weapons. And the weapon I want to talk about is the design ladder.

Briefly: the Danish design ladder is a design maturity framework for technology orgs, starting with “no design” at the bottom and ending up with “design as culture” at the top. The nuances of each level are not terribly important, except for one point: as we approach the peak of the ladder, we stop thinking about design as exclusively outward-facing, and start leveraging its principles and mechanisms internally as well.

Even designers might recoil at this notion — isn’t the customer our undiluted north star? — but it makes sense when you think about it. While our ultimate responsibility is to those external customers that actually use our products to achieve their goals, they are not the ones who consume the majority of our work. They are not the users of those outputs, because the outputs are not “usable” in the software sense. Rather, we produce outputs for our colleagues (product managers, developers, testers, marketers, etc) to consume.

By volume, these artifacts — from low-fidelity storyboards and wireframes to pixel-perfect Figma mockups and design system docs — overwhelmingly outweigh the proportion of our work that directly reaches the end-user (or they ought to — some truly awful production code I’ve written is still floating out there somewhere).

Our most immediate customers aren’t the users. They’re our counterparts in Product and Engineering.

This comes as no surprise to anyone enmeshed in B2B or B2E product, where the “producer” and “consumer” roles are complicated by the addition of many others, both on the producer (marketing/sales, account management, support) and the consumer (chooser, buyer, governor, user, user’s customer) sides. Any tool designed solely for the end-user without meeting the other considerations will inevitably fail to endure the friction of everyday business processes, which are orders of magnitude more complex than those for e-commerce or other common consumer-grade applications.

Understanding how those roles work together to deliver value to the ultimate user (the customer of the company paying for your product) requires a more sophisticated understanding of roles within the value-creation process. The design ladder asks us to model just one or two more steps: how that value travels from the user through design to product and ultimately delivery.

If we as designers want to be effective in our roles, we need to intentionally design that interlock just as much as we design every other part of the product, and give up the naive belief that good UX can be simply a function of our will to Do The Right Thing. And if we see that our teams are fracturing from the lack of clearly-defined customer outcomes, it’s our responsibility to identify them.

The most difficult part of turning our design methods inwards is simply realizing that it’s possible. Once we realize it’s something we can do, it’s easy to find immediate applications: just like our external users, our stakeholders have goals and existing ways of meeting them. And just like our users, our stakeholders have pain points caused by external conditions that we might address.

But unlike our users, we don’t need to invent fake stakeholders to join us in the room. We have the real deal — wandering the halls, getting slightly burnt coffee at the pantry, and taking up our conference rooms past their booked time slots. The only barrier to understanding is the willingness to try.

Shockingly, this barrier can be insurmountable. Many designers (and developers and product managers & etc & etc) believe that everyone they work with is simply after a different outcome, and rule out finding common ground.

And this is the exact decision that makes smooth teamwork impossible.

What separates a team from a workgroup is a shared set of goals and methods. If the team is still forming, then the job of a designer (assuming one thinks beyond their product) is to enable that formation, rather than sabotage it by assuming that we couldn’t possibly share our team’s goals because only we are correctly equipped to develop user empathy.

For decades, design’s struggle has been shaped by the fight for the seat at the table. Many designers point to engineering as a success story: a practice that was once considered secondary to “the business” but emerged on the back of Agile Transformation to become an equal stakeholder through the 2000s and 2010s.

But anyone familiar with “legacy tech” orgs that went through that transformation sees a very different story. Today’s “best practices” for software development evolved from ultra low trust environments, and the need for resilience in the face of the goalie problem that Engineering, as the most downstream function, faced as deadlines drew nearer and nearer. The developer experience was shaped by sacrificing quality for speed, only to be burned by the business pushing aggressive deadlines that cut refactoring efforts short.

Effectively, while Engineering won that seat at the table, it did so under adversarial conditions. Designers, who pride themselves on empathy, can do better — by building a new way of working together rooted in trust and shared goals. Though our top-down approach has stalled, the bottom-up approach of building a new table where we invite our peers to sit is only beginning to be explored.

Design doesn’t create value alone; only in partnership with business and delivery functions. Defining our roles in opposition to our partners is futile.

Rather than assuming the worst about your colleagues and stakeholders, give them the same benefit of the doubt that you would extend to your users. Do they do what they do out of malice — or are they driven by incentives you’re not aware of? Maybe it’s possible to align business outcomes and company conceptual models to end-user goals after all — or at least worth using our toolbox to try and find a way.