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've started calling this positional empathy. It sits alongside compassion rather than standing in for it, and it's turned out to be one of the more useful skills I've picked up in enterprise work. Most of the genuinely hard problems in these environments have nothing to do with visuals or technical execution. People show up misaligned, working from different mental models of the same problem, carrying incentives the brief never mentions.

Map that out accurately, without losing your own read on it, and you can usually work through it. It's rarely about winning an argument. It's about understanding the situation well enough that people stop arguing about the wrong things.

Stakeholder alignment isn't something you feel your way into. You map it, the same way you'd map any other system.

The standard design process asks what users need. That's a fine question, but it's not the one I spend most of my time on. The behavioral economics question asks something narrower and, I'd argue, more useful: given how people's cognition actually works, with its shortcuts and biases and context-dependence, what is this specific interface going to make them do?

Years of conversion rate optimisation across banking, insurance, loyalty, and e-commerce taught me that the answer to that question usually comes down to details nobody thinks to argue about: the order information appears on a page, whether a choice is framed as a gain or a loss, whether there's a default option at all. Get those wrong and no amount of good intentions in the brief saves the design.

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.

Adoption was messy, honestly, but the underlying structure held up regardless. That's actually what I was aiming for: not everyone following the process to the letter, but a process solid enough to keep working when they didn't. It's already survived my leaving, a round of new hires, and the stretches where nobody had time to babysit it. That's the real test, and it passed.

A good system doesn't need everyone following it perfectly. It just needs to still work when they don't.

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 hard part turned out to be human, not technical: getting an AI-assisted process to produce output that's actually useful instead of just plentiful, building in checkpoints at the moments that actually need human judgment, and keeping a room full of people from getting buried in AI-generated text and losing track of the decision they were actually there to make.

All of that is facilitation work. Which, it turns out, is design work too.

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 →