Audit One Customer Journey Before Redesigning Your Website

A website review can produce a long list of visual preferences without identifying what prevents a customer from completing a task. Start with one journey: finding a service, checking whether it fits, submitting an inquiry, and understanding what happens next.

The output should be an ordered repair list with observable problems, supporting evidence, and clear acceptance checks. This approach preserves the useful parts of user research, interface review, and testing while keeping the work small enough to complete.

Define the task and the review conditions

Consider a hypothetical equipment-hire business. A customer needs to check whether a machine is suitable, request it for a date, and find out whether the request has been accepted. The audit follows that journey from the relevant service page through the request form and confirmation.

Record the device, browser, account state, and connection conditions used. Include the mobile experience and the input methods relevant to customers. Use realistic product names, instructions, and error messages in prototypes rather than placeholder copy.

Write the task without telling the participant where to click. “Find out whether this machine is available next Friday and request it” is useful. “Click Hire, then select Friday” hides navigation problems by giving away the route.

Review clarity, control, and feedback

Jakob Nielsen's ten usability heuristics are broad rules of thumb for interaction design, rather than a certificate that a site is usable. Use them to organize questions about the journey:

Minimalistic website interface showing simplicity and consistency

• Status: can the customer tell whether a request is sending or complete?

• Language: do labels describe the customer's task rather than internal department names?

• Control: can the customer correct a date or leave a step safely?

• Consistency: do the same actions use familiar labels and behavior?

• Prevention: are unavailable choices explained before submission?

• Recognition: are important details visible instead of requiring memory?

• Efficiency: can returning customers complete routine actions without unnecessary repetition?

• Focus: does the page prioritize relevant information?

• Recovery: does an error explain what went wrong and how to continue?

• Help: is assistance available where the task becomes difficult?

Inspect information hierarchy as well as individual controls. If availability conditions are buried below a promotional story, shortening the form alone may not resolve the uncertainty.

Treat accessibility as a separate review responsibility

Check whether someone can navigate the journey using a keyboard, identify the current control, understand field labels, read the content when enlarged, and interpret errors without relying only on color. Review meaningful image descriptions and captions where media carries information needed for the task.

Use W3C's Easy Checks as a starting point, while respecting its explicit limitation: passing those preliminary checks can still leave significant accessibility barriers. Arrange a more complete assessment for the relevant scope rather than describing a quick scan as proof of accessibility.

Record what was tested and what remains untested. Automated findings, manual review, and sessions with people using assistive technology provide different evidence. Do not turn an empty automated report into a universal assurance.

Turn a finding into a repairable issue

Suppose the hypothetical hire form shows only “Something went wrong” after an invalid date, clears the entered details, and gives no indication whether a request reached the business. This is an illustrative failure, not an observation of a real site.

Website accessibility settings panel showing options for inclusive design

An issue record could contain:

• Location: request form, after date validation.

• Reproduction: enter an unavailable date and submit the form.

• Observed problem: the explanation is missing and previously entered details disappear.

• Consequence: the customer cannot tell what to correct or whether to retry.

• Proposed repair: explain the date restriction, preserve valid entries, and make submission status clear.

• Acceptance check: repeat the failure with keyboard and touch input, then confirm a valid request completes once.

Prioritize barriers that block the task or create serious uncertainty before decorative refinements. Assign an owner and keep the evidence with the issue. A screenshot may help explain placement; it cannot demonstrate keyboard behavior on its own.

Validate the repair with the whole journey

Ask representative users to attempt the same task without coaching. Observe completion, hesitation, errors, requests for help, and whether the final status is understood. Obtain appropriate permission for any recording and avoid collecting unnecessary personal information.

Also test loading and responsiveness under the recorded conditions. Investigate the actual delayed step rather than applying an arbitrary whole-page time target to every journey.

After release, compare relevant task completion and error records, while checking for changes in traffic or availability. A small usability session can reveal a problem but does not establish a population-wide conversion lift. Keep that distinction in the report.

Finish with what was repaired, what remains uncertain, and the next journey to review. That is a more useful redesign brief than a list of fashionable interface treatments.