Website Planning Toolkit

01

Website redesign brief

Describe the work, assign owners and list the questions suppliers need to answer.

Organisation and project owner Problem and supporting evidence Priority audiences and tasks Content work and ownership Functionality and integrations Quality and acceptance Constraints and approvals Handover and ongoing ownership

Fictional example: A training organisation needs editors to publish an event once and have it appear in the right listings. Registration remains in its existing booking system. Acceptance includes publishing, filtering and following the correct registration link. A custom booking integration is explicitly out of scope.

Every launch requirement has a testable outcome.
Content responsibilities are separate from design and development.
Unknowns have an owner and a date for resolution.

02

Ask visitors where they would look. Record their choices and where they get stuck.

Count people who reach the answer directly and those who backtrack before succeeding. Record the first wrong turn; a final success count can hide a difficult route.

Visitor task
Content inventory
Grouping and labels
Text-based test
Menu and search design
Retest

Fictional example: a resource organisation
Existing label	Question to investigate	Proposed alternative	Validation task
Capability development	Do visitors recognise this as training?	Training and events	Find the next suitable workshop without being told where to look.
Knowledge exchange	Do visitors expect resources, news or discussion?	Resources and guides	Find the current referral guide.

Audience and taskContent and proposed routeObserved first choice and difficultiesDecision, owner and retest

The task does not reveal the intended menu label.
The destination answers the visitor's question.
Mobile, keyboard, search and empty-result behaviour are checked separately.

03

Migration and redirect map

Example URL map for a fictional website. Copy the columns into your project system and record each test result.

Record the content cut-off and final import. Compare sample records as well as totals. Check HTTP indexing headers on PDFs and pages, including files that return 200.

Old URL	Decision and new destination	Expected response	Observed response / reviewer
/services/advice	Retain at the same URL	200; useful current page	Not tested
/our-training	Move to /training	Permanent redirect; final destination 200	Not tested
/news/expired-test-page	Remove; no relevant replacement	404 or 410	Not tested

Baseline and important URLsURL decisions and content ownersProduction checks and observed resultsLaunch, monitoring and recovery owners

No irrelevant homepage redirects, loops or unintended chains.
Production does not inherit staging access or indexing restrictions.
Important content survives the change, not just the URL.
Monitoring uses comparable periods and a recorded release date.

04

Form review and demonstration

Check instructions, labels, keyboard use, errors and confirmation.

For multi-step forms, check whether earlier answers can be reused. For login or verification, try password managers and pasting the full code. Inspect small targets against WCAG 2.2's size or spacing requirements. See W3C's repeated-entry, authentication and target-size guidance.

Common problem	Better behaviour to inspect
Placeholder used instead of a label	A visible, associated label remains when the field is filled.
Only a red border after failure	A specific message explains the correction and is associated with the field.
All input discarded after an error	Valid information remains while the visitor corrects the problem.
Success animation without a meaningful status	A perceivable confirmation accurately explains what happened.

Try a fictional enquiry

Submit the empty form, then correct the errors using a keyboard. The demo sends nothing.

Labels, required status and instructions are clear.
Keyboard focus is visible and every necessary control is operable.
Error feedback explains a correction and preserves useful input.
Zoom and narrow screens do not hide the task.
Confirmation is perceivable and accurate.
Assistive-technology testing and any formal evaluation have a stated scope.

Page, browser and input methodAction, expected behaviour and observed issueResponsible owner and priorityRetest conditions and result

05

Compare five editing tasks

Use the same content and staff roles in both systems. Record where editors finish independently, need help or get stuck.

Task	WordPress observation	Statamic observation	Required change
Update a landing page and preview it	Not evaluated	Not evaluated	Record after testing
Publish a structured resource	Not evaluated	Not evaluated	Record after testing
Change navigation safely	Not evaluated	Not evaluated	Record after testing
Draft, review and publish with ordinary roles	Not evaluated	Not evaluated	Record after testing
Preview and recover a mistake	Not evaluated	Not evaluated	Record after testing

Versions, extensions and configurationEditor roles and task contentIndependent completion, assistance and blockersDecision, trade-offs and ongoing responsibilities

Ask the supplier to show the proposed revisions and approval setup, including any licence requirements.

Changing shared content on one page produces the intended result on the second page.
An editor can save proposed changes to a published page while its approved version stays live.
The comparison records each implementation's actual settings and permissions.

06

Performance investigation

