A website strategy framework in five steps, from decision to control

Use this framework before writing an agency brief. Its subject is the client's website and service decision, not the agency's acquisition campaign. The work starts with a defined buyer problem, a user task and the boundary around that task.

What to take away

1. State the decision

Write: "The named owner will choose whether to [retain, repair, build or commission] by [review date], using [evidence]." Add the England connection, such as the location of the eligible service population or commissioning organisation. Name the regulator behind each item, such as the ICO under PECR, the Equality Act 2010 or Companies House.

A worked example for an England district council reads: the Head of Customer Services will decide by 30 June 2027 whether to repair the council tax support form. The supporting evidence is the 2026 contact log, assisted digital take up and the open incidents list.

The GOV.UK Service Manual says user needs should come from research, while stakeholder opinions remain assumptions. Although intended for government teams, this distinction is useful for a commercial project. Record the observed problem, its source and what would disprove it. "We need a new look" is not enough.

2. Map the complete task

Describe the trigger, steps, intended outcome and alternative route. Include confirmation, staff fulfilment, complaints, correction and exit, not just public pages. Name the system or team responsible at each hand-off.

The government's discovery guidance notes that a digital task may sit inside a wider journey with offline interactions and hard constraints. It also asks teams to consider alternatives to building. Therefore include these options:

Keep a short evidence ledger beside those options, entering author, collection date, eligible population, geography, method, storage location and limitation.

A customer-service note can show one incident occurred, but not how common it is. A supplier presentation is a claimed capability until tied to a contract term or tested artefact. If evidence cannot distinguish two routes, record uncertainty instead of awarding a convenient score.

3. Define acceptance before procurement

For each option, state the artefact, test population, method, expected record and defect rule. Examples include a content owner confirming factual accuracy, relevant users attempting named tasks, a keyboard review of specified journeys, a synthetic form reaching a test queue, and restoration from a controlled backup. These are test types, not evidence that any unnamed site passed.

Fix the thresholds in the brief. A worked example: at least 12 participants drawn from the eligible population, a pass rate of 85 per cent on the named tasks, and no open severity 1 defect at sign-off.

GDS guidance on measuring a website journey recommends combining performance data with user research. Specify event, numerator, denominator, period, time zone, exclusions, data owner and uncertainty rather than inventing a universal success rate.

4. Run independent gates

Create separate verdicts for accessibility and equality, privacy and PECR, security, IP and licensing, advertising claims, consumer or e-commerce rules, people and contractor status, procurement, contract, tax and finance, and exit. A positive design review cannot compensate for a failed gate.

For security, request project evidence across repository access, build, deployment, testing and flaw handling. The NCSC's development principles cover that lifecycle and expressly do not guarantee a secure product.

5. Assign control

Every action needs one owner, evidence location, review date and escalation route. Record who can pause spend, reject a deliverable, roll back a release and authorise restart. Keep an assumption log and a decision log, so a later team can see why work proceeded.

Also define change control before work starts. A new integration, audience, claim or collection purpose can alter cost and several risk gates at once. The change owner should identify affected acceptance tests, source records and reviewers before approving it. If the impact cannot be bounded, return to the service map rather than quietly expanding delivery.

This is a planning aid, not professional advice or a compliance determination. Named UK reviewers must assess the actual service, organisation, contract and data flow before use or publication.

Before you act

Common questions

What should the framework be used for?

Use it before writing an agency brief. Its subject is the client's website and service decision, not the agency's acquisition campaign. The work starts with a defined buyer problem, a user task and the boundary around that task.

How should evidence be recorded?

Keep a short evidence ledger beside the options. For each item, enter its author, collection date, eligible population, geography, method, storage location and limitation. If evidence cannot distinguish two routes, record that uncertainty instead of awarding a convenient score.

When should you choose hold rather than proceed or stop?

Choose proceed only when required evidence exists and every mandatory gate is open. Choose hold for a bounded, safe-to-investigate gap. Choose stop when the problem is unsupported, a constraint defeats the option or recovery is unacceptable.