Thinking
Field note · 5 min read
The Product Is the Brief
A digital product is a record of what a team actually decided.
I’ve spent over two decades designing and building digital products, across agencies, enterprise environments, and now independently.
The best systems explain themselves through use.
A brief describes the assignment before it meets pressure. The product shows what survived. It shows what the team understood, what it avoided, what it protected, what it cut, and what it quietly handed to the user.
Argument
The product keeps the receipts
What the product reveals
The written brief is only the first version of the truth.
It gives the work a beginning. It names the audience, the goal, the business case, the desired behavior, and the clean version of the problem everyone can agree on in a room.
That does not make it false. It makes it incomplete.
A brief is written before the work has to choose. Before the edge cases arrive. Before engineering constraints harden. Before stakeholders defend their favorite feature. Before the first-time user lands on the page with no context, no patience, and no obligation to care.
The product is where those choices become visible.
The homepage shows what the team believed had to be said first. The navigation shows what nobody wanted to remove. The onboarding shows whether the team understood the user’s first minute, or only its own internal process. The empty states show whether failure was designed for, or merely discovered later. The settings page often tells the truth no kickoff deck would admit.
A toggle buried three levels deep is rarely just a toggle. It can be a compromise. A naming argument. A legacy system nobody wanted to touch. A decision deferred so long it became part of the interface.
That is why a finished product often reveals more than the brief that started it.
The brief says what the team intended. The product shows what the team was able to decide.
A brief is a useful fiction. It gives the project a beginning. It names the audience, the goal, the desired outcome, and the version of the problem everyone is willing to agree on.
But the brief is not the work. It is the stated intention before the work meets constraints.
Once a product becomes real, the hidden assignment starts to appear. The hierarchy shows what mattered most. The navigation shows what nobody wanted to cut. The empty states show whether anyone thought about failure. The onboarding shows how clearly the team understood the user’s first minute. The settings, edge cases, and recovery paths show whether the system was designed as a surface or as a working environment.
This is why a finished product can reveal more than the kickoff deck. The deck says what the team wanted to build. The product shows what they were actually able to decide.
Friction
Confusion has a source
When the assignment is unclear, the interface starts carrying the contradiction.
Confusion usually enters before the visual layer. It does not begin as bad spacing, weak typography, or an awkward component. Those things may expose it, but they are rarely the root.
The root is usually an unresolved priority.
A homepage tries to sell three different things because the primary audience was never chosen. A dashboard gives revenue, churn, support volume, and casual engagement the same visual weight, then leaves everyone wondering what matters. A workflow asks for information too early because the database was allowed to lead the experience. A product promises simplicity, then exposes every internal distinction the organization failed to resolve.
The user does not know any of this.
They only feel the hesitation.
They pause. They reread. They scroll back. They guess. They abandon the task. Later, the team calls it a conversion issue, a copy issue, a layout issue, or a usability issue.
Sometimes it is.
Often, the interface is reporting something deeper: the product does not yet know what it is asking the user to believe, understand, or do.
That is why polish can make a confused product worse. A cleaner UI can hide the problem from the team while preserving it for the user. The system looks resolved from a distance, but the burden has not moved. It has only been made prettier.
A beautiful surface can still be asking the user to finish the brief.
Confusion does not usually enter a product as bad typography or ugly spacing. It enters earlier, as unresolved priority.
A page tries to explain three different offers. A dashboard treats every metric as equally important. A workflow asks the user to make a decision before the system has earned enough context. A product promises simplicity, then exposes internal complexity because no one decided where that complexity should live.
These are not only interface problems. They are structural problems becoming visible.
The user feels them as hesitation. They pause, reread, backtrack, ignore, guess, or leave. Internally, the team may describe the issue as a copy problem, a layout problem, or a conversion problem. Sometimes it is. But often the interface is only reporting the deeper condition: the product does not yet know what it is asking the user to believe, understand, or do.
That is why polish can make a confused product worse. A beautiful surface can hide the wound from the team while the user still feels it.
Principle
Read what the user is forced to carry
The real test of a product is not how much it contains.
It is what it makes the user carry.
A strong product absorbs complexity on behalf of the person using it. It does not pretend complexity is gone. It decides where that complexity belongs.
A strong product absorbs complexity on behalf of the person using it. Complexity has to live somewhere. Strong product work decides where it belongs. Weak product work forces the user to inherit it.
That is the work beneath the screen: naming the parts, ordering the path, reducing unnecessary choice, preserving necessary control, and making sure the product behaves consistently when the happy path breaks.
When a product asks the user to interpret vague labels, compare unclear options, recover from preventable mistakes, remember information the system should have kept, or understand distinctions only the company cares about, the brief was not finished.
It may have been approved. It may have been scoped. It may have been designed. It may even have shipped. But it was not yet coherent.
The better question is not, “Does this match the brief?”
The better question is, “What does this product reveal about the brief?”
Because the product is where intention becomes evidence. It shows the real hierarchy, the real assumptions, the real tradeoffs, and the real level of care.
If the work is clear, the brief has been carried through.
If the work is confused, the brief is still arguing with itself.
The brief says what the team intended. The product shows what the team could actually bring itself to decide.
principle
How to read the work
Do not judge the work only by what it says. Judge it by what it repeatedly forces the user to resolve.
A strong product absorbs complexity on behalf of the user. It does not pretend complexity is absent. It decides where the complexity belongs.
That is the real work beneath the screen: naming the parts, ordering the sequence, separating what is essential from what is merely available, and making sure the system behaves consistently under pressure.
When the product keeps asking the user to interpret vague labels, compare unclear options, recover from preventable mistakes, or carry memory the system should have kept, the brief was not finished. It may have been approved, but it was not yet coherent.
The better question is not, “Does this match the brief?”
The better question is, “What does this product reveal about the brief?”
Because the product is where intention becomes evidence. It shows the real hierarchy, the real assumptions, the real tradeoffs, and the real level of care. If the work is clear, the brief has been carried through. If the work is confused, the brief is still arguing with itself.