Record the delay, suspected cause and test conditions. Repeat the test after the change and check that the site still works correctly.

URL, action and symptomTest setup and data sourceEvidence and baseline measurementsHypothesis and smallest proposed changeRepeat measurements and side effectsDecision and next monitoring check

Example hypothesis: “JavaScript inserts the main image late. Put it in the initial page markup and repeat the loading test.”

For PageSpeed Insights field results, record whether the data covers the URL or the origin. Its rolling 28-day period includes experiences before a recent fix. Reporting details.

Our cache URL check: seven sample URLs produced three distinct cache URLs when Statamic's half-measure strategy kept only the size filter. Ignoring all query strings produced one, merging different product views. Download all four configurations and results (Statamic 6.31.0, 21 September 2026; URL handling, not a speed test).

Field data and lab measurements are identified separately.
A lack of field data is reported as unknown.
Correct content, personalisation and integration behaviour are retested.
Failed hypotheses are retained in the record.

07

Website acceptance and sign-off

Record which version was tested, the result and any outstanding fixes.

Journey	Expected outcome	Observed result / evidence
Find a service or resource	Correct content, eligibility and next step	Not tested
Submit an enquiry	Validation, confirmation and correct operational destination	Not tested
Publish as an editor	Permitted changes can be made, previewed and recovered	Not tested
Use a restricted role	Only authorised content and actions are available	Not tested

Release, environment and reviewersTest cases and evidenceDefects, severity and retestAccepted exceptions, owner and due dateRelease decision and authorised ownerProduction checks and recovery contact

Attach the relevant accessibility, performance, security and migration reports.

Multi-step forms are tested for abandonment, verification, retries and delivery failure.
A technical tester checks restricted actions by direct request.
Production checks cover settings that deliberately differ from staging.
A rollback plan preserves enquiries and orders received since launch.

08

Trace a missing enquiry

Use an agreed test identity. Record identifiers and necessary diagnostic information without copying real personal messages into the worksheet.

For a custom Dataverse connection, record status and headers: a successful create can return 204 with the record address in OData-EntityId; a service-protection 429 includes Retry-After. Keep the contact identifier separate from the enquiry identifier. Create responses · Retry guidance.

Browser submission
Accepted request
Storage, if configured
Delivery attempt
CRM record
Assignment and visibility

Form, connection type and test referenceLast confirmed stage and evidenceError, field mapping or permission findingRetry and duplicate-handling behaviourCRM record, assignment and staff visibilityRecovery owner and end-to-end retest

The visitor confirmation matches what the system actually accepted.
Temporary and permanent failures are handled differently.
Repeated delivery does not create an unintended duplicate submission.
An unresolved failure has a visible owner and recovery route.

09

Product finder test matrix

Ask the product specialist to confirm the expected result for each case.

Variant test: a fictional family has a black 18-inch item and a silver 20-inch item. A request for black and 20-inch must not return either as a match. All selected attributes must belong to the same available variant.

Case	Expected behaviour to define	Result
Known valid configuration	Relevant products and understandable guidance	Not tested
Known incompatible combination	Not presented as approved; explanation and recovery	Not tested
Missing compatibility data	Unknown state distinguished from approval	Not tested
Customer changes context	Dependent choices are re-evaluated and resets explained	Not tested
Shared link without session context	Missing information requested before a suitability claim	Not tested
Quote or order handover	The correct configuration and market are retained	Not tested

Data source, expert and representative recordsObserved cases, issues and evidenceImport, update and exception processMobile, keyboard and downstream checks

10

Content ownership and publishing

Name who checks the facts, reviews the copy, publishes changes and maintains the platform.

Before approving a shared record, list the pages that use it. Record publication, modification and review dates separately. When retiring content, choose whether it stays with a notice, redirects to a replacement or is removed.

Responsibility	Decision it owns	Assigned person / backup
Business content owner	Factual accuracy and currency	To assign
Editorial reviewer	Clarity, consistency and presentation	To assign
Publisher	Approved version and publication timing	To assign
Platform owner	Permissions, components, recovery and support	To assign

Content types and accountable ownersChange types and approval routeRole permissions and prohibited actionsReview dates and event-driven triggersApproved version and publication recordUrgent corrections, retirement and recovery

Shared information has one agreed source and owner.
Review dates reflect actual reviews, not automatic date changes.
Ordinary editors can complete their tasks with appropriate permissions.
Recovery and urgent-change processes have been demonstrated.

Website planning toolkit