Choose a Baseline Before Redesigning a Booking Form

Record the form version, entry pages, steps, key messages and relevant linked information. Keep screenshots or other appropriate references so later reviewers understand the baseline experience. A redesign comparison becomes difficult when the original has disappeared and the team relies on memory of what the customer previously saw.

Ask which customer task the form supports and what happens after submission. Identify staff review, eligibility checks and confirmation where relevant. Do not let the word booking imply a state the process does not provide. The baseline needs an operational definition that the website team and service owner both understand.

Choose what evidence indicates a genuine attempt to perform the task. A landing-page visit may be informative without representing a start. A first interaction, opening a task-specific step or another event may suit the actual journey, but the choice needs technical and service review. Document the definition and its limitations.

Check alternative entry routes. Customers may follow a saved link, arrive from an advertisement or use a returning-customer path. Decide which routes belong in the baseline and explain exclusions. Avoid collecting a denominator from one part of the journey and a completion count from several others without recognizing the mismatch.

Identify what the customer has achieved when the form ends and what the system records. Separate a submitted request, accepted data and confirmed appointment where those differ. Ask the technical owner to verify the actual state rather than inferring it from a friendly success message. Record any subsequent manual process relevant to the intended outcome.

[GOV.UK's completion-rate guidance](https://www.gov.uk/service-manual/measuring-success/measuring-completion-rate) emphasizes defined starts and completions and the relationship between them. Apply suitable definitions to your commercial service while keeping its actual purpose clear. Do not import a government transaction definition without checking whether it describes the booking task your customers are trying to complete.

Run appropriate test cases and compare the customer view with recorded events. Check successful submission, validation errors and relevant return visits. Mark tests so they can be handled according to the measurement plan. A dashboard displaying a metric does not establish that the event fires once, at the right step or only for the intended task.

Ask the technical owner about duplicate events, blocked tracking and other known limitations. Document what the evidence can show. Do not claim perfect visibility into every user when the setup does not provide it. The baseline can still be useful if its boundaries are understood and the same definitions remain available for later comparison.

Define treatment of internal tests, automated traffic, duplicates, ineligible users and unresolved cases through the appropriate process. Preserve relevant distinctions. An eligibility result can be a completed useful task even when it does not produce a booking, depending on the service purpose. Do not label every non-booking outcome a failed user experience automatically.

Keep rules stable and record changes. Selecting exclusions after seeing unfavorable results can distort the baseline. Where evidence is incomplete, show the uncertainty rather than forcing a definite classification. A reviewer should be able to trace why a case or event was included without relying on an analyst's private judgment.

Select an observation period that reflects relevant working and demand patterns, noting its limits. Record campaigns, closures, outages, service changes and staffing conditions. A short unusual week may not support a broad conclusion about the normal form. If no representative period exists, describe the available evidence honestly and plan a cautious comparison.

Avoid choosing the baseline window solely because it makes the redesign likely to look better. Record the selection reason before evaluating the new result where practical. The purpose is an informative starting point, not a performance target manufactured through selective dates. Keep the evidence available for another reviewer to assess.

Identify how customers receive help or complete the task through another route. A person may begin online and call because they cannot answer a question. That contact can reveal a useful form problem even when analytics only show an abandoned session. Record appropriate evidence without unnecessarily copying private conversations.

Keep assisted completion and channel switching distinguishable where they matter. Do not imply the form independently supported every completed task if staff supplied substantial help. Conversely, do not treat use of legitimate assistance as a customer failure. The redesign question should consider the service as people experience it, including the support needed to reach the outcome.

Combine event patterns with relevant customer questions, error reports and task observations. A drop between steps does not explain its cause by itself. Customers may discover ineligibility, pause to gather information or encounter a technical problem. Investigate the important possibilities rather than rewriting whichever screen has the largest apparent decline.

Check language, requirements and preparation. If the form requests details customers do not reasonably know, a visual redesign may leave the problem intact. Keep service decisions with their owners and identify what can be clarified in content. Before customers plan a visit or journey, the task should explain whether an appointment is actually agreed.

Use a compact record: journey version, task definition, events, evidence source, period, exclusions, context and observed issues. Add owners and unresolved questions. Keep any figures linked to the underlying definitions. An impressive chart without those details can become impossible to interpret after the tracking setup changes.

Store the worksheet where the design and service teams can use it. Follow appropriate access and retention arrangements. A baseline should support review without becoming another uncontrolled repository of personal information. The working record can use controlled references and generalized observations while preserving enough traceability to verify important findings.

Imagine a visit-request form whose success page says a request was received. The team initially labels its dashboard metric confirmed bookings. Review establishes that staff later confirm suitability and timing. The baseline is corrected to distinguish form submission from appointment confirmation, with the subsequent workflow recorded separately.

Customer observations also show uncertainty about a required equipment identifier. The redesign hypothesis addresses that preparation and help, while technical checks preserve comparable submission events. This fictional example illustrates how a baseline can improve the question being measured. It supplies no conversion rate or claim that the eventual redesign succeeds.

Choose specific hypotheses supported by the baseline, such as clearer eligibility guidance or a corrected error path. Record what should improve and what evidence will be checked. Avoid changing every aspect at once if the business needs to understand particular causes. Keep technical or commercial changes visible when they are necessary.

Research website providers with the task definitions and verified issues. If ongoing analysis needs capacity, define the responsibility before exploring service-analysis roles. A designer needs more than an instruction to increase conversions; the baseline should show which customer decision or obstacle the work is intended to address.

Ask the technical and service owners how the current journey handles a person who leaves to gather information and returns later. The measurement may count a new session, preserve an earlier attempt or lose the connection. Record what is actually known. A pause should not automatically be interpreted as permanent abandonment if the evidence cannot distinguish those situations.

Test relevant back navigation and repeated submission paths through authorized cases. A customer correcting a validation error may create several events for one attempt, while another may complete through a different route. These details matter when defining the baseline's denominator. Keep the explanation proportionate, but ensure the later redesign comparison uses equivalent meanings rather than treating a change in event behavior as a change in customer success.

Plan how the new journey's events map to the baseline and which differences prevent direct comparison. Ask the technical owner to verify measurement after changes. Keep the original version, configuration references and a correction plan so misleading or broken behavior can be addressed promptly. Do not assume a redesigned page remains measurable simply because the dashboard still loads.

Review later outcomes with traffic, support and service context visible. Describe specific verified fixes even when broader performance evidence remains uncertain. The practical result is a trustworthy starting record that lets the business assess a redesigned booking task without confusing a prettier interface, a changed metric definition and a genuinely better customer outcome.