Fitness, Niche, Responsive Web App - 2025
Nu Studio
A fitness studio platform designed to turn evolving operational rules into a structured booking system.
*Figma Make prototype
Product
Booking Platform
Surface
Web App (Desktop/Mobile)
Constraints
Evolving business rules
Cash + online payments
Future class expansion
Overview
Nu is a mindful movement studio. When the project started, there was no existing product logic. Booking rules, class conditions, and operational workflows were still evolving.
The platform had to support session packages, single bookings, flexible payments, and a front-desk check-in system; while keeping the experience calm and premium.
This project focused on translating real studio operations into a structured booking system that could scale as the studio grows.
Booking rules weren't defined yet
Class availability depended on level selection, minimum attendees, and time slots. Without clear logic, the booking flow risked confusion and operational errors.
Class viability created uncertainty
Sessions required at least three attendees to run. The system needed to handle this rule while keeping the experience predictable for clients.
Payment states could break check-in
Clients could pay online or at the studio. Without clear rules, unpaid bookings could disrupt front-desk operations and class entry.
Profile screens risked structural imbalance
Clients might have one session, many sessions, or none. The layout needed to stay structured without breaking visual harmony.
Booking a class seems simple. Until levels affect availability, packages affect payment, and capacity affects viability.
Business rules come before UI
Minimum attendees, level restrictions, and payment states were defined first. Screens were built only after the operational logic was clear.
Availability must reflect reality
Level selection happens before time selection so users only see sessions they can actually attend.
Edge cases must be predictable
Late arrival, unpaid bookings, and check-in windows were handled through clear system states instead of manual staff decisions.
Expansion should not break the structure
The class grid stays stable as the studio grows. Additional offerings live behind a “Browse All Classes” entry point instead of expanding endlessly.
Operational friction should stay invisible
Waitlists, payment settlement, and check-in enforcement happen quietly in the system without disrupting the booking experience.
Booking flow
Level selection defines available time slots so users only see sessions they can actually attend.
Schedule
Availability, capacity, and waitlists are surfaced clearly to avoid uncertainty when classes fill up.
Packages
Single sessions and multi-session packages share the same booking flow instead of creating parallel flows.
Profile
Upcoming sessions stay focused while expanded lists move into side sheets to avoid clutter.
Check-in
Arrival states guide users through early arrival, check-in windows, and unpaid sessions without manual staff intervention.
Class catalog
A “Browse All Classes” entry point allows the studio to expand offerings without breaking the layout.
WHY THIS MATTERED
Studios run on people, products run on rules.
Predictable booking for clients
Level-based availability and clear session states removed uncertainty when selecting classes and times.
Operational clarity for the studio
Check-in states and payment handling reduced front-desk friction and eliminated manual interpretation.
Demand preserved through waitlists
Full classes no longer meant lost clients. Waitlists captured overflow demand and allowed cancellations.
A system ready to grow
New classes, packages, and schedules can be introduced without redesigning from scratch.
WHAT I'D CARRY FORWARD
Operational rules must be designed early
Studios run on real-world constraints. If those rules are not systematized early, the product quickly becomes unpredictable.
Booking systems hide operational complexity
What looks like a simple “book a class” flow often requires handling capacity, payments, and rescheduling states behind the scenes.
Edge cases deserve first-class design
Check-in timing, unpaid sessions, and full classes can't be treated as exceptions. They shape how the system behaves every day.
Scalability is a product decision
Adding new classes, packages, or schedules shouldn't require redesigning the interface. The structure must anticipate growth.