A website project becomes expensive when important decisions are delayed until design or development is already underway. A useful brief does not need to predict every detail, but it should establish the problem, audience and constraints clearly enough for the team to make consistent decisions.
Use the following checklist before asking for page designs.
1. State the business objective
Describe what the website needs to change. Examples include:
- generate more qualified enquiries;
- explain a complex service more clearly;
- support a new market or proposition;
- reduce routine support questions;
- recruit staff; or
- replace an outdated site that is difficult to manage.
Avoid a goal such as “make it modern” without explaining what modernisation should achieve.
2. Define the priority audiences
List the people who need to use the site and what they are trying to accomplish. For each audience, note:
- what they already know;
- the questions or concerns they have;
- the evidence they need before trusting the business;
- the action they should take next; and
- any accessibility, language or device considerations.
When two audiences have different needs, the navigation and page structure should make the correct route obvious.
3. Clarify the offer
Write a plain-English summary of each service or product. Include who it is for, the problem it solves, what is included, how delivery works and what makes it credible.
A visitor should not have to decode internal terminology. Good design cannot rescue an offer that is still unclear.
4. Choose the primary calls to action
Decide which actions matter most. These may include submitting an enquiry, booking a consultation, calling, requesting a quote, registering, downloading information or starting a purchase.
Every page does not need the same action, but each important page should give the visitor a clear next step.
5. Inventory the content
Create a list of existing text, images, videos, downloads, testimonials, case studies, staff biographies and legal information. Mark each item as:
- keep;
- update;
- rewrite;
- create; or
- remove.
Assign an owner and approval date. Content delays are one of the most common reasons a website launch moves.
6. Separate evidence from claims
Identify the proof available for important statements. Useful evidence may include measured results, named testimonials, certifications, years of experience, project examples, process details or service guarantees.
Do not invent case studies, client logos or statistics. When evidence is not yet available, use transparent process information rather than unsupported claims.
7. List functional requirements
Record the features the site must support, such as:
- enquiry forms;
- appointment booking;
- payments;
- account areas;
- document downloads;
- multilingual content;
- search;
- a content management system;
- integrations with customer relationship or email tools; and
- review and approval before publication.
Distinguish a launch requirement from a future idea. This protects the first release from unnecessary complexity.
8. Document technical and operational constraints
Confirm the domain, hosting, email arrangements, existing analytics, integrations, security requirements and people responsible after launch.
Also identify who can update content, who approves changes and how quickly urgent corrections need to be made.
9. Agree how success will be measured
Possible measures include qualified enquiries, completion rate, page speed, search visibility, downloads, bookings, support deflection or recruitment applications.
Record a starting point when one exists. A number without a baseline is difficult to interpret.
10. Confirm legal and privacy responsibilities
List the legal entity operating the site, contact details, privacy requirements, cookie or tracking tools, intellectual property permissions and any sector-specific obligations.
Legal pages should reflect the actual business and technology in use. A generic template is a starting point for review, not a substitute for professional advice.
Turn the brief into priorities
At the end of the brief, define three groups:
- Must launch: essential for the site to achieve its first objective.
- Should follow: valuable improvements once the core journey is working.
- Could explore: ideas that need more evidence or budget.
This prioritisation gives the design and development team a clear decision rule. It also makes estimates more meaningful because everyone is discussing the same version of the project.
The result of a strong brief
A good brief reduces assumptions. It gives writers, designers, developers and stakeholders a shared picture of the audience, desired action and definition of done.
That does not remove collaboration. It makes collaboration more productive because feedback can be tested against agreed goals instead of personal preference alone.