web, macbook, air, apple, graphics, design, icons, technical assistance, web design, logo, website, bar, work, template, male, web design, website, website, website, website, website
Photo by CyberRabbit on Pixabay

Strategy

Part of Web design agencies strategy: an evidence-led brief

A website planning template in three parts, from decision header to control log

A blank planning template for an England website project, covering user tasks, evidence, acceptance, risk gates, change, incidents and exit.

Copy this blank record into the buyer's controlled workspace. Do not fill gaps with agency assumptions. Its subject is a client's website or digital service, not the channels used to market an agency.

What to take away

  • A blank website planning record should be copied into the buyer's controlled workspace, not filled with agency assumptions.
  • The decision header starts with evidence from actual or likely users, not stakeholder opinion.
  • The delivery record needs an owner, source, date, approval state and evidence location for each line.
  • A design approval does not validate the fact being presented in a commercial claim.
  • At each review select proceed, hold, stop or return to an earlier decision.

Decision header

Field / Blank entry

Buyer problem and evidence date
[ ]
User task, trigger and intended outcome
[ ]
England population and any UK-wide boundary
[ ]
Decision owner and review date
[ ]
Options, including do nothing and limited repair
[ ]
Service boundary and explicit exclusions
[ ]
Unknowns and assumptions to test
[ ]
Acceptance evidence and stop condition
[ ]

Start with evidence from actual or likely users. GDS guidance on learning user needs distinguishes researched needs from stakeholder opinion. Government methods are not compulsory for every private organisation, but the evidence boundary is valuable.

Decision header fields to complete

  • Buyer problem and evidence date
  • User task, trigger and intended outcome
  • England population and UK-wide boundary
  • Decision owner and review date
  • Options including do nothing
  • Service boundary and exclusions
  • Unknowns and assumptions to test

Delivery record

Complete each line with an owner, source, due or review date, approval state and evidence location.

  • Eligible buyers and users:population, inclusion, exclusion, access needs and research gap: [ ]
  • Objective:observable change sought, baseline definition and measurement plan: [ ]
  • Content:inventory, factual owner, review cycle, migration and archive: [ ]
  • Accessibility and equality:applicable basis, component criteria, manual and user tests, unresolved barriers: [ ]
  • Privacy and PECR:purposes, data items, roles, lawful basis, storage or access technologies, marketing channels, retention and rights: [ ]
  • Security:threat owner, privileged access, repository, dependencies, build, deployment, logging, incident and recovery evidence: [ ]
  • IP and licensing:asset, creator, owner, licence or assignment, third-party restriction and exit delivery: [ ]
  • Advertising and consumer claims:exact wording, substantiation, qualification, pricing presentation, sector review and expiry: [ ]
  • Platform and hosting:legal entity, edition, region, availability commitment, support, export, deletion and replacement route: [ ]
  • People:employee, worker or contractor facts, responsibilities, access and handover: [ ]
  • Procurement and contract:parties, scope, acceptance, change, subcontractors, liability, termination and continuity: [ ]
  • Finance and tax:currency, VAT treatment, unit, period, one-off and recurring cost, internal labour, contingency and authority: [ ]

The ICO's storage and access guidance should inform the technology inventory, but a label such as "analytics" does not decide the applicable rule. Qualified review must examine the actual operation and purpose.

Add a content and claims schedule rather than leaving those matters inside general scope. For each page, enter its audience, user task, factual owner, source, last review, next review, regulated-sector dependency and withdrawal route. For each objective commercial claim, retain the exact words, evidence file, qualification, placement and expiry. A design approval does not validate the fact being presented.

The platform line also needs a versioned dependency list. Name the hosting plan, content-management edition, plug-ins, fonts, analytics configuration, form processor and any external scripts only after their records have been checked. Enter who can update, disable, export and replace each dependency. Leave an unknown field open where the contractual or technical answer has not been obtained.

Acceptance and control log

For every deliverable, record:

Acceptance and control log entries

  • Test artefact, population and environment
  • Expected result and pass or fail evidence
  • Tester independent of maker
  • Open defects and acceptance authority
  • Change request and revised evidence
  • Incident owner and notification route
  • Rollback trigger and restart authority
  • Export, deletion and supplier exit

Control / Blank entry

Test artefact, population and environment
[ ]
Expected result and pass or fail evidence
[ ]
Tester independent of maker where required
[ ]
Open defects, severity and acceptance authority
[ ]
Change request, impact and revised evidence
[ ]
Incident owner, containment and notification route
[ ]
Rollback trigger, recovery point and restart authority
[ ]
Export, deletion, credential transfer and supplier exit
[ ]

The NCSC's secure development guidance covers development through continuing operation and planning for flaws. It is not a security certificate, so attach evidence from the project itself.

For incident planning, write the event that opens an incident, who receives the first report, the containment options, the evidence to preserve and the authority to communicate, restore or remain offline. Do not assume the agency controls every system. Where the buyer, host and another supplier share a journey, record the exact escalation path and contractual clock, if one exists.

At each review select proceed, hold, stop or return to an earlier decision. A hold must identify a safe investigation and an owner. A stop applies when a mandatory gate fails, necessary evidence is unavailable or the task cannot be improved responsibly. This uncompleted template offers no legal, financial or compliance assurance.

Before you act

  • Copy the blank record into the buyer's controlled workspace.
  • Start with evidence from actual or likely users.
  • Add a content and claims schedule for each page.
  • Name each platform dependency only after checking its records.
  • Attach project evidence rather than relying on external guidance.
  • Record the exact escalation path where suppliers share a journey.

Common questions

What should happen if a mandatory gate fails?

A stop applies when a mandatory gate fails, necessary evidence is unavailable or the task cannot be improved responsibly. A hold instead must identify a safe investigation and an owner. At each review the choice is proceed, hold, stop or return to an earlier decision.

How should commercial claims be handled?

Add a content and claims schedule rather than leaving those matters inside general scope. For each objective commercial claim, retain the exact words, evidence file, qualification, placement and expiry. A design approval does not validate the fact being presented.

What does the platform line require?

The platform line needs a versioned dependency list. Name the hosting plan, content-management edition, plug-ins, fonts, analytics configuration, form processor and external scripts only after their records have been checked. Enter who can update, disable, export and replace each dependency, and leave unknown fields open.

More in Strategy