How to write a website brief if you are not a programmer

A brief is not a 40-page document

For a small website, two or three clear pages can be enough. The purpose is not to impress with terminology but to remove ambiguity. “Contact form” can mean name and phone to one person, while another expects file uploads, service selection, consent and an email notification.

Start with five simple questions

1. What should the website change? More leads, fewer manual questions, sales, bookings or trust?
2. Who uses it? New customer, returning customer, employee, administrator?
3. What should the user do? Write the path as actions.
4. What happens afterwards? Where does the enquiry go and who responds?
5. How will you know it is finished? Define observable acceptance criteria.

A structure you can copy

Describe functions through behaviour

“We need a client portal” is too vague. Better: “After login the client sees their enquiries with number, date and status; they can open one, read admin messages and download the final file.” You do not need to mention JavaScript, PostgreSQL or APIs for a developer to estimate that flow.

Use references correctly

Links are useful when you say what you like: typography, catalogue density, navigation or interaction. Add two to four examples with one sentence each. “Make it like Apple” does not explain your business goal.

Content is part of the brief

Before design begins, decide who provides copy, photos, prices, documents and translations. Placeholder text can hide layout problems that appear as soon as real content is added, especially on mobile.

Add acceptance criteria

• Works in current mobile and desktop browsers.
• Forms really send data.
• No horizontal scrolling on phones.
• Important pages have title and description.
• The owner receives domain, hosting and service access.
• The complete user journey is tested on the production domain.

Do not prescribe technology without a reason

“Must use React” or “must be microservices” makes sense only when there is a technical reason: an existing team, standard or integration. Otherwise describe the desired result, load, roles, files and editing needs. A good developer should explain the proposed stack and its trade-offs.

Mark priorities

Use three labels: must launch, nice to have and later. If budget or time gets tight, the team already knows what cannot be removed and what can safely move to the next iteration.

What to request at handover

• Source code and repository access.
• Domain, DNS and hosting access.
• List of external services.
• Short admin instructions.
• How deployment works.
• Known limitations, if any.

Write these items into the brief from the beginning so handover is part of the work, not an unexpected request after launch.