How to Write a Good Website Brief

A good brief is the single most useful thing you can provide to a web development team. It doesn't need to be long or polished. It just needs to answer the right questions clearly enough that the people reading it can understand what you need and give you an accurate proposal.

We've received briefs that range from a single sentence to forty-page documents. Neither extreme is ideal. Here's what actually helps.

Start with the problem, not the solution

The most useful briefs tell us what you're trying to achieve, not how to achieve it. "We need a website that helps potential clients understand our services and get in touch" is more useful than "We need a WordPress site with a slider on the homepage and a blog."

The first version tells us the goal. We can then figure out the best way to achieve it, drawing on our experience across different technologies and approaches. The second version skips straight to implementation details that might not be the right answer.

What to include

About your organisation

Who you are, what you do, who you serve. This doesn't need to be long, but it helps us understand your context. A legal aid organisation has very different needs from an e-commerce startup, even if the project scope looks similar on the surface.

What you want the site to do

The primary purpose. Is it to generate leads? Provide information to the public? Sell products? Support existing clients? Most sites do several of these, but knowing the priority helps us make design and architecture decisions.

Who your audience is

The more specific you can be, the better. "Small business owners in Australia looking for accounting software" is more useful than "everyone." If you have multiple audience types, list them and note which is most important.

What you already have

Do you have an existing site? Existing content? Brand guidelines? Analytics data? Knowing what we're working with helps us scope the project accurately. If you're starting from nothing, that's fine too, but it affects the timeline and budget.

Your constraints

Budget range, timeline, internal approvals process, technical requirements, compliance needs. Being upfront about constraints helps us propose something realistic rather than something aspirational that doesn't fit your situation.

What you can skip

You don't need to specify the technology, the number of pages, or the exact features. That's our job. You also don't need to provide wireframes or design mockups unless you have strong opinions about the layout.

Lengthy background sections, mission statements, and org charts aren't usually necessary. We want to understand your problem and your audience, not read your annual report.

Keep it honest

If your budget is limited, say so. If your timeline is tight, say so. If there are internal politics that might affect the project, mention it. We're not going to judge you. We're going to use that information to give you better advice and a more realistic proposal.

The worst briefs are the ones that oversell the opportunity or hide the constraints. That leads to proposals that don't match reality, which leads to problems later.

Format doesn't matter

A clear email is fine. A shared document is fine. A PDF is fine. We've worked from briefs scrawled on the back of a napkin (not recommended, but we made it work). The format matters far less than the content.

If you want a starting point, just answer these five questions: What does your organisation do? What do you need the website to achieve? Who is it for? What's your rough budget? When do you need it by? That's enough for us to have a meaningful first conversation.

Ready to start? Send us your brief, or just get in touch and we'll help you figure out the scope.