How to Write a Project Brief That Gets Good Results

A good project brief tells the person you’re hiring what you need, why you need it, and what success looks like. Knowing how to write a project brief well is one of the highest-leverage things a founder can do before starting any design or development work. It doesn’t need to be long. It needs to be specific. Founders who write a clear brief get better work, faster timelines, and fewer revision rounds. The briefs that get good results share the same basic structure: a clear problem, a defined audience, real constraints, and honest context.

Why your project brief determines the quality of the work

When someone sends me a one-line message like “I need a landing page for my SaaS,” I can start asking questions, and I will. But we’ve already lost time. More importantly, the vagueness usually signals that the founder hasn’t fully thought through what they want. That thinking has to happen at some point. The brief is the right place to do it.

A brief forces clarity before money and time get spent. It aligns expectations from the first conversation. It gives the designer or developer a reference point when making decisions during the project. And it protects you from scope creep, because the original scope is written down.

Projects usually go sideways not because of bad design or bad code, but because the founder and the designer had completely different mental pictures of what they were building. A brief closes that gap.

The discipline of writing a brief also tends to surface real product questions. What is the primary action? Who exactly is this for? What are we willing to cut? Those aren’t brief questions, they’re product questions. Answering them before the project starts is almost always faster than answering them in the middle of it.

What a project brief that gets good results actually includes

This is the structure I find most useful. Not every project needs every section, but most do.

The problem you’re solving

Start with what’s broken or missing. Not “I need a landing page.” Why do you need a landing page? Is your current one converting at 0.5% and you need to fix it? Are you launching a new product and need to start capturing emails before launch? Are you pivoting from one audience to another?

The more context you give here, the better. Tell me what’s not working. Share any data you have. Even rough numbers help.

Who you’re building this for

Describe your user or customer. Be specific. “Small business owners” is not specific. “Independent restaurant owners in the US with one or two locations who are already using a POS system and feeling burned by their current marketing vendor” is specific.

If you have personas, share them. If you don’t, write a few sentences about who you’re targeting, what they care about, and what they’re skeptical of. This shapes every design and copy decision.

What you want people to do

Every product, page, or feature has a primary action. What is it? Sign up, book a call, buy the product, request a demo, download the app?

Don’t list five goals. Pick one. If you truly have two goals, rank them. The primary goal drives the whole design.

What done looks like

This is where most briefs fall short. Describe what success looks like in concrete terms. Not “a clean, modern design.” That tells me nothing. Instead: “A single-page site with a clear headline, one CTA above the fold, three benefit sections, and social proof. We want someone to be able to understand what we do and sign up for a trial in under two minutes.”

If you have benchmarks, include them. Conversion rates, load time targets, accessibility requirements, whatever matters to you.

Your constraints

Time, budget, technical requirements, brand guidelines. These aren’t optional. They’re facts that shape what’s possible.

If you need this live in three weeks, say so. If you have a hard budget ceiling, say so. If your product only runs on a specific tech stack, that matters. If you already have a brand guide with fonts and colors, share it.

I’m much more useful when I know the actual limits upfront. Hiding constraints doesn’t help you. It just means I design something you can’t implement.

Reference points and preferences

Links to sites you like, screenshots of UI patterns that appeal to you, competitors you admire or want to differentiate from. These don’t need to be in the same industry. They just need to show your aesthetic direction.

Be honest about what you actually like. References are most useful when they show the direction you genuinely want, not the direction you think sounds impressive.

How long should a project brief be?

Shorter than you think. A good brief is rarely more than one page of text. If you’re writing a brief for a landing page, three to five paragraphs is usually enough. For an MVP, you might need more, but I’d still aim for under two pages before any attachments.

The point isn’t to document every detail. It’s to communicate the essentials clearly. If you find yourself writing a five-page brief, you’re probably trying to solve design problems in the brief that should be solved in the actual work.

A brief should answer: what is this, who is it for, what should they do, and what does success look like? If you can answer those four questions clearly, you’ve written a good brief.

What to skip in your brief

