What should a design brief include?

The decision or change you want, the constraints that cannot move, the evidence you already have, and who approves. Screens and solutions are optional — being handed the answer removes the part of the process most likely to improve it.

How much does it cost to work with a design studio?

It depends on shape more than duration: an embedded engagement, a fixed-milestone scope and a two-week diagnostic price very differently. Tell a studio the decision and the deadline and it can propose the shape that fits.

How long should a design brief be?

One page is usually enough if it contains the decision you want made, the constraints that cannot move, the evidence you already have, and who approves. A polished deck that hides the awkward parts is longer and less useful.

What should you not put in a design brief?

A solution, a layout sketch, or a competitor's feature list as a requirement. Share them as context if you have them — being handed the answer removes the part of the process most likely to improve on it.

3 February 2026 · 8 min read

How to brief a design studio

The brief decides most of the outcome before anyone opens a design tool. What a studio needs, and what you can safely leave out.

Process
Collaboration

The short version

Lead with the decision or change you want, not a list of screens.
Name the constraints you cannot move — hidden constraints, not stated ones, cost you weeks.
Bring evidence (tickets, call recordings, funnel exports) rather than adjectives.
You are buying the ability to make the next hundred decisions faster, not a set of files.

Briefs arrive in two shapes. One is a list of screens with a deadline. The other is a paragraph of ambition with no constraints. Both push the important conversations into week three, where they cost the most.

Lead with the decision you are trying to make

The most useful first line is not what you want built but what you are trying to find out or change. Grow trial-to-paid. Stop losing enterprise deals at the security review. Make the product look like the price. That sentence lets a studio argue with the scope — which is most of what you are paying for.

A brief that specifies the solution gets you the solution you specified. A brief that specifies the problem occasionally gets you something better and cheaper than what you had in mind, which is the only real upside available in this kind of engagement.

Name the constraints you cannot move

The framework and component library already in production.
Contracts you cannot break: URLs, terminology, regulated copy, contractual SLAs.
The date something external depends on, and what happens if it slips.
Who has to approve, and when they are away.
Anything a previous attempt already ruled out, and why.

Constraints do not reduce the quality of the work; hidden constraints do. A studio that learns about your compliance review in week five will redesign around it in week six, and you will pay for both weeks.

Bring evidence, not adjectives

Ten support tickets, two sales-call recordings and a funnel export are worth more than a mood board and a list of words like premium and intuitive. Adjectives generate rounds of revision because nobody can prove a design is or is not them. Evidence generates decisions.

The last three months of support volume, grouped.
A funnel export for the flow in question, with the definitions written down.
Two or three recorded calls where the problem comes up unprompted.
Screenshots of the current thing, including the states you are embarrassed by — especially those.

You are not buying screens. You are buying the ability to make the next hundred decisions faster.

Say how you will judge it

Write down, before the work starts, what would make this a success and who decides. If the answer is a number, name the number and the timeframe. If the answer is qualitative — "it should look like we are worth the enterprise price" — say who gets to make that call, because unnamed taste is the single most common cause of a project running long.

What you can leave out

You do not need a solution, a layout sketch, or a list of features from a competitor. If you have them, share them as context rather than as a requirement — being handed the answer removes the part of the process most likely to improve it. You also do not need a polished document. A page of honest bullet points beats a deck that hides the awkward parts.

Questions we get asked

What should a design brief include?: The decision or change you want, the constraints that cannot move, the evidence you already have, and who approves. Screens and solutions are optional — being handed the answer removes the part of the process most likely to improve it.
How much does it cost to work with a design studio?: It depends on shape more than duration: an embedded engagement, a fixed-milestone scope and a two-week diagnostic price very differently. Tell a studio the decision and the deadline and it can propose the shape that fits.
How long should a design brief be?: One page is usually enough if it contains the decision you want made, the constraints that cannot move, the evidence you already have, and who approves. A polished deck that hides the awkward parts is longer and less useful.
What should you not put in a design brief?: A solution, a layout sketch, or a competitor's feature list as a requirement. Share them as context if you have them — being handed the answer removes the part of the process most likely to improve on it.