You Solved the Wrong Problem

TL;DR:
The brief already contains a frame, and the frame decides what you can see. Accept it without question and you build a flawless solution to the wrong thing. The [Segway](https://en.wikipedia.org/wiki/Segway) worked exactly as designed. Cities declined to cooperate.

The brief lands on your desk. Someone has already named the problem. You read it, nod, open your tool, and start designing. That moment, right there, is where most projects go wrong. Not in the wireframes. Not in the copy. In the unexamined three seconds where you accepted someone else’s problem definition without looking at it twice.

Designers are trained to solve. School, portfolios, job interviews, all of it rewards finding elegant answers. The question of whether the answer fits the actual problem gets very little airtime. So you get good at solving. And without noticing, you stop asking what you’re solving for.

The frame decides what you can see

In 1983, Donald Schön wrote something that should have changed how design education works but mostly didn’t. He made a distinction between problem solving and what he called problem setting. Problem solving, he argued, is the part everyone practices. Problem setting is the act of deciding which things to treat as problematic in the first place: naming the situation, framing it, deciding what counts as a relevant fact.

The frame is not neutral. It is a lens that makes some things visible and pushes others out of sight. Frame the problem as “users can’t find the checkout button” and you look at the button. Frame it as “users don’t trust this store enough to complete a purchase” and you look at a completely different set of things. Same user behavior. Two completely different design directions. The frame determines the solution before a single line gets drawn.

Kees Dorst, who spent years studying how expert designers actually think, found that what separates strong designers from weak ones is not execution. It’s framing. Experienced designers don’t rush toward solutions. They sit with the problem longer. They resist the first frame they’re handed. They try alternative framings until they find one that opens up the right kind of thinking. That patience isn’t timidity. It’s the actual work.

Problems that resist being solved

Horst Rittel and Melvin Webber named a category of problem in 1973 that most designers are dealing with every day without a word for it. They called them wicked problems. Not evil, but resistant. Unlike tame problems, which have clear endpoints and correct solutions, wicked problems shift when you touch them. Solving one aspect changes the conditions of all the others.

“Social problems are never solved. At best they are only re-solved, over and over again.”

Rittel & Webber

Most design problems are wicked. You design the onboarding flow to reduce drop-off. But reducing drop-off means more users reach the core product, which strains support. Solving churn reveals a retention problem you hadn’t seen. The system moves when you push it. Rittel and Webber’s point was not that wicked problems are hopeless. It’s that they punish anyone who treats them as if they have a single correct answer buried somewhere, waiting to be found. Narrow framing makes wicked problems worse because you solve a visible part and the invisible part bites you later.

The reason this matters for designers is that narrow framing is the default. You get a brief, you accept the frame in the brief, and you move. The brief says “simplify the settings page” and you simplify the settings page. But maybe the real problem is that users are reaching settings because they can’t find what they need in the main flow. The settings page was a symptom, not the disease. You just made the symptom more comfortable.

Elegant engineering, wrong city

Dean Kamen’s team built the Segway with extraordinary technical care. The self-balancing system was a genuine feat of engineering. They had a clear problem statement: urban personal mobility is inefficient, and we can build something better than walking for short distances between buildings.

They solved that problem. The Segway worked exactly as designed. It moved people, balanced itself, required almost no training. Kamen predicted cities would be redesigned around it. John Doerr said it might be bigger than the internet.

Only 140,000 units sold across the entire lifetime of the product. Production ended in 2020.

The team framed the problem as a device problem. Build a better way to move between buildings. But the actual problem was a systems problem, and the system was not cooperating. Cities had sidewalks not designed for vehicles. Regulations prohibited Segways from bike lanes and roads in most places. The $5,000 price tag put it beyond the reach of anyone who might have used it for practical commuting. People did not want to arrive at meetings looking like they’d come off a mall security shift.

None of that appeared in the original problem frame. The frame asked: can we build a better short-distance vehicle? It didn’t ask: will cities, regulators, employers, and social norms accommodate it? That question would have pointed toward a different problem, one with no clean engineering solution. So it stayed outside the frame.

The two-sentence test

Before the next brief sends you straight to Figma, try this: write two sentences. The first says what problem you are solving. The second says what problem you are not solving.

That second sentence is the work. It forces you to make the frame explicit, which means you can see it. A frame you can see is a frame you can question. Most teams never make it explicit, which means the frame operates invisibly, ruling out whole categories of solution before anyone in the room knows it.

If you can’t write both sentences, you don’t have a frame yet. You have an assumption. Assumptions don’t become visible until they’re wrong, which is usually after you’ve shipped.

Show both sentences to whoever gave you the brief. Not as a challenge. Just: “Here’s what I think we’re solving, and here’s what I think is out of scope. Does that match what you have in mind?” Half the time it doesn’t. And the ten minutes that conversation takes is the cheapest problem-solving you will ever do.

A beautiful solution to the wrong problem is still the wrong problem. The craft doesn’t change that.