A measurement plan before redesigning a website
A measurement plan defines the problem, intended improvement, observable events and commercial review before a redesign begins.
AI-assisted practical guide · Editorial approach
The useful starting point
A measurement plan defines the problem, intended improvement, observable events and commercial review before a redesign begins. Capture the current journey and known gaps first. Otherwise the team may launch a new visual system without a way to assess whether it helped the intended task.
Understand the decision
Choose one or two priority journeys and a meaningful outcome for each. Record what current analytics can and cannot show. Include receiving-team observations and consent-related gaps. Write the hypothesis behind the change, then identify other changes that might affect comparison, such as a new campaign or a different offer.
A practical approach
Define each event and business state before implementing tracking. Distinguish page visits, contact clicks, form attempts, accepted enquiries and qualified opportunities. Match reports to these definitions. Test whether an interruption or retry creates duplicate events. Collect only the information needed for the agreed measurement purpose; contact details and free-text enquiry content should not be copied into general analytics events.
- Name the problem and intended behaviour.
- Document current data limitations.
- Choose a source of truth for the outcome.
- Record concurrent changes before comparison.
Illustrative example
A manufacturer redesigning its quotation page could measure accepted requests and missing specification information. It would also ask sales whether the handoff is clearer. An increase in general page views would be secondary because it does not answer the project's main question.
A mistake to avoid
Avoid choosing success metrics only after seeing the result. A written plan prevents attractive but irrelevant numbers from replacing the original objective.
What to review
Review the planned outcome, usability evidence and receiving quality, with caveats for small samples and changes outside the redesign.
Turn the guide into a working brief
Write a measurement dictionary containing event names, trigger conditions, exclusions, owners and known gaps. Compare the analytics report with the receiving system for the same period and document differences rather than forcing the numbers to match. Use small experiments with a written hypothesis and one primary decision. Report uncertainty, missing consent and unavailable data plainly so the team does not mistake a partial view for complete attribution.
Common questions
What should I prepare before asking for help?
Start with this checklist: Name the problem and intended behaviour. Document current data limitations. Choose a source of truth for the outcome. Record concurrent changes before comparison. Add your business context, existing materials and the decision you need to make. A useful initial brief can include uncertainty; you do not need to invent answers before discussing scope.
How should I judge whether the work helped?
Review the planned outcome, usability evidence and receiving quality, with caveats for small samples and changes outside the redesign. Keep the observation period and definitions visible. Use the responsible team's evidence alongside the website journey; do not attribute every change in results to one asset or article.
Sources & scope
AI-assisted practical guide. Examples are illustrative; business-specific facts and sector claims need the responsible owner’s approval.
- W3C WAI: Forms Tutorial
Reference for accessible labels, instructions and feedback. Original business examples are illustrative, not research findings or verified client results.
Use this guide to start your brief.
Share your business context, existing materials and what is still unclear. The guide title will be included so the conversation starts with the right problem.
Prefer email? Send a brief with this guide’s context.