A few things I see in briefs that don’t help.

Adjectives that describe the vibe without describing the goal. “Clean,” “modern,” “intuitive,” “professional.” I hear these in every brief. They don’t tell me anything because everyone thinks their thing should be clean and modern. Skip them and describe the goal instead.

Long backstory about how the company was founded. I don’t need the origin story to design a landing page. Give me context that affects the work.

Feature lists without priorities. If you’re describing an MVP and you list 40 features, that’s not a brief. That’s a product roadmap that hasn’t been scoped. I’ll help you cut it down, but it slows things down if we have to do that from scratch.

Competitor teardowns. A sentence or two about where you sit in the market is useful. A full competitive analysis isn’t. Send me two or three competitors and tell me what you’re different about.

A project brief template you can use right now

Here’s the structure I’d suggest for most projects:

Project overview One or two sentences. What are we building and why now?

The problem What’s broken or missing? What happens if this doesn’t get built?

The audience Who is this for? Describe the person who will use or see this.

The goal What is the single most important action or outcome?

What done looks like Describe the output concretely. Scope, format, required elements.

Constraints Timeline, budget range, tech requirements, brand restrictions.

References Three to five links or screenshots. What do you like and why?

Context Anything else that affects the work. Existing data, past attempts, stakeholder dynamics.

That’s it. Fill that in honestly and you’ll already have a much stronger brief than the vague one-line requests most projects start with.

Want a head start? I send a structured intake form to every client before we start. Tell me about your project and I’ll send it over.

How to write a project brief for different types of work

The template above applies broadly, but a few things shift depending on what you’re building.

For a landing page

The most important sections are the goal, the audience, and what done looks like. I also need to know whether you need copywriting or if you’re bringing your own copy, whether you need the page connected to any tools (email platforms, CRMs, analytics), and what the page will live on (a domain you own, an existing site, a new one).

If you’re working with my flat-fee landing page service, I’ll walk you through this with my intake form. But the more you’ve thought about it before we talk, the faster we move.

For an MVP

Scope is everything. The brief for an MVP should be clear about what’s in v1 and what’s intentionally not. List the core user flows, not every feature. Tell me who will use it and what their main job-to-be-done is.

Also tell me what you’re validating. An MVP that’s testing whether people will pay is different from one that’s testing whether people will use a specific feature. That affects what we build.

If you’re thinking about your MVP build, bring a brief that covers the core loop. We’ll tighten it from there.

For AI automation

This one benefits from a different framing. Instead of describing the solution, describe the problem you’re trying to automate. What task takes too much time? Who does it now and how? What are the inputs and outputs? What would a good automated version do differently?

You don’t need to know anything about AI tooling. That’s my job. I just need to understand the workflow. For context, my AI integration service usually starts with a scoping call where I map your existing processes before we touch any tooling.

For a UX audit

A brief for an audit is simpler. Tell me what product you want reviewed, what user type I should focus on, and what you’re most worried about. Conversion problems? Onboarding drop-off? Specific flows that feel broken? Share access to the product and any analytics you have.

A clear brief lets me run a focused UX audit rather than a generic review.

How to write a project brief when you don’t have all the answers

This comes up a lot. Founders sometimes wait to reach out because they feel like they don’t know enough yet. That’s usually the wrong call.

A partial brief is much more useful than no brief. Write down what you know, mark the gaps clearly, and bring it to the first conversation. The gaps are actually useful information. They tell me where the product thinking still needs work, and that shapes how I approach the project.

Here’s how to handle common uncertainties:

If you don’t know the budget yet, write down what you’re hoping to spend and what you’d stretch to if the scope was clearly worth it. That gives me a real range to work with.

If you don’t know which features belong in v1, list everything you’re considering and flag the ones that feel essential versus nice-to-have. We can make that call together, but starting with your instincts saves time.

If you don’t know your audience well yet, describe who you think they are and what you’re still figuring out. An honest “we think our user is X but we’re not sure about Y” is more useful than a confident but invented persona.

