Key decisions
- Important user tasks are named.
- Requirements and assumptions are distinguished.
- Content owners and approval owners are identified.
- Pending assets and dependencies are visible.
Start with the visitor’s task
Choose the actions that matter: understand the service, compare suitable options or submit a request with the required information. Write the intended reader and the next step. MDN’s planning guidance supports thinking before coding; this matrix is our editorial way to organise that conversation. A reference site can suggest a direction, but it does not specify which pages or integrations your own business needs.
Assign content and decision owners
For every important page, identify who supplies the facts and who approves them. Mark copy, images and translations as ready, pending or outside scope. Keep source references for material claims. A page that depends on an unapproved service description has a content dependency, not merely a design task. Naming the owner helps the project find the missing decision before it becomes a release surprise.
Separate requirements from assumptions
A requirement is an agreed behaviour; an assumption is a belief that still needs confirmation. If the brief says visitors need an account, ask which task requires it. GOV.UK’s interview guidance is useful context for investigating user needs. Write the evidence or question beside the assumption instead of treating an internal preference as established audience demand. Keep new requests in a visible change list.
Connect scope to acceptance
Add a check that can demonstrate each important requirement. For a file download, name the expected file and the page where the journey begins. For an enquiry, state the confirmation and destination covered by the review. This does not set a price or deadline automatically: dependencies and operational requirements still need discussion. The finished matrix should make the next project conversation precise enough to produce a written scope.
| Item | Evidence needed | Decision |
|---|---|---|
| Required reader journey | Agreed task and expected result | Include and define acceptance |
| New optional idea | Purpose, dependencies and effort to assess | Evaluate separately before expanding scope |
| Unknown integration | Current documentation and bounded trial | Keep open until evidence resolves it |
An illustrative planning matrix; project terms follow the actual agreement.
Try the exercise
Create a scope matrix for a fictional two-language course website. Include three user tasks, the owner of each content item and one assumption that needs a research question before implementation.
Expected output
A brief with clear tasks, owners, dependencies and checks. It is a preparation exercise and does not establish a quote or delivery commitment.
Your evidence checklist
Mark only what you have checked. This records your own progress, not an independent audit or a predicted result. There is no automatic saving; download the note if you want to keep it.
0 / 6 checked
Questions and answers
Do visual references replace a written brief?
They can communicate an aesthetic preference, but they do not define tasks, content ownership or acceptance. Pair them with a small scope matrix so the team can connect the look you want with the behaviour and information the website must deliver.
Must every decision be final before discussion?
No. A useful brief makes unresolved decisions visible and gives them owners. That lets the discussion focus on the missing facts or trade-offs. Hiding uncertainty behind a long requirement list makes later scope changes harder to understand.
Next step
A good brief makes tasks, owners and unresolved assumptions clear enough for the next decision.