The first brief I ever ignored was the best design decision I made that year. Not ignored carelessly. Ignored deliberately, after reading it three times and realising that what it described and what it was actually asking for were two different things.
The brief said: improve the reporting flow. What it meant was: users don’t trust the numbers they’re seeing, and they don’t know what to do with them. Those are not the same problem. One is a UI problem. The other is a product problem. And designing a better UI for a product problem produces a polished surface over a broken foundation.
That gap — between the stated problem and the real one — is where most design work goes wrong. Not because designers are incapable of solving the real problem. Because they never stop to ask whether the brief has correctly identified it.
A brief is a translation. Someone in the business — a PM, a stakeholder, a leadership team — has observed something: a metric dropping, a user complaint, a competitive gap, an internal frustration. They’ve interpreted that observation through their own frame of reference, applied whatever constraints feel relevant, and produced a document that describes what they think the solution looks like.
That chain — observation, interpretation, constraint, solution — introduces error at every step. The metric might be a symptom rather than the cause. The interpretation might reflect the stakeholder’s mental model rather than the user’s. The constraints might be assumed rather than real. And the described solution might be an answer to the interpreted problem rather than the observed one.
By the time the brief reaches a designer, it has already made several decisions that nobody has examined. The designer who accepts those decisions uncritically isn’t solving the problem. They’re executing someone else’s half-formed hypothesis.
This isn’t a criticism of the people who write briefs. It’s a structural observation about how briefs are produced. Translation loses information. The further the brief travels from the original observation, the more of that information gets lost. A designer who goes back to the observation — to the actual user behaviour, the real metric, the specific moment where things break down — is doing the work the brief was supposed to do but couldn’t, because briefs are written by people who aren’t designers.
Working upstream of the brief isn’t about ignoring the business context or redesigning the product on your own terms. It’s about asking one question before any other: is this the right problem to solve?
That question sounds obvious. In practice, it requires specific skills that design education rarely teaches explicitly.
The first is reading the gap between what a brief describes and what the evidence shows. A brief that says “users find the interface confusing” is not the same as evidence that users find the interface confusing. One is an assertion. The other is a signal. Assertions need to be tested. Signals need to be interpreted. A designer who treats an assertion as evidence has already lost the thread.
The second skill is distinguishing between the problem the business has and the problem the user has. These frequently overlap, but they are not identical, and the design solution that addresses one may actively worsen the other. A checkout flow that reduces cart abandonment at the cost of user trust is solving the business problem while creating a user problem that will show up as a different metric six months later. The brief usually describes the business problem. The user problem requires its own investigation.
The third skill is knowing when the brief is right. Working upstream doesn’t mean every brief is wrong. Some briefs are excellent — precise, evidence-based, correctly scoped. Treating every brief with suspicion is its own failure mode. The discipline is not scepticism for its own sake. It’s the habit of verification before execution.
There’s a specific moment in most projects where the real problem becomes visible. It usually happens during research — in a user session, in a support ticket analysis, in a stakeholder conversation where someone says something that doesn’t fit the brief’s framing and everyone moves past it too quickly.
That moment is the most valuable thing research produces. Not the confirmation of what the brief already assumed. The anomaly that the brief didn’t account for.
In the project I mentioned at the start, the moment came in the third user session. A user looked at the reporting dashboard, read the numbers correctly, understood what they meant — and then didn’t act. Not because they couldn’t. Because they didn’t believe the numbers warranted action yet. They were waiting for a signal that the product wasn’t designed to give them.
The brief had asked for a better reporting flow. What the user needed was a decision surface — a layer that converted performance data into actionable guidance. Those are structurally different problems with structurally different solutions. The brief would have produced a faster path to the wrong answer.
Junior designers solve the problem they’re given. Mid-level designers solve the problem well. Senior designers ask whether it’s the right problem before they solve anything.
That progression isn’t just about skill. It’s about accountability. A junior designer who executes a bad brief has done their job. A senior designer who executes a bad brief without questioning it has failed at theirs — because part of the job, at that level, is to catch the brief’s errors before they become the product’s errors.
This is uncomfortable to say clearly, because it implies a kind of authority that design doesn’t always formally hold. You don’t always have the standing to reject a brief. You don’t always have the time to go back to first principles. You won’t always win the argument.
But the habit — the instinct to pause before executing, to ask what the brief assumed and whether those assumptions have been tested — is what separates designers who make products better from designers who make products more polished. Polish is visible. Better is compounding.
Before the first wireframe. Before the first sketch. Before the first conversation about components or flows or layouts.
Is this the right problem?
Not: is this an interesting problem. Not: is this a solvable problem. Is this the right one — for this user, at this moment, in this product?
If you can’t answer that question confidently, the brief hasn’t done its job yet. And that’s your job now.
The brief is the starting point. The problem is what you find when you look behind it.
References