Strategy
Part of Web design agencies strategy: an evidence-led brief
The website planning mistakes that start with a redesign
Seven non-ranked website-planning mistakes for England buyers, each tied to an authoritative record, a practical correction and a stop signal.
What to take away
- A redesign should start with a named user problem, not a visual solution.
- Map the whole service, including offline steps and staff systems, before procurement.
- Define measurable tests and accessibility checks in the brief, not after launch.
- The buyer keeps responsibility for security, tracking and intellectual property evidence.
Method, date and scope
Review date: 6 September 2026.
Scope: decisions about an England organisation's website or digital service. UK-wide law and guidance are labelled by source rather than recast as England statistics.
Inclusions: a failure needed an authoritative source, a practical correction and an observable reason to hold or stop work.
Exclusions: agency anecdotes, market rankings, invented results, prices and platform predictions.
Ranking and conflicts: the seven entries are non-ranked. No agency, supplier or advertiser funded or participated in this desk review.
1. Starting with a redesign
A visual solution arrives before anyone has described the task or evidence of failure. The GDS page on learning user needs says needs should be based on research and framed around the user's problem, not a solution. Correct this by naming the eligible user, trigger, intended outcome and present route. Stop if the buyer cannot show a problem worth addressing.
2. Treating the page as the whole service
The plan ignores telephone help, confirmation, fulfilment, complaints or staff systems. Government discovery guidance asks teams to understand wider journeys and offline interactions. Map every hand-off and owner. Hold procurement when the agency's boundary ends before the user's task does.
3. Accepting adjectives instead of evidence
Terms such as "intuitive" or "effective" cannot produce a pass or fail record. The Service Manual guide to measuring website success combines performance evidence with user research for end-to-end and non-transactional journeys. Define the test population, task, event, period, denominator and defect rule. Do not borrow a universal benchmark.
4. Leaving accessibility until launch
A late audit cannot cheaply repair every decision embedded in content, components and code. GDS front-end accessibility guidance describes component criteria, manual checks and assistive-technology testing, and warns that automated tools miss problems. Put access needs and acceptance checks into the brief. Stop a release with unresolved critical barriers.
5. Calling every tag essential
A commercial preference does not decide whether a storage or access operation is exempt. The ICO's current technology guidance requires a facts-based assessment of purpose and operation. Inventory tags, pixels, local storage and similar functions before build. Hold tracking until the permission and transparency route is reviewed.
6. Assuming the supplier owns security
Outsourcing development does not remove the buyer's need for evidence and incident authority. NCSC secure development principles cover the repository, build pipeline, testing and flaw management, while expressly denying a security guarantee. Name owners for access, findings, containment, rollback and recovery. Stop if critical access or recovery evidence is unavailable.
7. Confusing payment with ownership
Invoices and delivered files do not by themselves settle rights. GOV.UK's IP overview says a self-employed creator usually owns commissioned IP unless the contract provides otherwise. Inventory code, copy, images, fonts and designs, then record ownership, licence scope and exit delivery. Hold acceptance until a qualified IP reviewer resolves gaps.
None of these corrections promises legality or performance. Accessibility, equality, privacy, PECR, security, IP, advertising, consumer, employment, procurement, contract, tax, finance and exit remain separate gates for named reviewers.
Before you act
- Name the eligible user, trigger, outcome and present route.
- Map every hand-off and owner across the full journey.
- Define test population, task, event, period and defect rule.
- Put access needs and acceptance checks into the brief.
- Inventory tags, pixels and local storage before build.
- Record ownership, licence scope and exit delivery for all assets.
Common questions
What should a team do before agreeing to a redesign?
Name the eligible user, trigger, intended outcome and present route. Stop if the buyer cannot show a problem worth addressing. The GDS page on learning user needs says needs should be based on research and framed around the user's problem, not a solution.
How can a team avoid treating the page as the whole service?
Map every hand-off and owner. Government discovery guidance asks teams to understand wider journeys and offline interactions. Hold procurement when the agency's boundary ends before the user's task does. This includes telephone help, confirmation, fulfilment, complaints and staff systems.
What must be defined to measure website success?
Define the test population, task, event, period, denominator and defect rule. The Service Manual guide to measuring website success combines performance evidence with user research for end-to-end and non-transactional journeys. Do not borrow a universal benchmark.
