

As PilatesPass introduced more service formats (such as block bookings, private sessions, livestream classes, seasonal workshops) it became harder to keep the overall experience consistent.
Every new variation added another exception to the system (e.g. a slightly different calendar, pricing pattern, or confirmation flow). Over time, these differences made the platform feel unpredictable and increased the amount of work the engineering team had to do.
The business needed a booking experience that felt consistent and stable as it scaled.
Three challenges became clear early on:
1. There were too many versions of the booking flow
The product had grown feature by feature, which meant screens, logic and UI patterns weren’t shared. Engineering were supporting multiple pathways that essentially did the same thing.
2. UI patterns had drifted
Inputs, calendars, indicators and buttons behaved differently depending on the service type. This made the experience feel more complicated for clients, and harder to maintain.
3. Too much manual intervention
The founder and support team were frequently stepping in to fix booking mistakes or explain quirks in the system. They were feeling frustated and wanted their time to be better untilised.
Together, these issues created friction for users and slowed the team down.
To bring structure back to the core booking experience, I defined four goals:
My focus was on simplifying the system, not just the screens. I worked closely with the engineering team and the founders to rebuild the booking experience from the inside out. Here's how I approached it:
Understanding every version of the booking flow
I mapped every journey end-to-end, including group classes, private sessions, courses, and highlighted where they were different and where they really didn’t need to be. This helped reveal a single flow hidden underneath all the variations.

Creating a clearer structure for the booking experience
I divided the booking journey into a small set of repeatable building blocks (such as Availability, Class Selection, Booking Type etc.). Instead of separate flows, these building blocks could be combined in different ways depending on what the instructor was offering. This kept the logic simple and reusable.
Strengthening the design system
I rebuilt core components so they worked well across all service types. This included calendars that scaled for single or multi-session bookings, a consistent pricing pattern, clearer progress indicators, better validation and messaging, and predictable buttons and actions. My aim was to make the experience feel stable and familiar, no matter what kind of session someone was booking.
Working closely with engineering
I partnered with engineering early to make sure the new flow and compentents didn’t add more work. I shared user flows, rules and reasoning behind decisions so the team understood not just what we were changing, but why. Together, we prioritised what was worth refactoring now, what could wait, and how to roll out improvements without disrupting instructors.
1. One booking flow, many possibilities
Instead of designing something new for each service type, we created one flexible flow that could adapt to different offerings without becoming confusing or inconsistent.

2. Predictable interactions
People feel more confident when they know what to expect, so I introduced clearer steps, stronger states, and more helpful validation so the experience guided clients through their decisions.
3. Components that could grow with the business
I strengthened the underlying UI patterns across search, filters and listings so engineering could reuse these structures as new formats were introduced. This meant we could support new service types, new bundles and more complex booking logic without redesigning the experience each time.

4. Helpful system behaviour
Small touches like clearer empty states, warnings when options were incompatible, and more transparent confirmation messaging removed a lot of the uncertainty people previously felt when booking.

I worked closely with the founder to understand how instructors used the system day-to-day, which parts caused the most work, and which ideas were coming next. This helped us prioritise what to fix immediately versus what to design for in the long term.
We partnered with engineering from the very start, reviewing complexities in the codebase and how we could simplify it. The goal wasn’t just better UI, it was reducing the number of exceptions engineers had to maintain.
By working together, we created a flow that was easier to build, easier to extend, and much easier to keep consistent.
The redesigned booking experience gave PilatesPass a much stronger foundation.
We monitored:
Across all measures, the experience became more stable, more predictable and easier for both sides to use.
Even without sharing exact numbers, the shift was clear: fewer issues, faster delivery, and a booking system that finally felt ready for growth.
This project reinforced something I strongly believe - systems create speed.
By strengthening the underlying structure, PilatesPass gained a booking experience that could scale with the business instead of slowing it down. It made life easier for clients, instructors, the founders and the engineering team.
And for me, it was a great example of how design, engineering and product thinking come together to improve systems and processes in a rapidly evolving marketplace.

PRODUCT DESIGN / Complex workflows
Partnered with the founder and engineering team to redesign search, listing pages and checkout for a large packaging catalogue. By restructuring the information architecture and introducing clearer patterns, the experience helped buyers make faster, more confident decisions while reducing operational load on the business.
View case study

PRODUCT STRATEGY / PRIORITISATION
Partnered with the founder, product, engineering and data to diagnose funnel issues, set a clear product strategy, and align teams behind a focused roadmap. Improved onboarding clarity, prioritisation and team direction while shaping a Series-A-ready narrative.
View case study