How to write a website development brief.
A useful development brief names the user, the task they need to complete, the constraints and the evidence that the work is finished. Start there. A list of pages or a visual reference alone is not enough to estimate a build.
Use the free worksheetA contact form is a workflow, not a field list.
Illustrative example: a small studio needs quote requests from prospective clients. The release includes a service selector, a project description and a reply address. The studio must receive the request in its agreed system. A mailing list, customer account and automatic quotation are outside this release.
The requirement is complete only when both the visitor and the receiving team can tell what happened. These acceptance checks expose work that a screenshot of the form cannot show.
| Situation | Expected behaviour | Evidence to review |
|---|---|---|
| Valid request | The agreed system receives the request. The visitor sees the correct delivery status. | Match the visitor's test details to a received record. |
| Missing reply address | Explain which field needs attention and keep the other entries. | No request is sent until the required input is valid. |
| Delivery unavailable | If nothing is saved, explain the failure. If queued, say it is pending. | Disable the receiving service and inspect the actual stored state. |
| Repeated submission | A repeated attempt must not accidentally create duplicate requests. | Submit the same attempt twice and inspect the receiving system. |
Describe the outcome before the features.
Write one sentence about the problem. For example: a customer should be able to request a quote with the right project information, and the team should receive it in one place. That is more useful than asking for a modern website with a contact form.
Then identify the audience and the person who approves the work. Different stakeholders can contribute, but conflicting feedback needs one owner. Name any immovable deadline and explain what makes it immovable.
Explain what a visitor should be able to do.
List the important journeys from entry to completion. For a publication, that could be finding a topic, reading an article and subscribing. For a portal, it could be signing in, uploading a file and seeing its review status.
Include the unhelpful cases. What should happen if the upload fails, the visitor has no account or the receiving service is unavailable? You do not need to design the technical solution. You do need to explain the outcome a person should see.
- Who starts the action, and what information do they have?
- What result should they see?
- Who receives or acts on the result?
- What should happen if the action cannot complete?
Identify the content and systems already in place.
Name the existing domain, website, CMS, business tools and integrations. If this is a redesign, list useful URLs and content that must be retained. Say which text and assets are ready, who will supply the rest and who has permission to use them.
For each external system, state what you expect it to do. Access documentation or a test account is more useful than a logo on a requirements slide. Share sensitive access separately through an agreed channel.
Separate launch requirements from later work.
Mark each requirement as needed for launch or a possible later addition. State the budget range if there is one, even when the exact scope is still being worked out. It helps a developer propose a release you can actually fund.
Use observable acceptance criteria. In the quote-request example, a valid submission should reach the agreed inbox or system, while an invalid submission should show a useful error and create no request. A success message without delivery does not meet that requirement.
Decide what happens after launch.
Who will edit the content, pay for hosting, receive error alerts and approve updates? Ask for the source, deployment instructions and the account access needed to operate the finished site.
A brief does not need to answer every question. Label unknowns so they can be investigated instead of silently assumed. At BRÈCHE, the first conversation turns those unknowns into scope, dependencies and the next decision.
The checklist.
- One primary outcome and an identified audience.
- Key user journeys, including failure cases.
- Content owner, existing systems and URLs to retain.
- Launch requirements, later ideas and known unknowns.
- Budget context, timing constraints and one review owner.
- Acceptance criteria, source ownership and operational handover.
Take it into the project.
Website brief worksheet.
Turn a website idea into a brief a developer can question, scope and verify. Mark what you do not know yet.
Download the worksheet (.txt)Plain text, ready to edit. No account or email required.
Preview the worksheet questions
- Outcome and audience
- Who is the site for? What should they finish doing? Describe the current problem in one sentence.
- Primary journey
- Record the entry point, the visitor's actions, the result they see and the person or system that receives it.
- Acceptance evidence
- Describe one successful attempt, one invalid attempt and one unavailable service. What observable result passes each check?
- Content and existing URLs
- List content to keep, content to create, old URLs to retain or redirect, the content owner and any usage permissions to confirm.
- Systems and access
- Name the CMS, hosting and integrations. Link to documentation or a test environment. Record who can grant access, without credentials.
- Release boundary
- Separate launch requirements from later work. For each unknown, name the person who can answer it and the decision it blocks.
- Budget, timing and approval
- State the available budget context, any real deadline and why it matters. Name one person to consolidate feedback and approve the release.
- Handover and operation
- Who owns the accounts and source, edits content, receives errors and maintains the site? What must the next developer be able to do?