Project Context
Pagoda is a SaaS startup offering small business owners access to their salon management suite including website, booking, payment, and marketing tools in one place without technical expertise. One of the two founders, who is the developer, was inspired by his mother, an immigrant nail salon owner, who ran her business on pen, paper, and phone calls.
Pagoda hired me to design a mobile booking app for a prospective client, a multi-stylist barbershop weighing a move onto the platform.
Impact
I pitched the idea of keeping the design flexible for white-label use across their clients which was loved and adopted.
I delivered a full prototype plus appointment lookup and cancellation, which was mentioned as a nice-to-have, in three branding versions so the founders could choose how much customization they wanted to allow clients.
The app is currently in development, and the barbershop is now featured as a Pagoda client awaiting migration.
How might we design a booking app that keeps customers after a platform switch?
Problem
An appointment booking app could close a client. I pitched making a white-label app instead of a one-off as an addition to their suite.
A prospective barbershop client was ready to move to Pagoda, but wouldn't give up the functionality of their existing booking app for their customers. Pagoda only had a manager-facing mobile application and nothing for customers. Losing their customer booking app was a dealbreaker, so my designs had to fill this gap and preferably be even better to excite the client.
User Impact
Since we are replacing an existing app, the new app must be an improvement to not deter any customers from returning.
Business Impact
I proposed building the app as a white-label product, and Pagoda loved this. They agreed and wanted to use it for closing new clients or reinforcing their value.
Financial Impact
The client ran a barbering school at the same location. Pagoda saw it as a path to future business, since students would eventually open shops of their own.
Audit
The old app was quick, if you knew exactly what you wanted to do.
As my first step, I spent time looking at everything within the existing app. I tested the booking flow twice, once as a new user booking an appointment, and once again to explore every option and state. The app was quick to reach success if you already knew what you wanted, but difficult to navigate if you didn't.
Hard to scan services
Service lists were organized using drop-down menu selections that you had to pick one by one, making services hard to scan, especially if a stylist had many options.
Frustrating back buttons
I expected "back" to take me one screen back, but I'd find myself frustratingly back at the start re-selecting options. Sometimes, the button was grayed out but still clickable.
Excessive taps
A "Your Order" screen asked for review after picking a service, a time, and at checkout. This added multiple taps by needing to review what you just selected at each step.
The audit gave me these three considerations: how users scan listed services, making changes while booking, and a flow with no excessive steps.
Design
Building for speed, consistency, and reusability.
The founders already had speed and consistency in mind, and I added the white-label pitch. Every design decision works toward one of these three priorities:
Speed
Keep the flow and CTAs simple to be quicker and more efficient than a phone call or using the website.
Consistency
Use Pagoda Labs' existing design system and booking flow to feel like part of their platform.
Reusability
Build it as a white-label template so Pagoda Labs could rebrand the same app for each new client.
Pills for services
To fix the cluttered service lists and support scalability, I went with category pills that support multi-select.
The tradeoff was that category title lengths have to stay short enough to not take too much horizontal space. So I shared a character limit recommendation to ensure current categories fit. I flagged this with the team and they accepted this as the best solution.
Breadcrumbs for navigation
I made each step selectable, so you can jump back and make changes without starting over.
In the old app, going back to the first selection from checkout took 6 taps and cleared everything you picked, so completing the booking took 10 more, for 16 taps total. My design takes 2 taps to go back and keeps previous selections, so the user reviews and continues in 5, for 7 taps total.
Lookup and cancellation
The founders mentioned a "nice-to-have" depending on available project time was letting customers look up and cancel an appointment.
I believed it would be necessary to include this so that customers can easily "undo" their appointment in case they made an error and need to re-book or if something come's up and they won't go out of their way to call the shop.
The key decision was how users would access an existing appointment. I confirmed that users receive via email a 6-digit confirmation code after booking, so I built lookup around that.
Three branding versions
I built three full versions of the prototype so they could test the options: full Pagoda branding, Pagoda fonts with the client's colors, and full client branding.
The decision here set a precedent for how Pagoda could offer branding choices to future clients, which mattered for reusing the app as a template.
Developer Handoff
I walked the founders through a working Figma prototype, starting with the pages and features before showing separate branding versions.
For branding, I stayed neutral to get first reactions, then gave my recommendation: the mixed version, with client colors and Pagoda fonts. It lets the client show some of their identity while keeping every app legible through standard fonts and colors that ensure contrast accessibility.
I handed off the full set of designs in Figma, organized with named layers and auto-layout, so the file stayed responsive and easy for the developer to work from, along with the interactive prototype.
*Flow for prototype was branded for the first client. Logo blurred for their anonymity.
Outcome
A one-off app became part of a larger SaaS package.
The founders approved the full set of designs and agreed with my recommendation, choosing the mixed-branding version. I delivered a full working prototype and booking flow plus lookup and cancellation.
The project started as a one-off for a prospective client and ended as a reusable mobile booking experience to add to Pagoda's feature set.
The first app is currently in development and I expect it to release soon. The barbershop is already featured as a Pagoda client and is awaiting migration from their old software.
Reflection
What I learned
New experiences
I got two new experiences out of this project: designing for a developer handoff, and working inside an existing design system. I was accountable to Pagoda's requirements and kept in mind the founder/developer who was going to code my designs. I was thoughtful about constraints and clarified up front instead of waiting to discover issues mid-project. When I had to face ambiguity or make assumptions, I kept track of those points so that I could ask later and have ideas prepared.
Simplicity in design
I kept the design simple which left some screens, like the home screen, to potentially feel under-built. The founders were happy and excited about the results, since simplicity was a priority, but I'd want to explore how I could make the designs more inviting while still working as a white-label app.
Next Steps
What I would do next
Measure performance: Once the app is live, I would want to learn about how users are using the application to identify drop-off points and new features, then adjust from there.
Appointment Lookup: Currently, looking up an existing appointment requires a confirmation code, something users will have to find from a confirmation email. I would want to explore ways for a successful lookup while using different credentials, in case the original confirmation is lost or hard to find.
Update the Home: I would look for ways to make the Homepage more warm, perhaps with an image of the shop or added functionality to contact them or find directions. Additionally, it will be necessary to keep the UI current as Pagoda's design system evolves.