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. First compare the proposal with the existing website and the wider customer journey. The responsible decision may be to update, combine, redirect, reject or create. Only the last of those outcomes commissions a new page, and only when the need, evidence and lifecycle commitment hold together.

Why settle the page's purpose before drafting?

The team must establish a valid need, a distinct journey role, the proof required, the intended outcome and ongoing responsibility before treating the request as a writing job. A stakeholder's preferred title or format is a proposed solution, not evidence that another page is warranted. Starting with it leaves the writer to infer whom the page serves, which question it answers, what must be proved and how it relates to existing material.

Official GOV.UK guidance says published content should meet a valid user need and records should identify likely users, their task, supporting evidence and acceptance criteria. The template below combines those principles with pre-creation planning and lifecycle governance. It is a practical editorial synthesis, not an official standard, and it cannot substitute for discovery, user research, accessibility work, technical assessment, fact-checking or specialist approval.

What should the team check before approving another page?

The team should search the current site and trace the relevant journey before approving another page. Look for pages, tools, transactions, support material and other channels that already answer the question or perform the proposed job. GOV.UK guidance recommends reviewing existing guidance early, identifying material that can be updated, locating duplication and missing task information, and removing unnecessary duplication before publishing more.

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

Similar pages can make it unclear which source is authoritative and can make needed information harder to locate. That does not mean every related page must be merged mechanically. A short reminder at the point of need may support a transaction without becoming a competing source. The test is whether each piece has a deliberate journey role, or merely repeats content because teams planned it separately.

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 audience by the task, situation or knowledge level that materially changes what the page must do, then state the central evidence-backed question in words those people would recognise. An unbounded label such as “all users” gives the writer no basis for choosing context, terminology or detail. GOV.UK user-need guidance similarly calls for identifying likely users, what they are trying to do and the evidence supporting that need.

Useful evidence may include analytics, call-centre records, previous research and relevant external data, but each source must be interpreted against the question. Traffic alone does not reveal why people visited or whether the page helped. A central question can contain tightly connected subquestions when they form one coherent need. A requested video, working title or stakeholder preference remains a proposed response until evidence validates the underlying need.

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

These three fields define the page's unique contribution, the conclusion it must convey and the proof needed to support it. Page role explains why this page belongs at a particular point in the journey and why an existing page, transaction, tool or channel cannot do the job better. Key message states the essential conclusion. Required evidence covers both proof that the need exists and support for the claims the page will make.

Consider a support explainer that clarifies prerequisites before an administrator enters a configuration tool. The explainer helps the administrator establish readiness; the tool performs the configuration. Official service guidance distinguishes those roles and recommends providing information where users need it. Put the task-relevant message before supporting detail, then test the eventual page title, main heading and opening against the brief. WCAG 2.4.2 separately requires a page title that describes topic or purpose; passing that check alone does not establish complete accessibility.

How should the desired action determine the content format?

Desired action should name what the audience can meaningfully decide, do, locate, compare, understand or reach next, and the format should then serve that outcome. Treat the action as an acceptance condition for the content rather than automatically turning it into a lead, sale or form submission. A useful outcome may simply be deciding that an organisation is not ready to continue, or finding the correct support route.

Choose guidance, comparison, reference, explainer, transaction step, tool, video or another form only after the need and journey role are clear. Planning guidance links type and placement to audience knowledge, the task and how people will complete it, while service guidance distinguishes guidance from transactions. These sources establish the decision principle, not a universal business-site taxonomy. If a tool, transaction change or non-web channel works better, record that decision instead of forcing the need into a 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 specialist duties separately. Contributors, subject-matter reviewers, approvers, accessibility specialists, legal or regulatory reviewers and technical implementers remain responsible for their respective work. The owner coordinates the lifecycle; ownership does not turn that person into every required expert. Digital.gov likewise describes creation, maintenance, updating and removal as governed activities involving ownership, verification and approvals.

Set the next review from known change triggers, volatility, risk, available evidence and publishing commitments, recording the trigger alongside the date where practical. Do not impose a quarterly, annual or other universal interval on every page. GOV.UK guidance shows how publishing records can expose update history and overdue scheduled reviews, supporting later decisions to update, fix or retire content. A checkpoint makes the work visible, but does not guarantee that maintenance will happen.

What does a completed nine-field brief look like?

A completed brief is concise enough to review in one sitting but specific enough to expose weak assumptions before drafting begins. The following hypothetical example concerns a B2B support page. It makes no claims about traffic, completion, conversion or savings; an actual team would replace every assumption with evidence from its own product, customers and operating context.

• 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.

Approve the assignment only if stakeholders can show evidence for the audience and question, explain why the selected decision and page role are distinct, state the key message and required proof, describe a meaningful next outcome, justify the format, name an accountable owner, and commit to a review trigger and date. If a material answer remains unsupported or conflicts with another field, return the request for research or revision before assigning the draft.

The finished record should preserve the distinction between evidence of need, journey and format choices, accountable ownership, verification, approval and future maintenance. 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 but does not replace it. The writing assignment is ready only when the decision, all nine fields and the lifecycle commitment form one defensible proposal.