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

Before anyone drafts a new or substantially revised website page, 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. Check the proposal against the existing site and wider journey, then approve one of five outcomes: update, combine, redirect, reject, or create. A stakeholder's title, preferred format, or deadline can start the discussion, but it does not settle the page decision.

Why decide the page's purpose before drafting?

Decide the purpose first because a writing assignment is only sound when the team can explain the need, the page's distinct role, the evidence required, the intended outcome, and responsibility for its lifecycle. Official GOV.UK guidance says published content should meet a valid user need and that planning records should identify likely users, what they are trying to do, supporting evidence, and acceptance criteria. A requested title or format is a proposed solution, not evidence that another page is warranted.

Without that decision, the writer must infer whom the page serves, which question it resolves, how it relates to existing material, and what proof belongs in the copy. Those guesses can pull a draft in several directions or produce another page competing with an established answer. The nine-field brief is a practical editorial synthesis of user-need, planning, and lifecycle guidance, not an official standard. It gives stakeholders explicit conditions against which they can assess the eventual draft.

What should the team check before approving another page?

Check the current site and the complete user journey before approving another page. Search for pages, tools, transactions, support material, and other channels that already address the same need or perform the proposed role. GOV.UK guidance advises reviewing existing guidance early, finding material that can be updated, identifying duplication and missing task information, and removing unnecessary duplication before adding content. Similar pages can make the authoritative source unclear and needed information harder to locate.

• Update an existing page when it already owns the need and role but its content is incomplete, stale, or poorly structured.
• Combine pages when fragments split one coherent answer or create competing versions of the same guidance.
• Redirect or retire an obsolete page when another destination has become authoritative.
• Reject the request when evidence does not establish a valid need or a distinct page role.
• Create a page only when the need, role, evidence, outcome, format, owner, and review plan form a coherent proposal.

Apply these outcomes with judgment rather than mechanically reducing page counts. Limited repetition at the exact point of need can help someone complete a transaction, while a separate explainer may be justified when it performs a distinct preparatory job. Conversely, a tool adjustment, transaction change, or non-web channel may resolve the need better than prose. The purpose of the check is to choose an authoritative and useful response, not to force every request into either publication or consolidation.

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

WebChorus Editorial Team

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 one central evidence-backed question or task in language those people would recognize. “All customers” is too broad to guide scope, terminology, or depth. A useful audience description might distinguish administrators preparing for configuration from evaluators comparing options, because those situations require different evidence and different next steps. Canada's official content style guide likewise centres content on its intended audience and main task.

Evidence can come from several places. GOV.UK guidance identifies analytics, call-centre information, prior research, and relevant external data as possible inputs while requiring assumptions to be validated. Treat each input according to what it can actually show: traffic can reveal that a page was visited, but not necessarily why someone arrived or whether the proposed content would resolve the need. Interview findings, support records, search terms, and journey research can add context when they are relevant and methodologically sound.

• Write a coherent central question, allowing closely connected subquestions when they belong to the same task.
• Separate evidence of audience need from internal enthusiasm for a topic.
• Do not treat a working title, requested video, or stakeholder preference as proof that the need exists.
• Record important uncertainty so the team knows what must be researched before approval.

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 needed to support that conclusion. For page role, describe what this page does in the journey and why an existing page, transaction, tool, or other channel cannot perform that job better. Guidance and transactional elements perform different functions, and official service guidance recommends supplying information where people need it. A role should therefore describe a journey contribution, not merely repeat a content type.

For key message, write the essential conclusion the audience should retain, then plan to lead with its task-relevant substance. Canada's content style guide recommends placing the most important idea, step, or information first and removing details that do not support the main task. For required evidence, record both kinds of proof: evidence that the page need exists and authoritative material needed to substantiate its eventual claims. That may include current records, source data, demonstrations, product documentation, or verification by an appropriate specialist.

Consider a support explainer placed before a configuration tool. Its role may be to clarify access, compatibility, and documentation prerequisites; the tool, not the explainer, performs the configuration. The key message tells administrators what they must confirm before starting, while the evidence field identifies the product records and expert verification needed to support that advice. When published, test the title, main heading, and opening against the brief. WCAG 2.4.2 requires page titles that describe topic or purpose, although a good title alone does not 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 a format capable of supporting that outcome. This action serves as a practical acceptance condition: it describes what success would look like for the content without assuming that success means a lead, sale, or form submission. For an evaluation page, the meaningful outcome might be a defensible comparison; for support content, it might be reaching the correct tool with the required information ready.

Choose the format only after the need and role are clear. GOV.UK planning guidance connects content type and placement to audience knowledge, the user task, and how that task will be completed. The appropriate form could be guidance, a comparison, a reference, an explainer, a transaction step, a tool, a video, or something else justified by the context. The sources establish this decision principle, not a universal taxonomy for business websites, so the brief should record why the selected form fits.

• Use guidance when people need explanation or preparation.
• Use a comparison when they must evaluate meaningful differences.
• Use reference content when accurate retrieval is the primary job.
• Use an interaction when branching, calculation, input, or task completion is central.
• Use video only when motion, sequence, or demonstration materially helps.
• Recommend a different channel when a web page would not perform the job well.

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. Digital.gov describes content governance as extending through creation, maintenance, updating, and removal, with ownership, subject-matter verification, and approvals as distinct parts of the lifecycle. The owner coordinates that system; the role does not make one editor solely responsible for accessibility assessment, legal or regulatory judgment, technical implementation, data interpretation, or subject-matter approval.

Set the review date from real change conditions rather than imposing one universal interval. Consider known releases, policy or product changes, content volatility, consequence of error, available evidence, and organizational publishing commitments. Record the expected trigger beside the date when practical. GOV.UK guidance notes that publishing records can show when content was last updated and whether it is overdue for scheduled review, enabling teams to decide whether outdated material should be updated, fixed, or retired.

• Name the accountable owner for accuracy and maintenance.
• Identify contributors who supply information or draft material.
• Record subject-matter, accessibility, legal, regulatory, data, or technical reviewers when required.
• Separate approval authority from editorial contribution where the workflow requires it.
• Treat the checkpoint as a prompt for a decision, not a guarantee that maintenance will occur.

What does a completed nine-field brief look like?

A completed brief is compact enough to review in one sitting but specific enough to support a real decision. Consider a hypothetical B2B support request for customer administrators preparing to configure a supported integration. The example below contains no claims about traffic, completion, conversion, cost, or performance. A real organization would replace its assumptions with evidence from its own support records, product documentation, research, governance model, and publishing environment before approving production.

• 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 demonstrating the question, and verification by the responsible product specialist.
• Desired action: decide whether the organization 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 assigning the draft, ask whether 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. The approval test deliberately keeps evidence, format, ownership, verification, approval, and maintenance separate. If a material answer remains unsupported or incoherent, return the request for research or revision.

Approve production only when the need, decision, nine fields, and lifecycle commitment hold together. The brief remains a decision tool rather than a substitute for discovery, user research, accessibility work, fact-checking, technical assessment, or professional judgment. Bring in qualified accessibility, legal, regulatory, technical, data, or subject-matter specialists whenever the proposed content contains claims or implementation decisions requiring their expertise. The accountable content owner coordinates those contributions without replacing them.