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

Before anyone drafts, complete and approve a one-page decision record covering 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 website and the wider customer journey first. The result may be to update, combine, redirect, reject or create. A stakeholder's preferred title or format begins the discussion; it does not, by itself, establish that another page is warranted.

Why decide the page's purpose before drafting it?

Decide the purpose first because a writer needs a valid need, a distinct journey role, evidence requirements, an intended outcome and lifecycle responsibility before a request becomes a sound assignment. GOV.UK publishing guidance similarly starts with likely users, what they are trying to do, supporting evidence and acceptance criteria. Without those decisions, the writer must infer the audience, question and relationship to existing material, leaving ample room for unfocused copy or a page that competes with an established answer.

The nine fields below are a practical editorial synthesis, not an official standard prescribed by the cited guidance. They bring user-need, planning and lifecycle principles into one reusable record that stakeholders can assess before production. The record gives a later draft explicit acceptance conditions, but it cannot replace discovery, user research, accessibility work, fact-checking, technical assessment or specialist approval. Those activities remain necessary wherever the content and its risk require them.

Use the completed brief as a decision record, not as a miniature draft. It should settle what the page must accomplish and what proof it requires while leaving the writer room to shape language and structure responsibly. If stakeholders cannot agree the audience, evidence or next outcome, polished prose will not resolve the underlying uncertainty. Return the request for research or revision before commissioning copy.

What should the team check before approving another page?

Check the current site and the surrounding journey for anything that already addresses the need or performs the proposed role. Search pages, tools, transactions and relevant service channels; follow likely navigation and search routes; and note where ownership already sits. GOV.UK guidance advises reviewing existing material early, identifying suitable updates, finding duplication and missing task information, and removing unnecessary duplication. Similar pages can otherwise make the authoritative source unclear and the needed answer harder to locate.

• Update when an existing page already owns the need and role but its content is incomplete or outdated.
• Combine when fragments split one coherent answer or create competing versions of truth.
• Redirect or retire when an obsolete page should yield to a clearly authoritative destination.
• Reject when evidence does not establish a valid need or distinct page role.
• Create only when the need, role, evidence, action, format, owner and review plan form a coherent proposal.

Do not apply consolidation mechanically. Limited repetition at the point of need may help someone complete a transaction, while merging every related item could remove useful context. The real test is whether each item has a defensible job and whether people can tell where the authoritative answer lives. A tool, transaction change or non-web service channel may also meet the need better than an explanatory page.

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 that audience would recognise. Avoid labels such as all customers or everyone; they conceal meaningful differences. One central question may include closely connected subquestions, provided the proposed page can resolve a coherent need. Official guidance likewise calls for identifying likely users, their task and the evidence supporting it, while audience-centred style guidance focuses content on the main task.

• Use analytics to identify patterns, not to infer intent from traffic alone.
• Examine call-centre records and support enquiries for recurring language and obstacles.
• Use previous research and relevant external data where they address the actual question.
• Validate assumptions through proportionate research rather than treating stakeholder preference as proof.

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

These three fields define the page's unique contribution, its essential conclusion and the proof needed to support that conclusion. State the role as a job within the journey, including why an existing page, tool, transaction or other channel cannot do it better. Write the key message as the conclusion the audience must retain and place its task-relevant substance before supporting detail. Required evidence must cover both the existence of the need and the records, data, demonstrations, reliable sources or expert verification required for the claims eventually published.

• Example role: explain prerequisites before a customer administrator enters a configuration tool.
• Example message: confirm access, compatibility and required records before beginning configuration.
• Evidence needed: current product documentation, support records demonstrating the question and verification by the responsible product specialist.
• Boundary: the explainer clarifies readiness; the tool performs the configuration.

The published page must then communicate the settled purpose clearly. Test its title, main heading and opening against the brief: can someone identify the topic, understand the page's job and judge whether it is relevant? WCAG 2.4.2 requires page titles that describe topic or purpose, and W3C notes that descriptive titles help people identify and distinguish pages. Passing this focused check does not, on its own, establish complete accessibility.

