How to Write a Page-Purpose Brief Before Creating Website Content

Before anyone drafts, complete and approve a one-page decision record with nine fields: intended audience, user question, page role, key message, required evidence, desired action, format, owner and review date. Check the proposal against the existing site and the wider customer journey first. The responsible decision may be to update, combine, redirect, reject or create, so a stakeholder's requested title or preferred format should not automatically become a writing assignment.

Why decide the page's purpose before drafting it?

Decide the purpose first so the team can establish a valid need, a distinct journey role, the proof required, the intended outcome and responsibility for the page after publication. GOV.UK guidance similarly calls for each published item to meet a valid user need and for records to identify likely users, their task, supporting evidence and acceptance criteria. A title, landing-page request or video preference proposes a solution; it does not establish that the solution is needed.

Without those decisions, the writer must infer whom the content serves, which question matters, what claims can be supported and how the page relates to existing material. The draft may then collect several stakeholder messages without resolving one coherent need. The nine fields below are a practical editorial synthesis of user-need, content-planning and lifecycle guidance, not an official standard. They create an assessment record, but they do not replace discovery, research, accessibility work, fact-checking, technical assessment or specialist approval.

What should the team check before approving another page?

Check whether the current site, transaction, tool or another channel already meets the need before approving a page. Search using the audience's likely language, trace the relevant journey and inspect content that partly answers the question. GOV.UK guidance advises reviewing existing material early, finding pages that can be updated, locating duplication and missing task information, and removing unnecessary duplication. Similar pages can blur which source is authoritative and make the needed answer harder to locate.

• Update an existing page when it already owns the need and role.
• Combine pages when fragments compete to provide one answer.
• Redirect or retire an obsolete page when another source becomes authoritative.
• Reject the request when evidence does not establish a need or distinct role.
• Create a page when the need, role, evidence, action, format, owner and review plan form a coherent proposal.

Apply those choices with judgement rather than treating consolidation as a mechanical clean-up rule. Limited repetition at the point of need can help someone complete a transaction, while a separate explainer may be justified when it prepares users for a later tool. The concern is competing or unnecessary content, not every instance of related information. Record what was checked and why the selected outcome is stronger than the alternatives so the decision remains understandable after the meeting.

Do not brief the writer to produce a page; brief the organisation to justify the page's job.

How do you define the intended audience and user question?

Define the intended audience by the task, situation or knowledge level that materially changes what the page must do, then state the central evidence-backed question in language those people would recognise. ‘All customers’ is too broad when new administrators, procurement leads and experienced operators need different information. The Canada.ca style guide likewise centres content on its intended audience and what people need for their main task. Specificity gives writers a defensible boundary for terminology, detail and assumed knowledge.

Evidence may come from analytics, call-centre records, previous research and relevant external data, but its sufficiency depends on the question. Traffic alone shows that visits occurred; it does not explain intent or prove that another page is the answer. Compare several signals where practical, document assumptions and identify what still needs validation. One central question may include closely connected subquestions, provided the proposed content can resolve them as one coherent need rather than becoming a catch-all for unrelated requests.

How do page role, key message and required evidence work together?

These three fields define what the page contributes, what its audience must understand and what will make that message credible. Page role describes the unique job within the journey and why another page, tool, transaction or channel cannot do it better. Key message states the essential conclusion, with the task-relevant substance placed before supporting detail. Required evidence covers both proof that the need exists and the sources, records, data, demonstrations or specialist verification required to support the published claims.

Consider a support explainer for customer administrators preparing to configure an integration. Its role may be to clarify prerequisites and direct a ready administrator to the correct configuration tool; the tool, not the explainer, performs the configuration. Guidance and transactions have different jobs, and information should appear where it is needed in the journey. Test the eventual page title, main heading and opening against the brief: WCAG 2.4.2 requires a page title that describes topic or purpose, although this check alone does not establish complete accessibility.

How should the desired action determine the content format?

State the desired action as what the audience should be able to decide, do, locate, compare, understand or reach next, then choose a format that supports that outcome. Treating the outcome as an acceptance condition keeps attention on whether the content performs its intended job. It need not be a lead, sale or form submission: a person may need to confirm eligibility, compare options, find a record or decide that they are not ready to proceed.

Choose guidance, comparison, reference, explainer, transaction step, tool, video or another form only after the need and journey role are clear. Planning guidance connects content type and placement with audience knowledge, the task and how people will complete it; service guidance also distinguishes between guidance and transactions. These principles do not create a universal taxonomy for business sites. If a transaction change, tool or non-web channel would perform the job better, record that decision instead of forcing the need into a conventional page.

Who owns the page, and when should it be reviewed?

Assign one accountable person or team to maintain the page's accuracy, then set a review checkpoint from known change conditions. Ownership is not the same as doing every task. Digital.gov describes creation, maintenance, updating and removal as parts of content governance, with ownership, subject-matter verification and approvals playing distinct roles. Record contributors, approvers and the relevant product, accessibility, legal, regulatory, data or technical reviewers separately whenever the content requires their judgement.

Set the review date according to volatility, risk, evidence, known releases and publishing commitments rather than applying one quarterly or annual interval to everything. Record a trigger alongside the date where practical, such as a product release or policy change. GOV.UK guidance notes that publishing records can expose update history and overdue reviews, informing decisions to update, fix or retire content. A checkpoint makes future action visible, but scheduling it does not guarantee that maintenance will occur.

What does a completed nine-field brief look like?

A completed brief is concise enough to assess at a glance but specific enough to govern the assignment. It combines the evidence-backed need, content decision and lifecycle commitment in one internal record while preserving the distinction between ownership, verification and approval. The following hypothetical example shows the expected level of detail; it contains no assumptions about traffic, completion rates, conversion or savings, and a real team would replace every premise with evidence from its own context.

For a proposed integration-support page, the intended audience is customer administrators preparing to configure a supported integration. Their question is ‘What must I confirm before configuration?’ The page role is a prerequisite explainer before the configuration tool, and the key message is to confirm access, compatibility and required records before starting. Required evidence comprises current product documentation, support records showing the question and verification by the responsible product specialist. The desired action is to decide whether the organisation is ready and proceed to the correct tool or support route.

The format is concise guidance with a prerequisite checklist. The accountable owner is the product-support content team, with named product and accessibility reviewers recorded separately. The review date is the next scheduled checkpoint tied to a documented product-release trigger. These entries hold together because the audience, question, message and proof lead to a distinct preparatory role, while the action and format preserve the configuration tool's separate purpose.

• Is there evidence for the intended audience and user question?
• Does the selected decision follow from the existing-content check?
• Is the page role distinct within the wider journey?
• Are the key message and required proof explicit?
• Is the desired audience outcome meaningful and assessable?
• Can the team justify the chosen format?
• Are an accountable owner, relevant reviewers, a review trigger and a date recorded?

Approve the writing assignment only when those answers form a coherent record. If a material answer remains unsupported, return the request for research or revision before commissioning the draft. Bring in qualified accessibility, legal, regulatory, technical, data or subject-matter professionals whenever claims or implementation decisions require their judgement. The accountable content owner coordinates that work and keeps the lifecycle commitment visible, but does not replace the specialists responsible for it.