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

Before anyone drafts, complete 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 existing website and wider journey before approving it. The outcome may be to update, combine, redirect, reject or create, because a stakeholder's suggested title or format is a proposed solution rather than proof that another page is needed. Only turn the request into a writing assignment when its need, distinct contribution and lifecycle commitment hold together.

Why decide the page's purpose before drafting it?

Decide the purpose first so the team can establish a valid need, distinct role, evidence requirements, intended outcome and accountable owner before treating the request as copy production. Otherwise, the writer must infer the audience, question, proof and relationship to existing material while already shaping a draft. That invites a document which answers several loosely connected concerns, satisfies the requested format and still competes with a page that already owns the task.

GOV.UK guidance asks teams to connect published items to valid user needs and record 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 stand in for discovery, user research, accessibility work, fact-checking, technical assessment or approval from an appropriately qualified specialist.

What should the team check before approving another page?

Check the current site and the complete journey for anything that already answers the need or performs the proposed role. Search beyond pages: include tools, transactions, support routes and relevant non-web channels. Review what each asset promises, which evidence it uses, where it sits in the journey and who maintains it. GOV.UK guidance recommends examining existing guidance early, finding suitable updates, locating duplicated or missing task information and removing unnecessary duplication before adding content.

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

Similar pages can leave readers unsure which source is authoritative and make useful information harder to locate. That does not justify mechanical consolidation. A short instruction repeated beside a transaction may help someone continue at the point of need, while two maintained explainers making the same authoritative claim create a different governance problem. Record the reason for the chosen outcome so the later draft is assessed against an explicit content decision.

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 one central evidence-backed question in language those people would recognise. A label such as “all customers” gives the writer no basis for deciding what to explain, omit or assume. One central question may include closely connected subquestions; the practical test is whether the proposed content can resolve a coherent need for the described audience.

GOV.UK user-need guidance calls for identifying likely users, what they are trying to do and the evidence supporting that need. Possible evidence includes analytics, call-centre records, previous research and relevant external data, but each source must be interpreted for the question at hand. Traffic shows that visits occurred; by itself, it does not explain intent. A stakeholder preference, working title or requested video is likewise an input to investigate, not validation.

• Name the audience in relation to the task, situation or prior knowledge.
• Write the question as the audience might express it.
• Note the evidence, its limitations and any assumptions still requiring validation.

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

These three fields define the page's unique contribution, the conclusion it must communicate and the proof required to support it. State the page role as a job within the journey, not as a format: for example, clarify prerequisites before an administrator enters a configuration tool. The explainer prepares the administrator, while the tool handles configuration. GOV.UK service guidance similarly distinguishes guidance from transactional elements and recommends supplying information where people need it.

Write the key message as the essential conclusion the audience should take away, then place its task-relevant substance before supporting detail. Canada's official content style guide recommends leading with the most important idea, step or information and removing detail that does not help the intended audience's main task. Required evidence has two sides: proof that the page need exists, and the sources, records, data, demonstrations or specialist verification needed to substantiate what the published page will say.

• Test whether another page, tool, transaction or channel can perform the proposed role better.
• Test the eventual title, main heading and opening against the key message.
• Identify every material claim that requires a current source or qualified review.

WCAG 2.4.2 requires page titles that describe topic or purpose, and W3C explains that descriptive titles help people identify pages, judge relevance and distinguish one page from another. A clear title is therefore one useful test of whether the internal purpose survived publication. It does not, on its own, demonstrate that the page is accessible, accurate or necessary; those questions require their own evidence and checks.

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. The action is not automatically a sale, lead or form submission. Treating it as an acceptance condition is a practical synthesis of action-centred user needs and acceptance criteria: it gives reviewers a concrete question to ask without pretending that completion of the brief guarantees the outcome.

Choose guidance, comparison, reference, explainer, transaction step, tool, video or another form only after the need, audience and page role are clear. GOV.UK planning guidance connects content type and placement to audience knowledge, the user task and how people will complete it. Its service guidance also separates the jobs of guidance and transactions. These principles inform the decision, but they do not create a universal taxonomy for every organisation-owned website.

1. State the audience outcome without naming a format.
2. Locate that outcome within the wider journey.
3. Compare the available page, tool, transaction and channel options.
4. Record why the selected form is the most coherent choice.

If a transaction change, interactive tool or non-web support route performs the job better, say so in the decision record instead of forcing the need into a new page. Conversely, do not move explanatory material into an interaction merely because the interaction is the next step. The role, action and format should make sense together, with necessary information available at the point where the audience can use it.

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

Assign one accountable person or team to maintain the page's accuracy, then record specialist contributions and approvals separately. Ownership is not a promise that one individual will perform every duty. Digital.gov describes content governance as covering creation, maintenance, updating and removal, with ownership, subject-matter verification and approvals as distinct lifecycle concerns. Name accessibility, legal, regulatory, technical or data reviewers when the proposed content requires their judgement, and make the owner responsible for coordinating rather than replacing them.

Set the next review from known changes, volatility, risk, evidence and publishing commitments rather than imposing one universal quarterly or annual interval. Record the trigger beside the date when practical: a product release, policy change, contract renewal or source-data update gives the checkpoint context. GOV.UK guidance says publishing records can expose update history and overdue scheduled reviews, informing later decisions to update, fix or retire content.

• Owner: accountable for accuracy and ongoing maintenance.
• Contributors: supply content, evidence or implementation.
• Reviewers and approvers: exercise the specialist or organisational authority their role requires.
• Review checkpoint: prompts a decision but does not guarantee that maintenance will happen.

A high-volatility support page may warrant a checkpoint tied to every relevant release, while a stable reference may be reviewed against a different trigger and risk profile. That is an operational recommendation, not a cadence prescribed by the cited sources. The useful commitment is specific enough to schedule and accountable enough to act upon, while remaining proportionate to the content's actual change conditions.

What does a completed nine-field brief look like?

A completed brief is concise enough to inspect as one decision record yet specific enough to expose unsupported assumptions before drafting begins. The following hypothetical example concerns a B2B support page for customer administrators preparing to configure a supported integration. It makes no claims about traffic, completion, conversion or savings; a real team would replace its assumptions with evidence from its own website, support operation and product context.

• Intended audience: customer administrators preparing to configure a supported integration.
• User question: “What must I confirm before configuration?”
• Page role: a prerequisite explainer immediately 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 reach 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 brief only if stakeholders can show evidence for the audience and question, explain why the selected outcome 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. Keep evidence of need, format decisions, ownership, specialist verification, approval and future maintenance distinct rather than treating one sign-off as proof of them all.

If a material answer remains unsupported or incoherent, return the request for research or revision before assigning the draft. Bring in qualified accessibility, legal, regulatory, technical, data or subject-matter professionals wherever claims or implementation decisions require their judgement. The accountable content owner coordinates that work but does not replace it. A sound assignment begins when the need, decision, nine fields and lifecycle commitment form one defensible contract.