How to brief a design firm so the quote means something.

A brief is the problem, honestly told

The best briefs we receive aren't specifications. They're honest accounts of a problem: who has it, how badly, what's been tried, what winning would measurably look like. A brief that prescribes the solution ("we need an app and an aluminium enclosure") quietly hires the studio to decorate a decision instead of testing it. Tell us the disease and your constraints; let the diagnosis be part of the work.

If you draft with an AI tool, use it to find gaps, not to fill them. A language model will happily turn a few bullet points into pages of tidy prose, and the padding reads exactly like knowledge. The parts a studio needs most (what you've seen, what failed, what you're unsure of) are the parts only you can supply.

What to include

The user and the moment of use, as concretely as you can. The commercial frame: price ambitions, volumes, channels, and the deadline with its reason attached: "trade show in March" changes decisions that "ASAP" doesn't. Hard constraints, labelled as hard: standards you must meet, platforms you must fit, things legal has already vetoed. What exists already: prototypes, research, failed attempts (failed attempts are gold; they're paid-for evidence). And the honest state of belief: what's proven, what's assumed, what keeps you up. Budget range too, not because studios price to it, but because scope has to be designed to it, and pretending otherwise wastes everyone's first meeting.

What to leave open on purpose

The form, the architecture, the feature list beyond the essential: anything a Prove loop can answer cheaper than a committee can debate it. A good studio's first deliverable is often a sharper version of your own brief; if the firm you're talking to doesn't push back on at least one of your assumptions, you've hired an order-taker with a portfolio.

The agent-native lens: a brief that machines will read too

When your customer arrives through an assistant. Briefs describe the user. Increasingly they should also say whether an AI assistant stands between that user and the product: shortlisting it, comparing its specifications, setting it up, asking it for status. If that's likely, it is a requirement, and it belongs under hard constraints: specifications published as structured data an assistant can read rather than locked in a PDF, claims precise enough to be checked, and, for connected products, which capabilities an agent may read and which it may change only with a person's approval. Leave it out and the solution isn't kept open; the quote simply assumes a world without assistants.

When your own team works through agents. In an agent-assisted team, the brief stops being a document read once at kickoff. It becomes the reference agents check work against: the requirement a test result traces to, the constraint a design change is screened for, the budget a scope change is measured against. That raises the bar on how it's written. State each constraint once, plainly, with an owner. Mark what's assumed and what's proven, so an agent doesn't treat a hope as a spec. Version it, and have a named person approve every change, because a brief that agents can edit unseen is no longer anyone's statement of intent.

What the brief buys you

Comparable, honest quotes, because scope is quotable when the problem is clear. Faster starts. And a written record of intent that survives personnel changes on both sides, and that your tools can check work against long after the kickoff. Ours get answered with a scoped first loop and our straight read, which is exactly the deal described on our contact page: two paragraphs is plenty, and the strategy practice exists for the briefs that need building before they need answering.