PRODUCT DESIGN
FULL CASE STUDY
2025
PlanO
Designed a complete in-platform booking experience to help parents discover, book, and manage activities while enabling providers to streamline their operations.
TIMELINE
Oct-Nov 2025
TEAM
2 Developer, 1 UI/UX Designer & Founder
ROLE
UI/UX Designer
SKILLS
Figma, Client Relations
WHAT I WALKED INTO
I worked with the founder and development team to turn complex booking workflows, provider operations, and parent experiences into a simpler, scalable product.
When I joined PlanO as a UI/UX designer, booking was still happening but outside the platform through provider’s websites. My role was to design the foundation of an in-platform experience — simplifying booking for parents while creating scalable workflows for providers. My work can be broadly divided into 5 pillars.
THE CHALLENGE
Two very different users. One platform. Completely different needs.
Parents
Parents needed a simple, fast way to:
Find the right class for their child
Understand availability without confusion
Book confidently and manage everything after
Providers
Providers needed a structured way to:
Onboard their business onto PlanO
Connect existing systems and payments
Define their own policies
The challenge wasn't only designing for parents and providers separately. It was creating an experience where both sides worked together — while making decisions based on real data limitations, technical constraints, and what could realistically be built for the first launch.
HOW I APPROACHED THE DESIGN
Before opening Figma, I understood the product and user first.
Understand First
Before designing anything, I spent time understanding the business -who the providers were, how they operated, what parents were trying to accomplish, and where the current experience was creating friction. Garima walked me through competitor references, documentation, and her operational thinking. As a parent herself, her perspective helped ground many product decisions.
Design, then discuss
For most flows, I'd design based on what we'd aligned on, then bring it back for review. When something required a decision from Garima, we discussed it. When something required knowing what was technically possible, I brought in the developer.
Daily standups
Garima introduced a nightly standup — me, the frontend developer, the backend developer, and Garima. This became the place where design decisions got pressure-tested against technical reality. If I'd designed something that required restructuring how data was fetched, we'd know before it went into development, not after.
Constraint as input
Some of my original ideas — like merging the location and class discovery steps — required backend changes that would have delayed launch. Rather than pushing for the ideal solution, I documented the proposal as a future enhancement and designed a version that worked within current constraints. Knowing when not to push is part of the job.
THE WORK
My work in PlanO can be divided into 4 pillars.
01
Booking flow
Simplifying how parents discover and book classes
02
Provider Dashboard
guided setup for activity providers
03
Parent Onboarding
removing friction at sign-up
04
Parent Dashboard
managing the complete booking lifecycle
01 — Booking Flow
Simplifying how parents discover and book classes
The Problem
When a parent found a class they wanted, the booking happened outside PlanO — redirected to the provider's website. My role was to bring that experience inside PlanO.
The flow had six steps. Reducing them felt like the obvious solution, but every step existed for a reason. Instead of removing steps, I focused on making each one easier to move through
So I stopped asking "how do I reduce steps" and asked "what's making each step harder than it needs to be?
Decision 1 - Make availability obvious
The calendar had two states: disabled and booked. But there were actually three completely different situations — the class isn't offered that day, it exists but is fully booked, or there's an available slot. Treating all unavailability the same created real confusion.
The calendar redesign introduced three distinct states — grey for not offered, red for fully booked, blue for available. One change. Completely different clarity.
The booking journey starts with choosing a date. If parents can't understand availability at that moment, they're more likely to abandon the flow before they even begin. Making the three states clear reduces that early friction.
Decision 2 — Parents shouldn't have to read paragraphs to choose a class
Class information was coming directly from provider websites via API — arriving as long unstructured paragraphs. Parents had to read everything just to find the schedule, duration, and price.
I applied the same thinking across the flow:
Long paragraphs became structured information — making it easier for parents to scan, compare, and choose the right class.
Class Listing
structured cards surfacing location, class name, operating days, duration, price
Class details
key information pulled out of paragraphs into scannable sections
Instructor page
background and details structured so parents could make a confident choice, not just see a name
Left Panel
booking details shown consistently throughout with an edit option, so parents always knew what they were booking without going back
One principle stayed consistent throughout the flow: surface what parents need to decide first.
A Constraint Worth Noting
I explored merging the location step into class discovery — one less step, less friction. During standup with the dev team we realised it required restructuring how class data was fetched from the backend. Too much complexity before launch. I documented it as a future enhancement and moved on. Knowing when to ship the right-enough solution is part of the job.
02 — Provider Onboarding and Dashboard
Creating a guided setup experience for activity providers
The Problem
Before a provider could accept bookings through PlanO, they needed to complete a multi-step setup — confirming business details, connecting their systems, integrating payments, and defining their own policies.
This wasn't a simple form. It was the technical and operational foundation of how a provider would run their business inside PlanO.
The challenge was making something genuinely complex feel structured and approachable — without oversimplifying it to the point where providers didn't understand what they were doing or why.
How I approached
The founder had already mapped the business requirements with detailed documentation, competitor references, and developer input. My role was to translate that into a guided experience that felt structured rather than overwhelming.
The setup was divided into three clear phases, with a persistent sidebar showing progress so providers always knew where they were and what came next.
Step 1 : Buissness Details
Pre-filled information removed unnecessary work and let providers focus on reviewing instead of re-entering.
Information collected during signup was pre-filled, so providers only needed to review and confirm it. A simple principle: don't ask users for information they already provided.
Step 2 : System Integration
Complex integrations were broken into clear, guided actions so providers always knew what to do next.
This was the most technical part of the setup. Providers connected their booking software, API, and payment system to activate bookings through PlanO.
My focus was making each task feel guided instead of technical—using clear labels, helper text, and visible completion states so providers always knew what to do next.
A small but deliberate addition was the "Here's how to find your API Key" helper link, reducing confusion around a technical requirement.
Step 3 : Buisness Policies
Providers could define policies that matched how they already ran their business—without making the setup feel complicated.
Providers defined their own cancellation and refund policies instead of following a platform-wide rule, so each business could manage bookings the way they already operated.
The refund flow was designed to support multiple cancellation windows and refund percentages, giving providers flexibility without making the setup feel complicated.
The Key Insight across all three pages
Providers aren't developers, but setting up their business still involves technical steps. My role wasn't to remove that complexity—it was to organise it into a flow that felt clear, guided, and easy to complete.
03 — Waitlist Hub
Managing uncertainty and communication for parents
The Problem
Parents could join a waitlist when a class was full, but after that there was nowhere to manage it. They couldn't easily see which waitlists they'd joined, discover new ones, or choose how they wanted to be notified when a spot opened.
Waiting is already uncertain. The experience shouldn't make it feel even more uncertain.
What I designed
The goal was to turn the waitlist into something parents could easily understand and manage. I organized the experience into three simple sections that covered the entire journey—from joining a waitlist to receiving updates.
The Waitlist Hub brought active waitlists, new waitlist discovery, and notification preferences into one place.
MY Active Waitlists
A card-based view showing each waitlisted class, date joined, and notification method. I reused the same card pattern from the booking flow so parents didn't have to learn a new interface.
Discover More Waitlists
A simple flow for joining additional waitlists. Parents select a provider, choose a class, and add themselves—no repeating the entire search process.
Communication Preference
A dedicated place to manage how waitlist updates are received, with support for multiple email addresses and phone numbers for families who need it.
One insight that changed the design
Initially, notifications supported a single phone number. During discussion, Garima explained that families don't always rely on one device—or even one person. One parent might be checking email while the other is available by phone, and some families wanted updates sent to both parents.
That insight changed the design. Instead of supporting just one contact, I designed the section to handle multiple email addresses and phone numbers while keeping it simple to manage.
04 — Parent dashboard and booking management
Managing the complete booking lifecycle after a class is booked.
The Problem
Booking a class was only half the journey. Parents needed somewhere to manage everything that came after — upcoming classes, booking history, cancellations, modifications, payment details. Without a clear dashboard, everything was scattered.
Decision 1 — Upcoming classes first
Why upcoming classes lead
When a parent logs in, the most urgent question is "what's happening next with my child's classes?" Everything else is secondary. Most time-sensitive information goes first.
Each class row shows
Class name and provider
Date, time, location
View Details and Cancel/Modify
Decision 2 — Cancel and modify as one flow
The natural instinct is two separate buttons — Cancel and Modify. But to modify a booking, a parent first has to cancel the existing one, then select a new date. Two labels. Same starting point. I combined them into one flow.
Step 1
Cancellation confirmation
Step 2
Cancellation policy shown
Step 3
Class name and provider
Instead of returning the parent to the dashboard, I redirected them straight to the booking calendar — fewer steps, same outcome.
Decision 3 — Booking details structured for scanning
Left — class details
Name, status tag, provider, date, time, location, instructor
Center — payment
Amount paid, date, method, payment status
Right — actions
Cancel/Modify, Download Invoice, Cancellation Policy
Status tags — Upcoming, Cancelled, Completed — give instant orientation before reading any detail. Bookings ordered by importance: upcoming first, then active, then past.
Edge cases mapped
If a parent clicks Cancel without reading the policy, a confirmation popup appears with policy details before completing the cancellation — preventing accidental cancellations. Refund eligibility, error states, and empty states were all designed, not left as afterthoughts.
ALSO WORTH MENTIONING
Halfway through the project, a recurring problem surfaced.
There was no shared button system—neither in the design files nor in the developer's code. Every new button had to be recreated manually, which started creating inconsistencies as more screens were designed.
We discussed it during a standup and agreed the product needed a reusable system. I took ownership of creating one.
I designed a button system covering types, sizes, icon variations, and interaction states—default, hover, pressed, disabled, destructive, and success—giving the team a single source of truth for consistent implementation.
Types, sizes, states, and icon variations — everything the developer needed to implement buttons consistently across every flow."
The Outcome
