A good brief is not a long brief. It is a page that answers the questions a designer would otherwise have to guess.
You do not need a finished specification, a moodboard, or a 40-slide deck. You need to describe the problem clearly enough for someone to tell you whether they can solve it.
This is the one-page structure I use on the contact form. It works for a website, a brand, or a product screen.
1. The problem, not the solution
Start with what is not working.
"The current site is slow and the contact form is buried" is a problem. "I want a hero video and a new colour scheme" is a decision you have already made. The second one might be right, but it closes the conversation before it starts.
Write two or three sentences:
- What is happening now.
- Who it is hurting.
- What you want to be true instead.
If the problem is "nothing exists yet", say that. That is a valid starting point.
2. Who it is for
Name the people who will use the thing, not the people who will approve it.
A site for a holiday house has guests, not "users". A tool for a clinic has receptionists, nurses and patients, and they need different things. A brand for a startup has customers, investors and hires, and the first two may care about different signals.
You do not need personas. You need one sentence per audience, and a note on which one matters most right now.
3. What exists today
List the assets and constraints:
- A live site, an app, a Figma file, a logo, a brand guide.
- The platform you are stuck with, if any.
- The accounts you already own: domain, email, hosting, analytics.
- Anything that cannot change, such as a legal name or a product name.
This is where most surprises come from. If the domain is registered to a former developer, better to find out before the project starts.
4. What success looks like
One or two measures, not a wish list.
"More enquiries from the site" is a start, but it is not measurable yet. "Ten booking enquiries a month from people who already know the dates" is. "A site my sales team can send to a lead without apologising for it" is also valid.
If you do not have a number, describe the moment success becomes obvious. A designer can work with that.
5. The constraints
- Budget. A range is more useful than a single number. If the ceiling is $250, say so. The answer may be a smaller scope.
- Timeline. A real date, and why it matters.
- Decision makers. Who signs off, and who else needs to see it.
- Feedback. How quickly you can respond. A 20-day project with a one-week feedback gap is a 27-day project.
A one-page template
You can copy this into an email:
The problem: Who it is for: What exists today: What success looks like: Budget range: Timeline: Who decides: How quickly you can give feedback:
Eight lines. That is enough for a first reply.
What not to include
A brief is not the place for:
- A full page-by-page specification before anyone has discussed the problem.
- A moodboard of sites you like, with no note on what you like about them.
- "Make it pop", "modern", "clean", "premium" with no example.
- A list of every feature you might want one day. Separate the must-haves from the someday list.
- A deadline that is actually a preference. Say which one moves.
What happens next
A good designer should reply with one of three things: a question, a scope, or a clear no. "Thanks, I'll send a proposal in 48 hours" is not a reply if the brief is missing the problem.
I read every brief myself. If it is a fit, I send a fixed-price scope with line items and a date. If it is not, I say so and point you somewhere better. The contact form is the one-page version of this post.
The shorter the brief, the more honest the first conversation.