Back to Services

    Sample deliverable

    Sample UX and accessibility review: a fictional booking flow

    A short example of the prioritised review I deliver on a scoped engagement, applied to a made-up product so you can see the shape of the work.

    This is an illustrative sample. The product, the flow and the findings are fictional. It is not client work, not conducted research and not measured outcomes. It is not a compliance certification.

    The fictional flow under review

    The fictional product is Parkside Physio, a made-up physiotherapy clinic that takes bookings online. The review covers five steps on mobile: choose a treatment, choose a clinic, pick a date and time, enter your details, then pay a £20 deposit to confirm the appointment.

    A real review is scoped with you before anything starts: the journeys covered, the access I need and what you get at the end. This sample walks one journey, the way a scoped review would.

    Findings at a glance

    The three fictional findings, their priority and the reason for it
    FindingPriorityWhy
    The button before payment just says "Continue"HighIt sits on the payment path, it affects everyone who books, and the fix is small.
    A date error is shown by colour aloneHighIt can block completing the booking, and it relates to the WCAG guidance on not relying on colour alone (1.4.1).
    The times never say whose time zone they are inMediumFewer people are affected than by the payment wording, but the cost of getting it wrong is a missed appointment.

    The findings in full

    1. Finding 1 · High priority

      The button before payment just says "Continue"

      Observation and example
      On the your-details step, the primary button reads "Continue". The next step asks for a £20 deposit. Nothing on the details step says payment comes next.
      Impact hypothesis
      People may expect to review or confirm the booking, not to pay. A surprise payment step can feel like a trick, and some people will abandon there.
      Priority and rationale
      High. It sits on the payment path, it affects everyone who books, and the fix is small.
      Recommendation
      Rename the button to "Continue to payment" and show the deposit amount on the details step, so the next step is never a surprise.
      How to verify
      In a usability test, ask people on the details step what they expect to happen next. After the change, watch drop-off between the details and payment steps.

    2. Finding 2 · High priority

      A date error is shown by colour alone

      Observation and example
      If someone picks a date in the past, the date field border turns red. There is no message, no icon, and nothing is announced to a screen reader.
      Impact hypothesis
      Someone who cannot perceive the colour change gets no explanation. The form just refuses to move on, and they are left guessing.
      Priority and rationale
      High. It can block completing the booking, and it relates to the WCAG guidance on not relying on colour alone (1.4.1).
      Recommendation
      Add a short text error next to the field, tied to it programmatically, with an icon so the state does not depend on colour.
      How to verify
      Fill the form using only a keyboard and a screen reader, and check the error is readable, announced and fixable.

    3. Finding 3 · Medium priority

      The times never say whose time zone they are in

      Observation and example
      The time picker shows "09:30, 10:15, 11:00" with no time zone. The fictional clinic has two locations and takes bookings from people travelling for treatment.
      Impact hypothesis
      Someone booking from another time zone may assume the times are their own, and arrive an hour early or late.
      Priority and rationale
      Medium. Fewer people are affected than by the payment wording, but the cost of getting it wrong is a missed appointment.
      Recommendation
      Label the times with the clinic’s time zone, for example "All times are UK time", next to the picker.
      How to verify
      Ask test participants which time zone the shown times are in. If they hesitate or guess wrong, the label is not doing its job.

    What a scoped review is, and isn’t

    • It covers the journeys we agree to walk, not every page by default.
    • It is informed by WCAG, but it is not a legal compliance audit or certification.
    • Specialist testing with assistive technology is scoped separately, with the right expertise brought in.
    • Impact statements are hypotheses to test, not measured results.

    Next steps on a real engagement

    We agree the scope in writing, I walk the key journeys and review the evidence you already have, then we go through the findings together so your team can act on them. After fixes, we retest the same journeys to check the problems are actually gone.

    This is an illustrative sample. The product, the flow and the findings are fictional. It is not client work, not conducted research and not measured outcomes. It is not a compliance certification.

    Discuss a review of your product

    Get in Touch

    Before you get in touch

    Projects and contract work: A short email is plenty. It helps if you tell me:

    • What the product is
    • The problem you’re trying to solve
    • Your rough timescale
    • What kind of support you’re after: a review, a project or someone embedded in the team

    Please don’t send personal data, login details or anything confidential to your client or company at this stage. We can sort out access properly once the scope is agreed.

    Permanent roles: open to Senior Product Designer, Senior UX Designer, Lead UX Designer and UX Consultant roles, plus suitable hands-on Head of UX opportunities. London hybrid or UK remote, and available immediately.

    Open in your email appLinkedInDownload CV (PDF)