Start with the decision the website must support
A brief becomes useful when someone who has never attended your meetings can explain what the first release must do. “Modern, premium and easy to use” describes a preference. It does not tell a developer whether customers need to choose a service, upload a drawing, compare products or request a time slot.
Write down one customer situation first. Who arrives, what do they need to decide and what information should reach your team? Then describe the business outcome. A completed enquiry and a useful sales enquiry are different things. Your brief should explain the difference for your business.
The framework below is our practical way to turn that discussion into an estimate. It is not a prescribed industry form. The external references support the parts about task-based evaluation and planning accessibility; they do not validate a particular project budget or completion date.
Describe a real task without prescribing every click
Ask for a result a customer recognises. For example: a facilities manager needs to check whether you handle a particular type of building and send enough information to request an initial estimate. This leaves room to test whether the navigation and wording actually help.
Nielsen Norman Group’s guidance on usability tasks recommends realistic activities that prompt action without telling the participant how to use the interface. This is useful when you later turn the brief into a prototype review.
Avoid writing the whole brief as a list of components. A carousel, a calculator and a chatbot each need a purpose. Ask what would stop the customer completing the task if that component were omitted. If the answer is unclear, place it outside the first release until there is a reason to build it.
Use a scope table that reveals missing decisions
| Item | What to record | Example of a useful answer |
|---|---|---|
| Customer | Who uses this journey | An operations manager requesting a service estimate |
| Offer | What is being considered | Inspection and maintenance, with exclusions explained |
| First release | Pages and complete journeys | Three service pages and one enquiry route |
| Content owner | Who supplies and approves facts | The operations lead checks service limits and examples |
| Data | Fields, files and their destination | Service, location, contact and an optional approved file type |
| Acceptance | Evidence that the journey works | A submitted request reaches the agreed inbox with its context |
| Later work | Deliberately excluded features | Calendar integration after the enquiry route is working |
Page count alone is a weak scope description. Ten pages built from one shared layout can require less implementation work than a single page with a complex quote engine. Record reusable layouts separately from the amount of content that must be prepared and entered.
Give integrations their own short description
“Connect the CRM” leaves several unanswered questions. Identify the system, the record to create, the fields to transfer and the person who owns the receiving process. Say whether an existing customer can send a new request and what should happen when the same delivery is retried.
Provide redacted examples rather than live customer records. A sample request and an expected destination record often reveal ambiguities faster than screenshots of settings. List available documentation and the account owner. Share credentials through an agreed secure handover, separately from the brief.
You do not need to design the implementation yourself. You do need to identify the business rules that the implementation must respect. Where those rules are unknown, ask for a discovery deliverable before treating the integration as a fixed-price item.
Plan accessibility and content before visual approval
Accessibility belongs in the scope discussion, alongside content and testing. W3C’s planning guidance covers objectives, responsibilities, resources and measurable review criteria. It also explains why checks should begin before the website is finished.
For your brief, name the agreed accessibility target and the journeys to evaluate. Record who checks keyboard operation, form errors and content readability, and which checks need specialist review. A passing automated scan is not a substitute for an agreed evaluation scope.
Also identify who can approve claims, images and translated terminology. A layout cannot settle whether a service description is true. If those decisions arrive late, the developer may be ready while the project still cannot be published.
Worked example: a service enquiry
This is an illustrative project, not a client result. A business receives messages that contain a name and phone number but omit the service required. The first release therefore includes three service pages and a shared form that keeps the selected service attached to the request.
Its acceptance check is specific: choose a service on a phone, enter valid contact details, submit once and inspect the received message. It must contain the service and the entered information. A validation error must explain what to fix. A failed delivery must not display a success message.
The prototype review checks whether someone can find the right service and understand the request. The implementation review checks the actual submission and delivery. These are separate pieces of evidence. Neither needs an invented conversion uplift to justify checking the journey.
Agree decisions, review rounds and handover
- Name one person who can approve scope and resolve conflicting comments.
- List the material needed before each stage can begin, with an owner for every item.
- Define what a review round includes and how additional requests change the estimate.
- Link milestone approval to an inspectable deliverable rather than an unexplained percentage of progress.
- Include launch checks, access ownership, backups and instructions for routine changes.
Before requesting quotes, ask a colleague to read the brief without your explanation. If they cannot describe the first release and the conditions for accepting it, add the missing decisions. The aim is a shared understanding of the work, not a long document.
Put the brief to work
Use the website project brief to describe the first customer journey. If you already have competing proposals, read how to compare website quotes before choosing a supplier. For a rebuild, include the existing addresses and use the redesign brief.
Evidence and sources
Sources checked on 15 October 2026. The scope table, example and handover checklist are WebSoftLeader’s editorial framework. The example contains no measured client results.
- Nielsen Norman Group: writing realistic usability tasks. Supports the task-based review approach.
- W3C WAI: planning accessibility. Supports planning responsibilities, resources and evaluation early.
Коротко о важном
Do I need a complete specification before speaking to a developer?
No. Bring the business goal, a real customer task and examples of the information involved. Unanswered questions can become a small discovery task. Ask what that task will deliver and how its findings affect the estimate.
Should I include the budget in the brief?
A spending limit helps decide what belongs in the first release. State whether it includes content, external fees and ongoing work. A budget is a constraint to plan around, not a reason to fill the estimate with unnecessary features.
Is a prototype enough to approve the whole project?
It can support approval of structure and interaction, but it does not prove that real forms, payments or integrations work. Keep separate acceptance checks for the built version.
Development and SEO at WebSoftLeader. Clear explanations and a practical first step for your project.
About Vladimir
