Project planning
How to Write a Website Brief That Produces Better Work
A useful website brief explains the business context, priority audience, desired user actions, current problems, proof, constraints, integrations and definition of success. It gives a designer enough truth to make decisions without dictating a solution before the problem has been understood.
Explain why the project exists now
Begin with the trigger. The company may be launching, repositioning, entering a new market, losing enquiries, replacing manual ordering or outgrowing an old system. This context helps the project team distinguish the core reason for investment from adjacent requests.
State the business outcome in plain language. Examples include increasing qualified enquiries, enabling direct reservations, reducing repetitive support questions or presenting the brand credibly to enterprise buyers. Avoid goals such as 'make it modern' unless you explain what modernisation must change for the user or business.
Define users by situation and intent
Demographics alone rarely explain a digital journey. Describe what the priority user is trying to accomplish, what they already know, what they fear and what evidence they need. A returning customer placing an order behaves differently from a first-time visitor evaluating credibility.
If multiple audiences exist, rank them. A website that treats every audience as equally important often produces a navigation system that makes nobody feel understood.
- Primary audience and their immediate task
- Secondary audiences that still require a path
- Questions users ask before acting
- Objections or trust barriers
- Devices, languages or accessibility needs
Document content, systems and dependencies
List the content that exists, the content that must be created and who can approve it. Identify logos, photography, product data, policies, translations and legal text. Content uncertainty is one of the most common reasons schedules slip.
Name every system the website may touch: payments, bookings, CRM, email, analytics, maps, inventory, authentication or internal databases. Do not assume an integration is simple because two products have APIs. Access, data quality, limits and failure handling must still be reviewed.
End with scope boundaries and acceptance
Separate must-have release requirements from future ideas. State the expected deadline and why it matters, but allow the project team to test whether scope and timing are compatible. List known constraints such as platform commitments, regulatory obligations or internal approval cycles.
Finally, define acceptance: supported devices, required journeys, content approval, performance expectations and who signs off. This turns the brief into the beginning of a shared specification rather than an inspiration document that means something different to every participant.
Frequently asked questions
How long should a website brief be?
A small website brief may be two to four focused pages; a complex platform may require a longer living specification. Length matters less than whether the brief clearly covers outcomes, users, content, functionality, responsibilities, constraints and acceptance.
Should a website brief include design references?
Yes, when each reference explains what is useful: hierarchy, tone, interaction, clarity or brand feeling. A folder of unexplained screenshots can create conflicting expectations and encourage imitation instead of an appropriate solution.
Do I need every requirement before contacting a developer?
No. You need enough business context to begin a useful conversation. A capable partner can help turn uncertainty into requirements, but unknowns should be identified and resolved rather than hidden inside a premature fixed quote.
From reading to deciding
Make the next decision concrete.
Send Amin the business context, current problem and required outcome. You will get a direct view of what should be clarified before anything is designed or built.