STUDIO
A wellness booking app, designed and prototyped in Figma.
Independent portfolio concept.
Product Design · UI Design · Interactive Prototyping
Role
Product design and prototyping
Tools
Figma
Scope
Five screens, nine components, one working booking path
Deliverables
Interactive prototype, component library, case study
Overview
STUDIO is a five-screen mobile appointment-booking experience for a premium wellness studio. It covers the full journey from browsing services to booking confirmation, with reusable components and a booking state that stays consistent from the first tap to the last.
Problem
Booking a massage should feel as calm as the massage. Booking tools often put dense listings, crowded calendars and generic styling between the person and the appointment.
STUDIO explores the opposite: one decision per screen, a restrained editorial look, and a booking state that stays correct from the first tap to the confirmation.
Design direction
The look is warm, quiet and editorial. A warm neutral background, a muted botanical green accent, thin borders and very little shadow keep the screens calm. Fraunces carries the headlines and service names, and DM Sans handles everything functional. Photography is natural light, soft shadows and clean compositions, with no people, so the screens stay focused on the service.
Every screen asks for one decision. Services that aren't available yet are visibly inactive, so nothing looks tappable that isn't.
Color
Canvas
#F5F0E8
Surface
#FBF8F3
Ink
#2A2823
Accent
#56674F
Typography
Fraunces · Display
DM Sans · Body
Spacing: 4 · 8 · 16 · 24 · 32 px
Radius: 8 · 12 · 20 px + pill
Selected foundations from the STUDIO Figma file.
The flow
Explore, Service Details, Select Appointment, Review Booking, Booking Confirmation, and back to Explore.
Back works at every step and keeps the choice you made. Starting a new booking resets the selection to the default.
Selected screens
Explore. A featured service and what is coming next. Unavailable services look inactive, so nothing appears tappable that isn't.
Service Details. One photo, a short description, duration, price, three benefits, and a single primary action.
Select Appointment. A fixed date and three time slots with clear available, selected and unavailable states.
Booking Confirmation. The selected time repeated back, with a plain note that it is a prototype and no real appointment is created.
Components and interactive states
The system is deliberately small: nine components built on color, spacing and radius variables and six text styles. Every screen is assembled from instances, so a change to a button or a card updates everywhere.
Components: primary, secondary and disabled buttons, service card, date chip, time slot, booking summary card, top navigation, bottom navigation, and a status bar.
Keeping the selected time correct
The time slot is the one piece of real logic. Figma resets a component's state when you navigate away and back, so the selection can't live in the component.
Instead, two prototype variables, selectedTime and isLaterSlot, are set together on every tap. The slot highlight and the time shown on Review and Confirmation both read from them. That is why:
• Back keeps your choice
• Switching slots updates every screen that shows the time
• Starting a new booking resets the time to 10:00 AM
Time-slot states
Selected
10:00 AM · default choice
Available
11:30 AM · tap to change
Unavailable
2:00 PM · no tap action
Each bookable tap updates selectedTime and isLaterSlot together. Review and Confirmation read the same selected time.
Demo video
Two complete bookings, one at 10:00 AM and one at 11:30 AM. The selected time carries through Review and Confirmation, and a new booking starts from the default.
Try it yourself
Tap the featured service to start. Best viewed on a phone or at phone size.
Open the prototype
Scope and what I'd build next
One service is bookable, with a fixed date. The prototype has no backend, account system or payment.
If I extended it, the next steps would be a second bookable service with its own times, and a Bookings tab that keeps each confirmed appointment in a list. Both need state that survives a reset, which is the interesting design problem.