How to brief a design team so you get what you wanted

This is the one that changes everything else.

“We need a dashboard redesign” is a solution. You’ve already decided the answer, and the best you can hope for is a competent execution of your own guess.

“Users can’t find their core metric within ten seconds of logging in, and it’s showing up in churn calls” is a problem. Now the team can tell you whether that needs a redesign, a different default view, or an onboarding change that costs a tenth as much.

You know your business better than any agency will. You do not necessarily know which interface change solves a given problem — that’s the thing you’re buying. Briefing the solution buys you hands instead of judgement.

“Our users” is not an audience. Two sentences of specificity beats a persona document:

• Who they are, concretely. “Ops managers at 50–200 person logistics companies, mostly on desktop, usually in the product for three hours a day.”
• What they’re trying to do when they hit this surface. “Reconciling yesterday’s deliveries before a 9am standup.”

That second sentence — the context of use — is the one most briefs omit and the one that most often changes the design. Someone reconciling data under time pressure before a meeting needs something very different from someone browsing.

Not “make it modern.” Something you could check.

Best case, it’s a number: activation rate, completion rate, time-to-first-action, support tickets about this flow. If you don’t have the instrumentation, say so — that’s fixable, and worth fixing before the work rather than after.

Second best, it’s a testable statement: “a new user reaches their first report without asking support.” That’s not a metric, but it’s checkable, which is enough.

Everything that can’t change, and everything that will get vetoed:

• Technical. The stack, the component library, browsers you still support, the API you’re stuck with for two more quarters.
• Brand. What’s locked and what’s negotiable. If the logo is untouchable, say it now rather than in round three.
• Political. Who has veto power and what they dislike. If your CEO hates carousels, that is a constraint and pretending otherwise wastes a week.
• Budget and timeline. Both. Withholding budget doesn’t get you a better price, it gets you proposals scoped for the wrong problem and a conversation that has to start over.

The awkward constraints are the valuable ones. A team that knows the real boundaries early designs inside them; a team that finds out late redesigns.

The fastest engagements share a pattern: everything needed was available in week one. The slowest share the opposite.

What we ask for, and why:

• Analytics access. So the first design decision is informed rather than guessed.
• Three to five session recordings of real users on the relevant surface. Ten minutes of watching someone struggle is worth an hour of briefing.
• Recent support tickets mentioning the area. Your support inbox is the cheapest research you own.
• One person who can answer questions within a day. Not a committee. A named person.
• Existing files — brand assets, design system, whatever exists, however messy.

The last one matters more than it sounds. Teams often apologise for the state of their files and withhold them. Send them anyway. Knowing what’s actually there is more useful than a clean start based on assumptions.