How to write a website brief: goals, pages, features and acceptance criteria

The essentials of a website brief

A website brief defines the result you are commissioning: who the website serves, what action it supports, which pages and features are included, and how completion will be checked. Start with business goals and customer journeys, then specify content, integrations, constraints and acceptance tests. Visual references communicate a style; they do not replace functional requirements.

• Define the main visitor action and how enquiries will be recorded.
• List page templates, languages, essential features and exclusions.
• Give each critical feature an input, an expected result and a repeatable test.
• Assign owners for content, access, approvals and acceptance.
• Agree how changes and the final handover will be managed.

1. Define the business problem and audience

Before approaching a business website development agency in Moldova or Europe, explain the working situation. What do you sell, who evaluates it, where will visitors come from and what should happen next? “Build a modern website” leaves those decisions open. A custom website development proposal becomes easier to compare when agencies estimate the same outcome.

Separate a website requirement from a business target. Recording an enquiry and sending it to a named sales owner is testable. Achieving a particular number of sales also depends on demand, pricing, traffic and the sales team. Do not treat a revenue ambition as proof that an otherwise unspecified website has been completed.

For international businesses, name the actual markets and supported languages. “European audience” is too broad to decide currencies, delivery or local wording. If you have not chosen a format, compare the options in our website format guide.

2. Inventory pages and reusable templates

Distinguish page templates from individual pages. A homepage, service page and article usually have different structures. Ten services may use one approved template with ten independent sets of content. Record both counts so that neither party confuses the number of pages with the amount of design work.

For each entry add a proposed URL, language, objective and content status. Include the documents your process requires, with the appropriate specialist responsible for their wording. For a corporate website, define navigation between services as well as the homepage layout. A page list alone does not describe how visitors find an answer.

3. Specify features as user journeys

“Connect the CRM” is a heading, not a complete requirement. Which form creates which record? What fields are sent, who owns the lead, and what happens after a second submission or a temporary error? Use identifiers such as FORM-01 and CRM-01 so that questions and test results refer to a specific requirement.

For website and service integrations, attach a field map and identify the authoritative system for each data type. Online stores also need product variants, stock ownership, payment and delivery rules. Each extra feature creates implementation, testing and maintenance work; give it a business reason.

4. Assign content and localisation responsibilities

Content should have a delivery plan rather than a hopeful placeholder. Keep a register containing the page, material, source, owner, due date and approval status. If copywriting is included, agree the factual sources and editing rounds. If translation is included, identify who reviews terminology and market-specific conditions.

• Separate writing, translation, upload and ongoing updates.
• Identify who supplies photographs and permission to publish them.
• Define mandatory product attributes and an import format where relevant.
• Use meaningful image descriptions and alt text, rather than keyword lists.
• Choose one person to consolidate the client team’s feedback.

A multilingual website needs complete versions of content, navigation, forms and links. A language label in a menu is not a translation deliverable. When commissioning website development for your business, disclose which languages your team can actually support after launch and which materials remain unavailable.

5. Agree technical quality and SEO responsibilities

Make quality conditions observable: supported browsers and viewport sizes, keyboard access to navigation, visible field labels and understandable validation errors. Replace “must be fast” with the pages, device, measurement method, conditions and target to be agreed. A single laboratory score does not describe every visitor’s connection or device.

The brief should assign responsibility for distinct title tags and descriptions, a clear H1, logical H2/H3 headings, preferred URLs and language alternatives. A migration also needs an old-URL inventory and redirect plan. Our pre-launch SEO checklist helps structure checks; deeper issues belong in technical SEO work. A brief should not promise a ranking position as an automatic development outcome.

Record backup, access and handover arrangements. Do not paste passwords or API keys into a widely shared requirements document. Name the access owner and the approved transfer method instead. Privacy and other legal wording must match the actual countries, data flows and business process.

6. Write repeatable acceptance tests

An acceptance criterion states the observable condition that means a requirement is complete. Specify the initial state, action and expected outcome. “The form works” can mean different things to the developer, salesperson and client; the following tests give them the same evidence to inspect.

Add status, evidence and a correction owner to the test log. Agree which defects block launch and which may be resolved later. Test on the published site or an agreed staging environment, and mark test enquiries so they do not distort sales reporting. Include meaningful error cases alongside the successful journey.

7. Separate launch scope, changes and maintenance

Define the essential first release, later phases and exclusions. A service enquiry site may launch before a customer account or a complex calculator is added. This makes development decisions explicit rather than turning every new idea into a dispute about the initial quotation.

1. Approve a dated version of the brief before the final scope estimate.
2. Record new requests together with their effect on cost and timing.
3. Agree approval stages for design and functionality.
4. List recurring platform, hosting, domain and third-party service costs.
5. Include accounts, source materials, instructions and known limitations in handover.

Website maintenance after launch should have its own scope, coverage and responsibilities. Do not assume unlimited updates are included indefinitely. Clarify who can update the website and who will check that changes do not break important journeys.

8. A practical starting template

Copy the structure below into a shared document. If something is unknown, label it “to be decided during discovery”. An honest open question is more useful than an invented technical specification. This framework works for a local supplier or a remote international development team; market and operating details must be adapted.

1. Context: product, audience, markets and the problem to solve.
2. Goal: main visitor action and how its completion is checked.
3. Scope: page inventory, templates, languages and first-release exclusions.
4. Features: journeys, field maps, integrations, repeats and errors.
5. Content: copy, images, data, delivery dates and owners.
6. Quality: mobile use, SEO, accessibility, security and performance testing.
7. Acceptance: tests, defect priorities, approver and correction process.
8. Handover: access, training, documentation and maintenance terms.

Send the same document version to shortlisted agencies and request an itemised response with exclusions. Compare equivalent deliverables rather than the lowest total alone. The purpose of a brief is a shared understanding that can be tested, not a large document that nobody can use.

9. Common client questions

Do I need a finished brief before contacting an agency?

No. Start with your business, audience and desired customer action. Detailed journeys can be developed during discovery, but major uncertainties should be resolved or explicitly recorded before committing to scope and price.

How does a brief differ from a technical specification?

A short brief gathers context and expectations. A requirements specification translates them into agreed pages, features, constraints and tests. A small project can use one document if it provides a sufficiently clear basis for delivery.

Can sales be a website acceptance criterion?

Website acceptance checks implementation and agreed behaviour. Sales also depend on the offer, market, acquisition and follow-up. Discuss commercial KPIs separately with defined measurement and responsibility. They should not conceal missing functional acceptance tests.