How to write a useful website project brief
A good brief does not prescribe the design. It gives the project team enough context to make better decisions and identify risk early.
- Author
- Víctor Ribera
- Published
- Reading time
- 2 min read
A useful brief is a decision document, not a list of visual preferences. It explains the current situation, the desired change and the constraints that shape the work.
It does not need to be long. It needs to make important unknowns visible so that suppliers can propose a realistic scope instead of guessing.
Describe the business context
Start with why the project exists now. Explain what has changed, what is not working and what the business expects the website to improve.
- Business model and main offer
- Current website and known problems
- Target markets and languages
- The decision or deadline driving the project
Define audiences and actions
“Everyone” is not a useful audience. Name the groups that matter and the questions they bring. Then define the actions that represent success for each group.
- Primary and secondary audiences
- Main objections or information needs
- Preferred actions: contact, purchase, book, apply or download
- Any offline step that follows the website
Inventory content and functionality
List what already exists and what must be created. Mention forms, CRM, payments, analytics, multilingual content and legal requirements.
A content inventory prevents the design phase from discovering that key material is missing or owned by someone unavailable.
- Pages and documents to migrate
- Photography, video and brand assets
- CMS roles and editing needs
- Third-party systems and account ownership
State constraints and decision rights
Be transparent about timing, budget range, required technology and internal approval. These constraints help a team design a viable process.
Name the final decision-maker and the people who give specialist input. A project with unclear authority can lose more time in feedback than in development.
Ask for a response you can compare
Tell suppliers what you want back: approach, scope, assumptions, timeline, price structure and examples relevant to the challenge.
- Proposed phases and deliverables
- Dependencies on your team
- Explicit exclusions
- Post-launch support
- How changes to scope are handled
A brief should create clarity, not close the solution
Give enough context for informed decisions, but leave room for the project team to challenge assumptions. The strongest briefs define the problem and success criteria without pretending the solution is already known.
Discuss a project brief
