Scaling a booking platform to 20+ services
Executive Summary
My Role: Lead UX Designer
Team: 2 designers, Product Manager, Developers, QA
Timeline: 8 Months
Scope: Consumer PWA (mobile and web), Business Owner panel, Outlet Manager panel, Super Admin, across 20+ service categories
The brief
The client wanted one platform where consumers could discover and book entertainment and personal care services, everything from movies and bowling to escape rooms, golf, and salons. The business model depended on onboarding new service categories quickly and cheaply, without rebuilding the product each time.
There was no existing platform, no user base, and no UX brief. What existed was a category taxonomy spanning 20+ subcategories, a four-tier user hierarchy the client had outlined, and a backend RFP focused entirely on AWS infrastructure. Design scope was mine to define, and early structural decisions would directly affect engineering cost, time to market, and whether the platform could grow without repeated redesign.
Defining the architecture before designing the interface
Before any UI work, I ran a working session with the PM and client stakeholders to map role permissions, data visibility, and booking logic across service types, ahead of designing a single screen. That wasn't the team's instinct; the instinct was to start on screens and work out structure later. I pushed for the opposite, because getting the structure wrong would cost far more than a week's delay.
That session surfaced the real tension: movies needed a seat map, bowling needed lane selection and per-game pricing and shoe sizing, events needed date/slot logic, personal care needed practitioner availability. Every service type had different booking logic, and the client wanted all of it managed through one platform by Business Owners of varying technical sophistication.
The early direction was a separate flow per service type, faster to start. After mapping what 20+ separate flows would mean for design, development, QA, and maintenance, I made the case to stop. A configurable system meant more upfront complexity and closer alignment with engineering, but it avoided duplicating work every time a category launched. I used the client's own expansion roadmap to show the cost difference over time. Stakeholders initially preferred separate flows, they were easier to understand, but aligned on the configurable approach once we walked through the long-term cost together.
We discarded several weeks of work and restarted.
Early-stage admin flow exploration
What configurable meant in practice
The booking experience surfaced only the fields relevant to each service, seat maps for cinema, lane and time for bowling, slot calendars for appointments, driven by how a Business Owner had configured their service, not by hardcoded interface logic. A new category could be activated in the Super Admin panel with zero frontend changes.
The key decision, worked out closely with engineering, was whether the booking form should adapt based on frontend rules, or whether the backend should tell the frontend what fields to show. Frontend logic meant a code change for every new service type. Backend logic meant the Super Admin could activate a category without touching the frontend at all.
We chose backend-driven. That single decision is what let the platform go from 5 to 20+ service types without a frontend rebuild.
Role model and permission boundaries
Four roles, each with distinct permission boundaries: Super Admin managed the platform, service templates, onboarding, commissions, offers. Business Owner managed their own business, services, outlets, pricing, performance across locations. Outlet Manager had a deliberately narrow view, scoped to their assigned outlets only, no access to business-level configuration or finances. Consumer experienced none of this complexity.
The outlet model made the Business Owner / Outlet Manager relationship work: one Business Owner could run multiple physical locations, each its own outlet with its own manager, configuration, and earnings tracking. An Outlet Manager could activate services and manage bookings, but couldn't touch outlet structure, assign other managers, or see business-wide finances, a real operational risk if that boundary were loose.
We validated the permission model with stakeholders through structured walkthroughs of real operational scenarios, not just a diagram review. That process surfaced two boundary cases we hadn't accounted for, resolved before detailed design began.
Mapping Platform Scope Before Designing the Interface
Permission Boundaries Across Super Admin, Business Owner and Outlet Manager
Consumer experience
All of the role and configuration complexity had to stay invisible to the end user. Navigation was structured around two sectors, Entertainment and Personal Care, with category icons that updated listings and deals simultaneously, the sector model came from the client's requirements; the design work was in how selections cascaded and how venue cards supported direct booking without a separate detail page first.
The original booking path was five-plus steps. We cut it to three by moving contextual decisions, add-ons, food, sharing, to post-booking moments instead of the critical path. Features like ride-share integration and group booking were deliberately deferred; the configurable architecture meant they could be added later without structural changes.
Consumer PWA screenshot (web and mobile)
The design system
One shared component system covered both consumer-facing interfaces and admin panels, rather than two separate systems that would double maintenance and drift apart over time.
The real decision was handling the visual and behavioral differences between a consumer booking card and a Business Owner dashboard panel, different purposes, different information density. We solved this with surface-level component variants, customer and admin, governed by one token system but with distinct visual treatment.
30+ reusable components, 200+ design variables, structured so engineering could extend it for new categories without design involvement each time. After launch, the component system was reused in adjacent internal tooling and became the engineering team's default pattern for new feature work.
Results
The platform launched with 2 enterprise clients. Within the first month, both were processing 500-2,000 bookings a month across multiple outlets, meaningful volume for a greenfield product with no prior user base, confirming the core booking experience worked and that Business Owners could configure services independently.
The more significant outcome: the client's team expanded the platform from 5 service types at launch to over 20, with no structural changes to the frontend or booking flows. New categories were configured and activated independently. That was the specific outcome the architecture was built to enable.
Annotated Business Owner dashboard wireframe
Business Owner dashboard hifi UI
What I would do differently
I'd find a way to talk to real Business Owners earlier, even informally. The configuration experience, how a bowling venue operator or salon owner would actually set up their service, was designed largely from stakeholder knowledge and assumption mapping. The system worked at launch, but some onboarding friction surfaced post-launch that earlier operator conversations likely would have caught. The consumer side was well validated through competitive analysis; the operator side was less tested, that's where I'd invest more time upfront next time.