Development4 min read
A website project brief: what to agree before development
“We need a modern website, something like this example” is a reasonable way to begin a conversation. It is a difficult basis for a quote. One person imagines a few information pages, another expects a searchable catalogue, and someone else assumes incoming orders will be processed automatically.
A website project brief records who the site serves, what people need to do and what the team will deliver. It should make sense to the business as well as the people building it. You can start without producing dozens of pages of technical terminology.
Describe the user's task first
Identify the visitors and the actions they need to complete. For an equipment supplier, that might mean comparing models, checking dimensions and requesting a quotation. This tells a project team more than “an attractive catalogue”.
The GOV.UK discovery research guide starts with understanding people's goals and existing difficulties before planning a service. Applied to a business website, that principle helps the team work from actual needs rather than a long collection of preferences.
Connect the main task to an outcome you can check. “Navigation should be convenient” leaves room for disagreement. “A visitor can move from a category to a suitable product and request a quote” describes a testable journey.
Separate the page list from the feature list
A page list establishes the structure, but does not describe all the work. A product page may contain only copy and a photograph, or it may also need variants, prices, documentation and stock management.
- Pages: home, about, services, catalogue, product detail and contact.
- Actions: search, filter, compare, send an enquiry or make a purchase.
- Administration: who adds products, changes prices and reviews enquiries.
- Integrations: payments, delivery, an accounting system or another external service.
Distinguish launch requirements from later possibilities. A catalogue and enquiry form may be essential now, while a customer account area can wait. Keep the later ideas in the document without accidentally including them in the first delivery.
Assign responsibility for the content
Agree who supplies copy, photographs, logos, product information and language versions before design begins. A bilingual website needs more than a language switch: both versions require navigation, form messages, content and links between equivalent pages.
For an existing website, inventory the pages and their addresses. Decide what stays, what changes and where old URLs should redirect. This belongs in the redesign plan, rather than becoming an unexpected launch-day task.
Give content delivery an owner and a date. A developer can build a layout using sample text, but the actual Georgian heading or a long product name still needs to be checked in that layout.
Write down how delivery will be accepted
For each important feature, explain how you will check the result. A form, for example, should accept valid details, explain errors, deliver to the agreed destination and confirm success only after receipt. That is a more useful acceptance condition than “the form works”.
Apply the same approach to mobile, tablet, language versions and administration. Agree representative screen sizes and browsers. Include practical tasks: a member of staff should be able to add a product and inspect it in both languages.
The official discovery-phase guidance also addresses goals, constraints and deciding how success will be assessed. A private website project may need a much smaller exercise, but it still needs answers to those questions.
Agree how changes affect the quote and schedule
Specify what the quoted work includes: design reviews, development, content migration, testing, launch and training. Identify domain renewal, hosting, paid licences and ongoing support separately where they follow different arrangements.
New requirements may emerge during the project. Both sides should know where a change is recorded, who approves it and how its effect on cost or timing is agreed. Changes are a normal part of project work; uncertainty grows when additions happen without an explicit decision.
A short checklist for the first discussion
- The business objective and the visitor's main task.
- Pages, features and required languages.
- People responsible for producing the content.
- Integrations, access requirements and known constraints.
- Acceptance checks, change handling and the scope of support.
The brief should remain a working document. Keep clarified decisions in one current version rather than scattering them across conversations. If the project is still an idea, tell us about the business and the customer's task; that gives us a useful starting point for defining its scope together.
