TL;DR: A great web design brief is one page, answers five questions ruthlessly, and gets signed before any design work starts. The five fields: what is this site for (name the buyer, the stage, the job in 60 seconds), who lands here and from where (traffic temperature and source), what are the three takeaways, what is the primary CTA, and what does good look like (one or two reference sites). Bad briefs are two pages of corporate framing. Good briefs are a single page of specifics. The clear ones ship faster, cost less, and end up with better sites. No brief, no sprint. A $5k project without a signed brief becomes a $9k project in disguise.
We ask every client to fill out the same one-page brief before we quote. Most of them send back two pages of corporate framing. A few send back a single page that is ruthlessly clear. The clear ones ship faster, cost less, and end up with better sites. Here is what a great brief actually looks like, field by field.
This is a real brief from a recent client, anonymized. The italic notes are ours.
Field 1: What is this site for?
Selling our new developer-focused CI platform to technical founders at seed-to-Series-A startups. We need a site that makes a technical buyer trust us in under 60 seconds.
What makes this good: it names the buyer (technical founder), the stage (seed to A), and the job (trust in 60 seconds). "Developer-focused" is not filler — it tells us the site is read by skeptics who will check the meta tags.
What people usually write instead: "to showcase our product and grow our business." Useless. Every site does that.
Field 2: Who lands here, and from where?
Mostly inbound from Hacker News and Twitter after launch posts. Some warm leads from sales calls sending the site as a follow-up. Very little paid acquisition yet.
What makes this good: it tells us about traffic temperature (warm-ish, technical, skeptical) and referrer (HN commenters, Twitter skimmers). A HN-primary site should be heavy on honest technical content and light on marketing polish.
What people usually write instead: "our target market." We cannot design for a target market. We design for someone who just arrived from a specific link.
Field 3: What are the three things they should take away?
- This is built by people who have actually built CI at scale.
- The product is faster and simpler than Circle/GitHub Actions for the jobs we target.
- It is easy to try without a sales call.
What makes this good: three things, ranked. Not five. Not "our mission, vision, values." Actual takeaways that have implied consequences — takeaway 3 means we need a prominent "start free" path.
What people usually write instead: a laundry list of features. Features are not takeaways.
Field 4: What is the primary CTA?
Start a free project. Credit card not required. Secondary CTA is "Talk to the team" for deals over 20 users.
What makes this good: one primary CTA, one secondary, and the trigger for each. "Credit card not required" is a copy note we would otherwise have to dig for.
What people usually write instead: "book a demo and sign up and read docs and see pricing." Every CTA added weakens the others.
Field 5: What does "good" look like?
Linear.app for type and discipline, Fly.io for the technical-honesty voice. Not Vercel — we don't want to look like a developer tool trying to be a design agency.
What makes this good: two positive references and one explicit negative. "Not X" is as useful as "yes X." It tells us the client has a real opinion.
What people usually write instead: a list of five sites that do not go together, with no framing. Five references without a pattern is no reference.
Field 6: What have you tried already, and what hasn't worked?
We built a one-page site in Framer last year. Traffic was fine, conversion was not. Nobody stayed long enough to learn what the product actually does. Also the Lighthouse score embarrassed us every time we linked to it.
What makes this good: it tells us what changed. We know we are not the first attempt, we know the failure mode (depth of engagement), we know a technical signal the client cares about (Lighthouse). This shapes what we build and what we avoid.
What people usually write instead: nothing, because they are embarrassed. Do not be. Every studio wants this context.
Field 7: What is the deadline and why?
Launch by March 27. We are speaking at a conference on April 2 and want the site stable by then, ideally with a week to catch bugs.
What makes this good: a hard date with a real reason. We can work backwards. We know what happens if we miss the date — embarrassment at a conference. That changes our risk tolerance.
What people usually write instead: "ASAP" or "flexible." Both of these mean the project will take longer than it should, because nobody is pressuring a decision.
Field 8: What is your budget range?
$6k–$9k. We want custom work, not a template. If the number needs to be higher for what we're describing, tell us why.
What makes this good: a range, not a ceiling. An invitation to push back. A statement that custom is a requirement.
What people usually write instead: "get back to us with a quote," which forces us to guess. We end up quoting a range we hope fits and the conversation becomes about budget instead of scope. Tell us the number.
Field 9: Who on your team owns this?
Final say on design: Priya (CEO). Final say on copy: Marcus (CTO, writing most of it). No one else has veto power.
What makes this good: named humans with named domains. No veto power from people not listed. This prevents the "wait, my cofounder needs to weigh in" moment in week 3.
What people usually write instead: a list of titles. Titles do not approve designs, people do.
What we add to the brief
After we get these answers, we add three things before the project starts.
A success metric. "The site is a success if X." Usually a signup rate, a scroll-depth number, or a sales-call conversion number. Not for OKRs. For us, to know what we were aiming at six months later.
A non-goal list. "We are explicitly not trying to rank for X right now." "We are not building for enterprise buyers in this version." Non-goals let us say no cleanly.
A risk register. The three things most likely to blow this up. Usually: copy slipping, a cofounder with opinions not yet surfaced, or a migration from an old system we have not fully scoped.
Why this works
A good brief is not bureaucracy. It is the forcing function that makes the team think hard before spending money. Every bad project we have shipped started with a vague brief. Every good project we have shipped started with a brief under one page that had strong opinions in every field.
If you want our brief template, email us. We send the Notion doc over with no email gate. Use it with any studio, not just us.