Where do we lose players in the booking journey?

Tenup, a tennis-court booking platform, was preparing a major redesign. The v2 mock-ups already built in some assumptions. Carrying v1 frictions into a new product would have meant a second redesign.

Client

Tenup · product and design team

My role

Audit, scoring, readout

Deliverables

Prioritisation matrix, roadmap, design briefing

1. Mapping4 days

   Exploring the product, the full journey, choosing the 5 critical screens.

2. Heuristic review1 week

   Each screen assessed against Nielsen's 10 heuristics and ISO 9241, with screenshots and severity.

3. Scoring4 days

   Frequency × impact × persistence, prioritisation matrix.

4. Recommendations4 days

   Quick wins, structural fixes, long-term improvements. Design briefing.

Why this approach

1. An expert audit rather than tests

   3 weeks before v2, a known flow and a need for full coverage of the 5 screens: the heuristic audit was the right balance of time and thoroughness.

2. Two reference frameworks

   Nielsen's 10 heuristics and ISO 9241, so that each violation is backed by a recognised criterion, not an opinion.

3. Explicit scoring

   Frequency × impact × persistence: a prioritisation the team can challenge and reuse.

1. Where does the booking journey create friction?
2. Which frictions are critical before v2?
3. Do the hypotheses built into the v2 mock-ups hold up?

1. Step 4/6
   Availability only appears at step 4

   Club, surface, equipment, time slot… and only then do you learn the court is taken. Three minutes invested for a dead end.

2. Critical
   No detection of overlapping bookings

   The conflict with an existing booking is only flagged after payment, with a generic message. A direct hit on trust.

3. Memory
   Filters disappear once applied

   Surface, covered court, max price: users have to remember their own criteria from one step to the next, which is especially costly on mobile.

4. 3
   Three date pickers with no shared logic

   « Slot », « range », « availability » mean the same thing depending on the screen. More learning, more distrust at the moment of paying.

1. P1Show availability in real time

   As soon as the time slot is selected, before going any further.

2. P1Check for conflicts before payment

   Cross-check with active bookings, with an explicit warning.

3. P2A persistent summary of filters

   In the header of the booking flow.

4. P2One date picker, one vocabulary

   A unified component in the design system and a shared design/dev glossary.

Every method has blind spots. Here are this study's, and how I accounted for them.

• An expert audit does not replace observation.

  It detects violations, not their real weight for players. A user test on v2 is the next step.