The brief is never the real problem

Every engagement I have ever worked on started with a brief. Sometimes formal, sometimes a conversation, sometimes just a sentence: "We need to redesign this." "We need a design system." "We need someone to fix the app."

The brief is never wrong, exactly. It describes a real thing that needs to happen. But it almost never describes the actual problem.

A company asks you to redesign a screen. You look at the screen and it is fine. The problem is the workflow behind it, which sends users through seven steps when three would do. The screen is a symptom. The workflow is the problem.

A founder says they need a design system. You look at the product and realise the reason things feel inconsistent is not a missing component library. It is that three different people made three different decisions about how the product should work, and nobody reconciled them. The inconsistency is a symptom. The absent product direction is the problem.

A team says they need to move faster. You sit in their sprint meetings and notice they spend half the time debating what to build, not how to build it. Speed is not their problem. Undefined priorities are.

This pattern shows up everywhere. The stated need and the underlying cause are separated by at least one layer of misdiagnosis. Not because people are confused. Because the brief is always written from inside the situation, and from inside the situation the symptom is the most visible thing. You have to step outside it to see what is actually driving the pain.

Acting on the brief feels productive

The hard part is that acting on the brief feels productive. Redesigning the screen produces a visible result. Building the component library produces a visible result. Both are real work. But if the underlying problem stays untouched, the visible result will not hold. The redesigned screen will degrade. The component library will go unused. And in six months the same conversation starts again.

The most useful thing I do in the first week of any project is not design. It is asking questions that nobody inside the organisation is asking, because from inside, the brief seems obvious. Why does this workflow exist in its current form? Who decided this structure? What happens when a user does not follow the expected path? What changed since this feature was originally built?

These are not clever questions. They are obvious ones. But they tend not to get asked because the brief already defined the problem, and everyone moved straight to solving it.

I have learned to treat every brief as a starting point, not a destination. The real problem is usually one level below what was described. Sometimes two.

Getting to it takes days, not weeks. But those days are the difference between work that sticks and work that needs redoing.