Pick the journey that matters to the business
For a hypothetical commercial cleaning company, the important task might be requesting a site assessment for an office. Begin with the customer’s constraints: building type, service area, preferred timing and any access requirements. Decide what the website should help them complete before a person from the company takes over.
Document a successful journey in plain language. The visitor identifies a relevant service, understands what an assessment includes, submits the necessary details and receives an accurate confirmation. This gives designers, developers and the sales team a shared goal. It also exposes gaps that a review of the homepage alone would miss.
Inspect information and interaction separately
First review the information: does the site state the area served, property types supported and what happens during the assessment? Then review the controls: can a visitor identify the service selection, contact fields and submission action? Treat these as separate questions because complete information does not guarantee a usable form.
Use actual labels and clear grouping around the controls. W3C guidance supports associating labels with form inputs. In a practical review, record which field caused confusion and what wording would resolve it. Do not reduce the entire journey to a generic accessibility or agent-readiness badge.
Look for differences between views of the page
A browser assistant may work with page structure, accessibility information or visual output. Its route can reveal contradictions. The cleaning form might display a selected service visually while the underlying control still exposes a different value. A decorative element may resemble a button without behaving consistently.
Test the form on the live implementation, not only in a design file. Check the page after loading, after a selection and after an error. Record what actually changes. A screenshot can prove appearance at one moment; it cannot prove that the submitted service choice reaches the team correctly.
Use controlled tests instead of uncontrolled enquiries
Create a test scenario with a clearly identified test name and agreed handling. Avoid generating a stream of real appointment requests while exploring the interface. Where possible, use a test environment or stop before the final external action, then have the team verify the remaining step.
Include one ordinary mistake, such as an incomplete address, and one unsupported case, such as a property outside the service area. The interface should explain how to recover or obtain help. Success means the site handles the whole intended range of the task, including outcomes where the customer should not continue.
Prioritize fixes by customer consequence
Rank findings by what they prevent: understanding eligibility, selecting the correct service, submitting accurate information or knowing what happens next. Fix the most consequential issue first and repeat the same scenario. Keep purely visual preferences separate from observed failures.
A project handoff should include changed pages, test cases, remaining limits and ownership. If an emerging agent integration is proposed, explain which supported environment will use it and how the business will maintain it. The first objective is a reliable service journey that staff can demonstrate and customers can complete with confidence.
Put it to work
- Write the intended service journey and boundaries.
- Review business facts separately from interactive controls.
- Inspect selections and error states after interaction.
- Use controlled records for enquiry tests.
- Repeat the same scenario after fixes.
Sources and further reading
Sources reviewed November 8, 2026. Platform behavior and availability can change. The exercises and examples are our editorial recommendations.