How to write a website brief people can actually build from

A useful website brief is a decision document, not a mood board or feature wish list. It gives everyone enough shared context to decide what the first release needs to do and what can wait.

Start with people and tasks

Name the priority audience, the situation that brings them to the site, the question they need answered, and the next action that would be useful. W3C’s planning guidance similarly starts with what a site should do, who will use it, how it is organized, and the user journey.

Include the constraints that change the work

• Existing content, evidence, and claims that have approval.
• Required integrations, data boundaries, and operational handoffs.
• Accessibility, privacy, performance, and sector requirements that need specialist review.
• Decision owners, review points, and what constitutes acceptance.

Turn it into a buildable scope

Separate the first release from later opportunities. For every priority page or workflow, state the audience, job, required content, primary action, dependencies, and owner. Do not use a brief to claim outcomes that have not been evidenced.

Kiwi can help clients turn an early brief into a focused information architecture, content plan, interface direction, and release scope.