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

Before anyone starts drafting, complete 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 request with the website's existing pages, tools, transactions and wider customer journey. The responsible outcome may be to update, combine, redirect, reject or create. A stakeholder's suggested title, PDF, video or landing page is only a proposed solution; it is not, by itself, evidence that another page deserves a place on the site.

Why decide the page's purpose before drafting it?

Decide first because a valid need, a distinct journey role, credible evidence, an intended outcome and lifecycle responsibility must exist before a request becomes a writing job. Otherwise, the writer has to infer who the page serves, which question it resolves, what must be proved and how it relates to existing content. GOV.UK guidance similarly connects publishing with a valid user need, likely users, their task, evidence and acceptance criteria. The nine fields below are our practical editorial synthesis of such planning and governance principles, not an official standard. They create a shared basis for judging the eventual draft, but do not replace discovery, user research, accessibility work, fact-checking, technical assessment or specialist approval.

What should the team check before approving another page?

Check whether the website or another channel already meets the same need before approving new content. Search the site using audience language, inspect navigation and internal search results, and trace the relevant journey through guidance, forms, portals, tools, support material and offline service routes. Review which item currently owns the answer, whether important information is fragmented and whether an obsolete URL still competes for attention. GOV.UK guidance recommends reviewing existing material early, updating suitable pages and addressing duplication or missing task information. Similar pages can blur which source is authoritative, although deliberate repetition at the precise point of need may still support a transaction. The audit should therefore lead to one recorded decision:

• 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 page has become the authoritative destination.
• Reject when evidence does not establish a valid need or a distinct page role.
• Create only when the need, role, evidence, action, format, owner and review plan are coherent.

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 express the central evidence-backed question in language those people recognise. ‘All customers’ is too broad; ‘customer administrators checking prerequisites before configuring a supported integration’ gives the team a usable boundary. One central question may include closely connected subquestions when they form a coherent need. Possible evidence includes analytics, call-centre or support records, earlier research and relevant external data, but each source must be interpreted for the question at hand. Traffic can show that visits occurred; it cannot, alone, prove why people came or whether the proposed page is the right response. A working title, executive preference or requested video remains a solution hypothesis until the need is validated.

• Describe what the audience is trying to accomplish and what they already know.
• Record where the question appears in research, support interactions or journey evidence.
• Separate observed evidence from assumptions that still need validation.
• Keep only connected subquestions that the proposed content can resolve coherently.

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 required to sustain that conclusion. State the page role as a journey job, including why an existing page, transaction, tool or other channel cannot perform it better. Then write the key message as the one point the audience must understand, placing its task-relevant substance before supporting detail. Required evidence has two parts: evidence that the need exists, and sources, records, data, demonstrations or expert verification for claims the page will make. For example, a support explainer may clarify prerequisites before an administrator enters a configuration tool; the tool, not the explainer, performs the configuration. Guidance and transactions serve different functions, so their responsibilities should not be blurred.

• Test the eventual page title against the agreed topic and purpose.
• Use the main heading and opening to make the page's relevance apparent.
• Remove detail that does not help the intended audience with its main task.
• Treat this alignment check as one accessibility input, not proof of complete accessibility.

How should the desired action determine the content format?

The desired action should state what the audience can meaningfully decide, do, locate, compare, understand or reach next; the format should then be chosen to support that outcome. Treat the action as an acceptance condition for reviewing content, not automatically as a lead, sale or form submission. Someone may simply need to confirm eligibility, compare two supported options or locate the correct service route. Once that outcome and the page role are clear, consider guidance, comparison, reference, explainer, transaction step, tool, video or another justified form. GOV.UK planning guidance connects content type and placement to audience knowledge, the task and its completion, but it does not provide a universal taxonomy for business websites.

• Use guidance when the audience needs instructions or prerequisites.
• Use a comparison when people need to evaluate defined alternatives.
• Use a reference when accurate retrieval matters more than a linear explanation.
• Choose a tool, transaction change or non-web route when it performs the job better than 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, then record the next review according to its actual change conditions. Ownership is not the same as doing every job. Contributors may draft or supply evidence; subject-matter specialists verify technical claims; approvers accept organisational risk; accessibility specialists examine inclusive use; and legal or regulatory reviewers handle decisions requiring their judgement. Digital.gov describes creation, maintenance, updating and removal as parts of the content lifecycle, with ownership, verification and approvals as distinct responsibilities. The owner coordinates these inputs and ensures decisions are recorded, but does not replace the specialists involved.

• Set timing from known releases, policy changes, evidence expiry, volatility, risk and publishing commitments.
• Record a trigger beside the date when a known event could make the content inaccurate.
• Avoid imposing the same quarterly or annual interval on every page.
• At the checkpoint, decide whether to update, fix, consolidate, redirect or retire the content.

Publishing records can reveal when content was last updated or has become overdue for scheduled review, supporting a later maintenance decision. A checkpoint, however, is only a governance commitment: it does not guarantee that work will happen. Teams still need visible ownership, capacity and an escalation route when a review is missed or specialist evidence is unavailable.

What does a completed nine-field brief look like?

A completed brief should read as a compact, internally coherent decision record rather than a mini-outline or keyword sheet. The following hypothetical B2B support example demonstrates the level of specificity required without claiming any improvement in traffic, completion, conversion or cost. A real team must replace every assumption with evidence from its own products, customers, support records and operating environment.

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

Before approving the assignment, ask whether stakeholders can show evidence for the audience and question, defend the update, combine, redirect, reject or create decision, and explain the page's distinct role. They should also be able to state the key message, identify the proof required, describe a meaningful audience outcome, justify the format, name the accountable owner and commit to a review trigger and date. If a material answer is unsupported or conflicts with another field, return the request for research or revision rather than asking a writer to resolve a governance gap inside the draft.

Approve writing only when the need, decision, nine fields and lifecycle commitment hold together. Bring in qualified accessibility, legal, regulatory, technical, data or subject-matter professionals whenever claims or implementation choices require their judgement. The accountable content owner should coordinate that work and preserve the decision record, not claim expertise that belongs elsewhere.