If you’re not sure what the right format is, look at examples. Google’s re: Work project brief guide and the Nielsen Norman Group’s resources on UX documentation are both worth reading for context on how good teams frame project requirements. You don’t need to follow any specific format. You just need to answer the core questions.

A partial brief that names its gaps is always better than a polished document that papers over them.

Common mistakes that make project briefs less useful

I’ve read a lot of bad briefs. The failure modes are pretty consistent.

Writing for the wrong audience. Some founders write briefs as if they’re writing a pitch deck for investors. That’s the wrong framing. A brief isn’t about selling the vision. It’s about giving a practitioner enough information to do the work well. Strip out the market size slides and tell me about the user.

Confusing outputs with outcomes. “We need a redesigned dashboard” is an output. “We need users to complete their onboarding setup in the first session, and right now they’re dropping off before step three” is an outcome. The second one is far more useful because it tells me what to optimize for, not just what to build.

Not sharing what’s already been tried. If you’ve had a previous designer take a run at this and it didn’t work, tell me. If you’ve run copy tests and certain messages didn’t land, tell me. That context saves time and helps me avoid repeating mistakes that already cost you money.

Treating the brief as final. A brief is a starting point, not a contract. If something changes during the project, update it or at least note the change. The brief is most valuable as a shared reference, and it only works as that if it stays accurate.

The Shape Up method from Basecamp has a useful concept here: they distinguish between “problem” framing and “solution” framing in project briefs, and recommend staying in problem framing as long as possible. The brief is the right place to do that. Save the solution design for the actual work.

What happens when a brief is unclear

I always ask follow-up questions rather than guessing. But there’s a cost to that. It adds at least a day to the start of the project. More importantly, it tells me that the founder hasn’t fully committed to what they’re building. That’s not a fatal flaw, but it does make the early stages of a project harder.

The real risk isn’t that I’ll build the wrong thing. I’ve got enough experience to push back and ask. The real risk is that you’ll approve designs that don’t match what you actually needed, because you weren’t sure what you needed at the start. Then we’re both doing rework.

Good briefs prevent rework. That’s why they matter.

If you want to see how I structure project intake specifically, my about page has more on how I run projects from first contact to delivery. And if you’re trying to figure out what service makes sense for your situation, the services overview breaks it down by project type.

Frequently asked questions

How long should a project brief be?

For most projects, one page is enough. A landing page brief might be three to five paragraphs. An MVP brief might run to a page and a half. If you’re going longer than two pages (not counting attachments), you’re probably over-documenting the solution instead of describing the problem.

What’s the most important thing to include in a project brief?

The goal and the audience. Everything else can be worked out in conversation, but if I don’t know who you’re designing for and what you want them to do, I’m guessing at every decision. These two things define the whole project.

Do I need a project brief for a small project like a landing page?

Yes, even for a single landing page. A brief doesn’t need to be formal. Even a well-structured email covering the goal, audience, constraints, and a few references is enough. It saves time and reduces the chance of getting something back that misses the mark.

Should I include my budget in the project brief?

Yes. You don’t have to give an exact number, but a range helps. It tells me what’s realistic to propose and prevents us from designing something you can’t afford to build. Hiding the budget doesn’t protect you. It just slows things down.

What references should I include in a project brief?

Three to five examples of work you like, with a note on what you like about each one. They don’t need to be in your industry. If there’s a site you’ve always loved the way it explains a complex product, link it. If you hate a specific pattern (carousels, auto-playing video, modal popups), mention that too.

Can I write a brief before I know exactly what I want to build?

You can and probably should. Getting your thoughts down in a brief, even with gaps and uncertainties, is a useful thinking exercise. Mark the parts you’re unsure about and we’ll work through them. A partial brief is much more useful than a blank page.

Ready to start a project?

If you’ve got the outline of a brief, that’s enough to have a real conversation. I offer flat-fee services for landing pages, MVPs, AI integration, and UX audits, so there’s no ambiguity on cost from the start.

Tell me about your project and I’ll send you my intake form. It covers everything in this post, structured so it takes about 10 minutes to fill out.