Solving the Problem, or Finding It

There's a story that gets told in design and management classes so often that nobody seems sure where it started. The tenants of an office building keep complaining that the lifts are too slow. The owners call in engineers, who come back with expensive options: faster motors, smarter scheduling, maybe an extra shaft. Then someone, usually described as a junior employee or the building manager depending on who's telling it, suggests something cheaper. Put mirrors next to the lift doors. The mirrors go up, people start checking their hair and straightening their collars while they wait, and the complaints mostly stop. The lifts are exactly as slow as before.

I'm a little suspicious of how neat this story is, and I'd treat it as a parable rather than a case study. But it survives because it captures something real about design work. The engineers were solving the problem they were given, which was "the lifts are slow". The person with the mirrors noticed that the actual problem was "waiting feels long and boring". Those are two very different problems, and they lead to very different solutions. Designers spend their careers moving between these two ways of working: solving the problem in front of them, and questioning whether it's the right problem at all. This post is about both, where each one comes from, and why I think good design needs the two of them talking to each other.

The clearest case for this view came from Herbert Simon, an American scientist who, unusually, won both the Turing Award in computing and the Nobel Prize in economics. In his 1969 book The Sciences of the Artificial, he gave a definition of design that is still quoted everywhere: "Everyone designs who devises courses of action aimed at changing existing situations into preferred ones." By that definition, a doctor writing a treatment plan is designing, and so is a manager reorganising a team or a teacher planning a lesson. Design stops being something only people with sketchbooks do and becomes a general way of getting from where you are to where you want to be.

Simon thought about this almost like a search. You start with a problem, you work out the constraints, you generate possible solutions, and you test them against what you need. He also gave us a very honest word for how this works in real life: "satisficing", a blend of satisfy and suffice, which he had coined back in the 1950s. His point was that people almost never find the single best solution, because there are too many options and too little time. Instead, we look until we find something good enough that meets our requirements, and then we stop. If you've ever shipped a feature on a Friday because it worked well and the sprint was ending, you have satisficed, and Simon would say that's not laziness. It's how any reasonable person makes decisions with limited time and information.

There's a lot to like about this view, and most of the design industry runs on it. Briefs, requirements, success metrics, usability tests and design reviews all assume that a problem can be stated clearly enough to be solved and then checked. It's also what makes design defensible in a room full of engineers and business people. When you can say "the problem was X, we tried three approaches, and this one reduced drop-off by a measurable amount", people listen. The weakness is hiding in the first step. The whole method only works if the problem you start with is the right one, and Simon's framework doesn't say much about how to tell.

The most influential argument for the other side came from Donald Schön, a philosopher who studied how professionals actually think while they work. In his 1983 book The Reflective Practitioner, he pointed out that real problems rarely arrive neatly packaged. What arrives is a messy situation: a confused client, a half-written brief, some complaints, a deadline. Before anyone can solve anything, someone has to decide what to pay attention to and what to ignore, and how to describe the situation so that it becomes workable. Schön called this "problem setting", and he thought it was where most of a professional's real skill lies. He described design as a kind of conversation with the situation. You make a move, maybe a sketch or a rough prototype, the situation "talks back" by showing you something you hadn't expected, and that changes your understanding of what you're even trying to do.

That description matches design work much better than a tidy flowchart does. It certainly matches my experience of sketching. A rough sketch is rarely a record of an idea I already had. More often it's how I find out that the idea doesn't work, or that it works for a reason I hadn't planned. The sketch answers a question, but it usually raises a better one.

There's a lovely experiment behind this too. In the 1970s, the design researcher Bryan Lawson gave two groups of students the same puzzle: arrange a set of coloured blocks to meet certain rules, some of which weren't explained up front. One group were final-year architecture students and the other were postgraduate science students. The scientists tended to explore the blocks systematically, trying to work out the hidden rule first and then build the answer from it. The architects tended to propose arrangements straight away and learn about the rules from what worked and what didn't. Lawson described the scientists as problem-focused and the architects as solution-focused. Both groups could solve the puzzle. What surprised me most was a later part of his study, where first-year students from both subjects behaved much the same way, which suggests that designers aren't born thinking like this. They learn it, partly through years of being asked to make things before they fully understand the brief.

For a while, it was tempting to treat these as two camps, the rational problem-solvers on one side and the reflective problem-finders on the other. The research since then suggests that good designers don't pick a side. In 2001, Kees Dorst and Nigel Cross published a study in which they watched experienced industrial designers work through a real design task. What they saw was that the designers' understanding of the problem and their ideas for the solution developed at the same time, each one reshaping the other. A partial solution would reveal something new about the problem, which would then suggest a different kind of solution, and so on. Dorst and Cross called this co-evolution. The creative moment, the one people usually describe as a flash of insight, tended to happen when a clear link finally formed between a way of seeing the problem and a way of solving it.

If that sounds familiar, it's because the most popular design process diagram is built around the same idea. In 2005, the UK's Design Council introduced the Double Diamond, which splits a project into two halves. The first diamond is about the problem: you open up by researching widely, then narrow down by defining what you're actually going to tackle. The second diamond is about the solution: you open up again with many ideas, then narrow down to what you deliver. People often sum it up as designing the right thing first, and then designing the thing right.

