What a Design Studio Needs From You Before Work Begins
A product build brief is the document that gives a design studio enough context, constraints, and success criteria to actually design something without pinging you every other day for clarification. It's not a mood board, and it's not a wishlist of features you'd like someday. Think of it as the reference the studio keeps open on a second monitor, the thing they check every time a decision needs making.
Six things separate a brief that works from one that doesn't:
- Problem statement / business goal
- Target user and use context
- Functional and technical constraints (platform, stack, integrations)
- Success metrics, meaning what 'done well' actually looks like
- Timeline and budget boundaries
- Existing assets: brand guidelines, prior research, competitor references, whatever you've already got lying around
Here's a decent rule of thumb: a good brief means fewer clarifying questions at kickoff, not more. If that first call turns into forty-five minutes of the studio asking things your document should already cover, the brief missed the mark. Simple as that.
Briefs and specs get mixed up constantly, and it's worth separating them properly. A brief sets direction. Where the edges are, what actually matters, what doesn't. A spec goes further: exact screens, states, copy, every edge case spelled out. The failure mode I see most often is founders handing over a spec-heavy document while expecting brief-level flexibility from the studio, or the reverse: a loose, three-paragraph brief with an expectation that the studio will somehow reverse-engineer spec-level precision out of thin air.