A few ideas I keep coming back to.

There's a version of empathy that's emotional — you put yourself in someone's position and feel what they might feel. That has real value: it's the foundation of personal connection and deep user trust. But in design work, especially inside large organisations, what's more useful day-to-day is a different kind: the ability to map how another person understands the situation, what they're optimising for, what they're afraid of, and what they need to be true in order to move forward.

I think of this as positional empathy. It isn't a replacement for compassion — it's a complementary instrument, optimised for a different context. And it turns out to be one of the most practically useful skills in enterprise design work, because most of the hard problems in these environments aren't visual or technical. They're political and cognitive. People aren't aligned. People don't share the same mental model of the problem. People have incentives that aren't visible in the brief.

If you can map that landscape accurately — without losing your own perspective — you can find the path through it. Not by winning the argument, but by understanding the terrain well enough to stop arguing about the wrong things.

Positional empathy is not a substitute for compassion — it is a complementary tool for professional complexity. You do not feel your way to stakeholder alignment; you think your way there.

The standard design process asks: what do users need? That's a good question. But the behavioral economics question is different: given how human cognition actually works — with its shortcuts, biases, and context-dependence — what does this interface make people likely to do?

Those are not the same question.

I spent years working on conversion rate optimisation across banking, insurance, loyalty, and e-commerce platforms. What that work teaches you — if you're paying attention — is that small design decisions have disproportionate effects on behavior. The order of information on a page. The framing of a choice as gain or loss. The presence or absence of a default. These aren't details. They are the mechanism by which the design does or doesn't work.

This doesn't mean manipulating people. It means understanding how decisions are actually made — under time pressure, with incomplete information, shaped by context — and designing for that reality rather than an idealised version of it.

What users need and what users do are not the same question. The behavioral approach works by modifying choice architecture through psychological levers — not by gathering more stated preferences.

When I joined the IKEA Home Services team, there was no shared working system. Files existed everywhere. The hierarchy of work — what belonged in Figma, what in Confluence, what in Jira — was unclear and inconsistently applied. The process that existed depended on specific individuals to hold it in memory and transmit it informally. When those individuals weren't available, the system collapsed.

My approach was to start with principles rather than tools. I mapped the actual work the team was doing: the types of tasks, their interdependencies, the decisions that kept getting lost. From that, I derived a set of structural rules — what goes where, when, and why — that could be documented, taught, and modified without requiring me to be present.

It was adopted imperfectly. The structural bones held. I've come to think that imperfect adoption of a well-structured system is actually the success condition — not perfect compliance. The goal was a process that could survive my departure, survive new team members, and survive the moments when no one has time to maintain it carefully. It does.

Imperfect adoption of a well-structured system is the success condition — not perfect compliance. The goal is survival, not control.

What I've been exploring over the past year is what happens when you introduce AI into a design process that was already complex — specifically, the Shape Up methodology my team uses at IKEA. Shape Up asks people to hold a lot of context, make judgment calls on incomplete information, and move quickly through shaping decisions that have long downstream consequences.

AI can process and produce information faster than any team can absorb it. Which means the bottleneck shifts. It's no longer about generating options — it's about making sense of them. About having enough shared context to evaluate what the AI has produced and decide what to do with it.

The interesting design problem here is human, not technical. How do you structure an AI-assisted process so the output is actually useful — not just voluminous? How do you build in the right checkpoints, the right level of human judgment at the right moments? How do you prevent a room full of people from drowning in AI-generated text and losing the thread of the actual decision?

Those are facilitation problems. And facilitation, it turns out, is a design problem.

AI does not remove the need for judgment. It moves it. The bottleneck shifts from generation to sense-making — and structuring that process is a design problem.

Read the full framework →