Embracing complexity: is it time to rethink empathy and user needs?

I recently re-read Thomas Myddelton’s fantastic blog post Research heresies and it got me thinking. He talks about “unhelpful beliefs that get in the way of doing a great job” in user-centred design. One of the controversial opinions he calls out:

User needs is a harmful concept for training user researchers. It’s confusing. It leads to bad practice. We should be more specific about what we’re talking about.

I’m not going to re-hash what he has already brilliantly articulated himself (seriously, go and read it). I am totally on board with his argument. But I want to talk a bit more about the brief history he gives of “user needs” in government, and how that relates to the phenomenon of context collapse (more on this later).

Are user needs useful?

As Myddelton points out, user needs are foundational to government design principles, and rightly so. It is vital that we understand the needs of our users when we are designing government services. A commitment to user needs attracts many of us to working in this environment.

But he draws a distinction from the fundamental principle, to the use of “user needs” as a formulaic tool.

So how did we get here?

Myddelton talks about the history of user needs at the Government Digital Service (GDS) and calls out the work of instrumental senior researchers. He explains that these people see “user needs” as a shorthand for a lot of human complexity, including:

  • goals
  • tasks
  • contexts
  • behaviours
  • emotions
  • beliefs
  • problems
  • capabilities.

He doesn’t have an issue with user needs being used in this way. The problem occurs when we take a complex concept, divorce it from its original context, and let it loose into a much wider pool of practitioners.

There is now a risk that a rich, complex way of looking at the full human experience is reduced down to a standard formula:

We’re reducing the breadth and the complexity of the things that we’re trying to look at by stuffing them into this rigid narrow concept of user needs in the format of user stories. It makes our approach to design a bit reductive and a bit deterministic.

Myddelton has stopped talking about ‘user needs’ with researchers. Instead, he focuses on:

  • goals
  • tasks
  • behaviours
  • feelings

In other words, he has returned to the original context from which user needs were derived. He is returning nuance and complexity to the conversation.

Empathy is a myth

Design Thinking is a foundational tool for user-centred designers. It is billed as “a non-linear, iterative process that teams use to understand users, challenge assumptions, redefine problems and create innovative solutions to prototype and test.”

But people who follow conversations around design methodology (we’re fun at parties) will be aware that there has been pushback in recent years against the “empathize” stage. This stage is about gaining an insight into your users through research, and using that to cultivate empathy for your users for your team and your stakeholders.

The challenge is a fair one. It is perhaps best articulated by Jesse Weaver in their post Design has an empathy problem: White men can’t design for everyone:

As Design Thinking has spread, more and more companies take this as a justification to ignore the diversity of their teams. After all, with Design Thinking, even mostly white mostly male design teams can design for anyone on the planet simply by “empathizing” with them.

The problem is that this is bullshit. “Design empathy” is a myth. It doesn’t actually exist.

In reality, you can never truly understand another person’s lived experience. Even if they closely resemble you, it can still be a challenge, let alone if they are of a different race, gender, sexual orientation, or socioeconomic status.

What Weaver says is true. Empathy goes nowhere near far enough when it comes to designing services that work for the diverse needs of humanity. He calls out the need to diversify design teams. I would add to this the importance of co-creating with users. It is our role to enable users to be active participants in the process, not passive recipients. (Check out the Design Justice Network and equityXdesign for more on this).

Whilst I agree with Weaver’s argument, we should consider context, as we did with user needs above. The Design Thinking process started to be popularised over 30 years ago. The landscape of design and product innovation was completely different at the time. Thinking about users, even by shallow attempts at “empathising” with them, was pioneering in an environment which was driven by technology and business needs.

The problem is not with the original model. The problem is that it is still operating largely unchanged, three decades on. It has been taken from its original context, and reused by new practitioners, without consideration of how their situations are different to those faced in 1991.

Context collapse in user-centred design tools

The idea of “context collapse” comes from research into social media by linguists and sociologists. The way social media platforms proliferate ideas means entire new audiences can come across an idea without any understanding of the context from which it originated. There have been fascinating discussions around how this phenomenon can lead to cultural appropriation:

Just like other social platforms, TikTok facilitates a dynamic Gaunt refers to as “context collapse,” meaning that cultural elements are shared among one another without having a shared historical, geographic, cultural, or another frame of reference. And that’s partially how you end up with young white teenagers unknowingly inserting themselves into conversations and issues they may not fully understand.

This is a useful way to think about what is happening with concepts like user needs and empathy in the Design Thinking model. They were created for a specific purpose, within a specific context, by people who shared a cultural and methodological frame of reference.

The concept of ‘User needs’ was created as a short-hand for a whole host of information, and was never intended to be a blunt format to be re-used for every single problem ad nauseam.

Cultivating empathy can be useful when you are dealing with stakeholders who have never considered users. Enabling business- or tech-focused stakeholders to empathise with actual users can be revelatory. But we have (largely) moved on from that. We should be going a lot further to bring users into the design process.

The originators of these methods had a problem to solve, and they devised tools that helped them reach their goal. But these tools have gone mainstream. They have been picked up and shared without any reference to the original context, and as such, they have become less useful. We need to bring curiosity to each fresh project and consider which tools will serve us, and which are better left in the box.

Let’s embrace complexity and nuance

As humans, we love to simplify things. We use prescribed formulas to help us shortcut tasks and save effort. It’s human nature and it works brilliantly for some repetitive tasks like data entry. But it doesn’t work for everything.

When we’re dealing with something as messy as human needs, desires and motivations, we need nuance. We need complexity. There will never be a one-size-fits-all solution for these problems.

We can use tools and conceptual models to help us think through these knotty problems, but they should never be prescriptive. Trying to force a problem to fit an existing methodology ends up in services that are exclusionary and unfit for purpose.

If you are using a tool or method in your work, do some research on the context in which it was initially conceived. Question whether it will serve your particular context and your users. It might take longer, but it’ll be better in the long run.

Have you come across context collapse in your work? Get in touch, I’d love to chat — I’m on LinkedIn

Many thanks to Ben Webster for casting his expert Content Designer’s eyes over the first draft of this post.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store