How should the desired action determine the content format?

Define the desired action as what the audience should be able to decide, do, locate, compare, understand or reach next, then choose the format that best enables that outcome. Treating this action as an acceptance condition is a practical synthesis of action-centred user needs and acceptance criteria. It need not be a lead, sale or form submission. A person who can make an informed decision, find the correct document or continue a task may have achieved the page's intended outcome.

• Use guidance to explain a task or decision.
• Use a comparison when people must assess meaningful alternatives.
• Use reference content when accurate lookup is the central need.
• Use a transaction step or tool when interaction, routing or calculation performs the real job.
• Use video only when the medium is justified by the need, accessibility plan and journey context.

Planning guidance connects content type and placement to audience knowledge, the task and how people will complete it. Service guidance also distinguishes the work performed by guidance and transactions and recommends supplying information at the point of need. These principles do not create a universal taxonomy for business websites. If a transaction change, tool or non-web channel performs the job better, record that decision instead of forcing the need into a new page.

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

Assign one accountable person or team to own the page's accuracy and maintenance, while recording contributors, reviewers and approvers separately. Content governance spans creation, maintenance, updating and removal; ownership, subject-matter verification and approval are distinct parts of that lifecycle. The owner coordinates the work but does not absorb every specialist duty. Name accessibility, legal, regulatory, technical, data or subject-matter reviewers whenever the content requires their judgement.

• Name the accountable owner in a role that can maintain the page, not merely sponsor its launch.
• Record specialist verification and approval responsibilities separately.
• Choose the next review date from known changes, volatility, risk, evidence and publishing commitments.
• Add the relevant trigger, such as a documented product release, when practical.

Do not impose one quarterly, annual or other universal interval. Risk- and trigger-based timing is an operational recommendation derived from lifecycle ownership and scheduled-review guidance, not a cadence prescribed by the sources. Publishing records can show when content was last updated or has become overdue for review, supporting a later decision to update, fix, consolidate, redirect or retire it. A checkpoint creates accountability for that decision; it cannot guarantee that maintenance will happen.

What does a completed nine-field brief look like?

A completed brief should read as a compact, evidence-aware production contract rather than a speculative outline. The following hypothetical example concerns a B2B support page for customer administrators preparing to configure a supported integration. It makes no claim about traffic, completion, conversion or savings. A real organisation would need to replace every assumption with evidence from its own customers, products, service records and governance arrangements.

• Intended audience: customer administrators preparing to configure a supported integration.
• User question: What must I confirm before configuration?
• Page role: a prerequisite explainer placed before the configuration tool.
• Key message: confirm access, compatibility and required records before starting.
• Required evidence: current product documentation, support records showing the question and verification by the responsible product specialist.
• Desired action: decide whether the organisation is ready, then proceed to the correct tool or support route.
• Format: concise guidance with a prerequisite checklist.
• Owner: the product-support content team, with named product and accessibility reviewers.
• Review date: the next scheduled checkpoint tied to a documented product-release trigger.

This brief holds together because the audience situation, question, role and next outcome describe one coherent journey. It also keeps important responsibilities distinct: support records help establish the need, product documentation substantiates the guidance, a specialist verifies accuracy, accessibility review remains separate and the content team owns maintenance. The example is reusable as a pattern, but its conclusions are not evidence for another organisation's page.

1. Confirm that credible evidence supports the audience and central question.
2. Explain why the update, combine, redirect, reject or create decision is appropriate.
3. Show that the page role is distinct and the key message can be substantiated.
4. Describe a meaningful next outcome and justify the chosen format.
5. Name an accountable owner, necessary reviewers, a review date and a relevant trigger.

Approve the writing assignment only when those answers form a coherent decision record. If a material answer remains unsupported, contradictory or dependent on unresolved specialist judgement, return the request for research or revision. Bring in qualified accessibility, legal, regulatory, technical, data or subject-matter professionals whenever claims or implementation decisions require them. The accountable content owner coordinates that assurance; ownership never substitutes for specialist competence.