Designing Fast and Slow

Designers tend to prefer System 2.

We want to slow things down, look at the problem from several angles, do some research and test a few models before committing. We often wait until we feel 90 per cent sure before pulling the trigger. Partly because we know that, despite all the talk of agile development and continuous iteration, many decisions are effectively permanent. The team moves on, the backlog fills up, and the promised second pass never comes.

Our business and product partners often work differently. They are dealing with growing backlogs, limited attention and a steady stream of opportunities. Decisions are made through pattern recognition and instinct: this sounds plausible, a competitor is already doing it, the downside seems limited, and there are another dozen bets waiting behind it.

The result is a kind of fire-and-forget product development. Ship the idea, see what happens, move on.

Designers usually respond by trying to pull everyone into System 2. We ask for more evidence, more time, more clarity and a better understanding of the problem before committing resources.

Sometimes this works. It is more likely to work in larger, successful companies, where the cost of a mistake has risen and institutional caution has started to set in. But in many organisations, those objections fall on deaf ears. Worse, design starts to be seen as an organisational handbrake: the team that always needs another workshop, another round of research and another week to think.

That perception is not entirely fair. But it is not entirely invented either.

I often describe the difference as a chess-versus-poker mindset.

Designers tend to treat product decisions like moves in a game of chess. Each move changes the board, closes down future options and may be difficult to undo. One sufficiently bad decision can compromise the whole game. It therefore makes sense to study the position carefully before moving.

Many business leaders think more like poker players. They expect to lose plenty of hands. The aim is not to avoid every bad outcome, but to place enough sensible bets that the winners more than cover the losses. From that perspective, spending too long protecting against failure may be more dangerous than failure itself.

Neither position is inherently irrational. The disagreement is really about how mistakes are priced.

Designers assume that a poor decision will become embedded in the product. It will create inconsistency, technical debt, support costs and awkward constraints that the team will be living with for years. Business leaders are more likely to see the same decision as a relatively cheap experiment. If it fails, they will stop investing in it and move on.

The problem is that many organisations talk as though they are playing poker while building products as though they are playing chess. They describe decisions as experiments, but rarely remove the failed ones. They promise to iterate, but almost never return. Each supposedly temporary bet leaves another permanent mark on the board.

Under those conditions, design’s caution starts to look less like perfectionism and more like experience.

But designers also need to recognise when they really are looking at a cheap, reversible bet. Not every decision deserves a month of research. Not every imperfect release creates lasting damage. Sometimes the cost of waiting is greater than the cost of being wrong.

The useful question is not whether the organisation should think fast or slow. It is whether this particular decision is genuinely reversible, what failure would actually cost, and whether anyone will come back to fix it if the bet does not pay off.