The diagram is useful, but I'd be careful with how literally it gets taught. In real projects, the two diamonds rarely happen in a clean sequence. You often discover that your problem definition was wrong halfway through building a solution, and the honest thing to do is to go back. The diagram makes it look like a journey with a clear handover in the middle. In reality it behaves more like the conversation Schön described, where you keep moving back and forth until the problem and the solution make sense together.

One of my favourite examples of problem-finding comes from Jaipur in the late 1960s. Prosthetic feet designed in the West were built around Western lives: shoes, chairs, flat floors and cities. For many amputees in India, that was the wrong brief entirely. People needed to squat, sit cross-legged on the floor, walk barefoot through fields, and wade through water and mud, often while working long days outdoors, and they needed something they could afford. A craftsman named Ram Chandra Sharma, working with the orthopaedic surgeon Dr P. K. Sethi, developed what became known as the Jaipur Foot, made largely from rubber and wood. It was flexible enough to let people squat and sit on the floor, sturdy enough for rough ground, and cheap enough to be fitted widely, and it is still given free of charge to many people today. The engineering was impressive, but the real breakthrough came first. Someone looked at how people actually lived and redefined the problem from "make a replacement foot" to "let this person squat, sit and work the way they did before".

I had a much smaller version of this moment at Rocketium, where I worked on designing an agentic AI system for creative teams who produce ads at huge scale. On paper, the problem looked like it was about AI. The company already had an AI co-pilot, nobody used it, and the obvious brief was to make a better one. Instead, I spent several days sitting with the in-house design team and watching how they actually worked. The moment that changed things was small. To add content variations, designers were exporting data out of the product into a Google Sheet, editing it there, and importing it back in. Watching that round trip made it clear that the real problem wasn't the assistant. It was that designers were spending most of their day carrying out repetitive steps that needed no creative judgement at all. Once the problem was framed that way, the solution had a much clearer job: take on the execution, and leave every real decision with the designer. If I'd taken the original brief at face value, I would have designed a nicer chat window for a problem nobody had.

Problem-finding has become fashionable, and it comes with its own set of inspirational quotes. You've probably seen the one where Einstein supposedly said that if he had an hour to solve a problem, he would spend fifty-five minutes thinking about the problem and five minutes on the solution. It's a good line, but researchers who have tried to trace it, including the website Quote Investigator, haven't found any evidence that Einstein said it. The same goes for Henry Ford's famous claim that if he had asked people what they wanted, they would have said faster horses. There's no record of him saying it either. I mention this partly because it's funny that a profession so focused on questioning assumptions repeats these quotes without checking them, and partly because they push an exaggerated idea, that the clever designer is the one who always rejects the brief.

That's the trap on the problem-finding side. It's possible to spend so long questioning and researching that nothing ever gets made, or to treat every brief as naïve just to look thoughtful. Teams have deadlines, budgets and real users waiting, and sometimes the problem you've been given is actually the right one. When a checkout button is too small to tap on a phone, the job is to make it bigger, not to run three weeks of discovery about the meaning of shopping. Simon's satisficing is a healthy reminder here. At some point, a good-enough understanding of the problem is enough to start, and building something will teach you more than another round of interviews.

The trap on the problem-solving side is the opposite, and I think it's more common. Most of us, given a brief, start picturing solutions almost immediately. It feels productive, and it's exactly what Lawson's architecture students did. The danger is falling in love with the first idea before checking whether it answers the real need. The useful habit is somewhere in between: let yourself sketch early, as long as you treat every sketch as a question about the problem as well as an answer to it.

If I had to put it simply, I'd say problem-solving is what designers are hired for, and problem-finding is what makes them worth hiring. Companies bring in designers because they have something that needs fixing, and solving it well, on time and within real constraints, is the job. But the designers who make the biggest difference are usually the ones who pause long enough to check whether they're fixing the right thing, and who have the confidence to say so when they're not.

The practical habit I'd take from all this is small. When a brief arrives, rewrite it in your own words before you open any design tool, and then ask what would have to be true for that brief to be the right one. Who said this was the problem? What did they see that made them say it? Is there someone affected who wasn't asked? Sometimes the answers confirm the brief, and you can get straight to work with more confidence. Sometimes they reveal a mirror-next-to-the-lift kind of problem hiding underneath, and that's when the most interesting work begins.

The lift story is probably too neat to be entirely true, but I keep coming back to it because of who got it right. It wasn't the person with the most technical knowledge. It was the person who looked at people standing in a lobby and asked what they were actually experiencing. That move, from the problem as stated to the problem as lived, is available to anyone, and in my experience it's the most valuable thing a designer can learn to do.

Further reading: Herbert Simon, The Sciences of the Artificial (1969) · Donald Schön, The Reflective Practitioner (1983) · Bryan Lawson, How Designers Think (1980) · Kees Dorst and Nigel Cross, "Creativity in the design process: co-evolution of problem–solution" (2001) · Kees Dorst, Frame Innovation (2015)