Someone hands you a brief. It says: redesign the onboarding flow. Users are dropping off. Most designers open Figma. The smarter move is to pause for thirty seconds and ask: how do we know that’s the problem?
Briefs feel like answers. They arrive with confidence — sometimes with a deadline attached, sometimes with wireframes already sketched out by whoever wrote them. They have the structure of a solved problem. But underneath most briefs is a stack of assumptions that nobody has tested, and sometimes hasn’t even named out loud.
The drop-off might not be an onboarding problem. It might be a targeting problem — the wrong users arriving in the first place. It might be a product-market fit problem dressed up as a UX problem. It might be something the data simply can’t tell you without talking to a human being first. Designing a better onboarding flow for the wrong root cause doesn’t fix anything. It just ships faster.
This isn’t an argument against briefs. It’s an argument about what they actually are.
Jeff Gothelf and Josh Seiden, authors of Lean UX, frame it cleanly: a brief isn’t a set of requirements, it’s a starting hypothesis. “We start with assumptions instead of requirements. We create and test hypotheses. Our goal is not to create a deliverable — it’s to change something in the world.” [1] That shift sounds small. In practice it changes everything about how you begin a project.
If the brief is a hypothesis, your first job isn’t to execute it. It’s to pressure-test it. What would have to be true for this brief to be correct? What’s the fastest way to find out if it is? What would change about the solution if it isn’t?
The Nielsen Norman Group describes discovery as the phase that exists precisely because moving forward on only assumptions is risky — the team may end up solving a problem that doesn’t really matter, wasting time, money, and effort [2]. Discovery isn’t a luxury. It’s the thing that determines whether the work you’re about to do is the right work.
In practice, this looks less dramatic than it sounds.
It doesn’t mean ignoring the brief or starting a three-month research phase every time someone asks for a new filter. It means asking — quickly, often informally — what assumption is load-bearing here? Every brief has one. The assumption that the problem exists where we think it does. The assumption that fixing this will move the metric we care about. The assumption that users experience this the way we imagine they do.
Name the assumption. Then decide how much it costs to be wrong about it.
On small bets, you proceed and adjust. On large ones — the kind where the wrong answer means six engineers building the wrong thing for a quarter — you spend a week finding out before you commit.
The most useful question isn’t what should we design?It’s an earlier one: what would have to be true for this design to succeed?That question surfaces the assumptions hiding inside the brief without requiring a formal research plan, a stakeholder workshop, or anyone’s permission.
The designers who do this well aren’t contrarian. They don’t push back on everything. They just treat the brief as the beginning of a conversation rather than the end of one — and they’ve developed a quiet habit of asking the question that nobody else thought to ask before the work started.
Most products have a design problem and a problem upstream of it. The brief usually describes the first one. The job is to find the second one before you start solving.
References