Simulated UX Design Challenge for SoulCycle
This project is part of my ongoing effort to build a portfolio of UX design work that reflects real-world product challenges. Instead of starting from scratch or cloning an existing app, I used AI as a simulated product manager to create a realistic design brief for a SoulCycle app problem. By doing so, I’m able to practice the same kind of work I would encounter on the job, framing user pain points, balancing business goals, and creating design solutions within real-world constraints.
I selected waitlist transparency as my focus because it’s a universal UX frustration (not just for fitness apps, but also in industries like airlines, restaurants, and ticketing). Using AI as a collaborative tool, I:
Generated a PM-style product brief, outlining background, problem statement, user pain points, business goals, and success metrics.
Structured the challenge like a whiteboard/take-home exercise, the same format recruiters and hiring managers use to evaluate candidates.
Planned the design deliverables, mapping the current user journey, highlighting where the system breaks down, and proposing wireframes for a more transparent, trustworthy waitlist experience.
This approach allows me to treat AI like a design mentor and project accelerator: giving me prompts, constraints, and framing that feel authentic to a real workplace scenario. It bridges the gap between coursework and industry by letting me create a professional, portfolio-worthy case study even without direct client work.
Starting Point: The PM Hand-off
Design projects rarely start with polished specs and instead often begin with a problem framed by a Product Manager. To simulate this, I created a realistic PM hand-off that outlines the pain points, goals, and constraints I used to guide my design process.
“Hi, we’ve been hearing a lot of frustration around the waitlist. Riders don’t understand where they stand once they join, they’re nervous about when their credits will be charged, and they often miss notifications when a spot opens up. It’s creating trust issues, and support is logging way too many tickets on this.
What I’d like you to explore is:
How can we make the waitlist experience feel more transparent and fair?
Specifically, can we show position in line, clarify credit rules up front, and make notifications feel more actionable?
Keep in mind: we don’t want to overwhelm people with too much detail, and the solution should still feel very ‘SoulCycle’ — simple, energizing, not transactional.
If you can map the current flow, highlight where people drop off, and come back with some mid-fidelity wireframes for a cleaner journey (joining → waiting → getting a spot), that would be perfect. Don’t get too stuck on engineering constraints at this stage…just focus on what makes sense for riders. We’ll circle back with engineering to validate feasibility later.”
Jordan Reyes, Product Manager
Process: The Path to a Solution
Understanding the Problem
Synthesized rider pain points from PM hand-off and secondary research.
Created lightweight personas (e.g., “busy professional squeezing in a class before work” vs. “new rider anxious about losing credits”).
Mapped the current waitlist journey to highlight confusion points (position uncertainty, unclear notifications, credit anxiety).
Identified business implications (lost trust, dropped bookings, reduced retention)
Ideation & Exploration
Sketched multiple approaches to improving transparency and notifications.
Explored low-fidelity wireframes focusing on:
Position visibility (“You are #3 on the waitlist”).
Clear rules for when credits are held or returned.
Actionable notifications (join, cancel, confirm).
Evaluated tradeoffs of different flows (simplicity vs. flexibility).
Selected the most promising concepts based on rider clarity + feasibility.
Designing the Solution
Developed mid- and high-fidelity wireframes in Figma.
Refined flows for joining, monitoring, and securing a waitlist spot.
Introduced new interface elements:
Real-time waitlist position indicator.
Clear credit status messaging.
Notification preferences toggle.
Iterated on design details to maintain SoulCycle’s brand tone (energetic, motivating, premium).
Prepared final annotated mockups to demonstrate usability improvements.
→ Understanding the Problem
Clarifying & Defining the Need
Jordan’s brief highlighted three pain points: unclear waitlist position, credit anxiety, and missed notifications. She also provided two design constraints: keep details simple and preserve SoulCycle’s energizing, lifestyle-focused brand feel. At this stage, I also factored in the business constraints she did not specify but that would be expected in a real project: engineering resources (avoid solutions that require a complete backend overhaul), revenue considerations (ensure credit policies remain fair without undermining the business model), timeline (scope improvements to be achievable within a few release cycles).
I translated the problem into three design goals:
Transparency without overload: riders should see their position and odds in a way that feels simple and motivating, not transactional.
Credit clarity at the point of decision: rules for charges and refunds must be predictable and surfaced before a rider commits.
Actionable notifications: alerts should come at the right time and make it easy to confirm or decline a spot.
Together, these goals defined my scope: create a waitlist experience that resolves confusion, reduces support load, and reinforces trust.
Research
Goals:
⭐️ Understand how riders currently experience the SoulCycle waitlist.
⭐️ Identify pain points around transparency, credits, and notifications.
⭐️ Explore what other fitness platforms or booking systems do well (or poorly) in similar flows.
Methods:
📚 Secondary research: Reviewed Reddit threads, app store reviews, competitor apps, and official policies to uncover recurring frustrations and industry practices.
📚 User research: Conducted a handful of lightweight interviews with SoulCycle riders, segmented into committed riders, casual drop-ins, newcomers, and busy professionals, to capture real experiences and emotional pain points.
📚 Task analysis: Mapped the current SoulCycle waitlist flow to identify friction points around visibility, credit rules, and notification timing.
Links to Additional Materials: interview questionnaire, affinity mapping figjam, user flow diagram
-
Transparency
Riders on Reddit often say: “I just want to know if I’ll get in or not.”
ClassPass displays exact waitlist position (e.g., “You’re #3 of 6”), but users complain it gives false hope when spots don’t open.
Nielsen Norman Group notes that too much queue detail can actually raise anxiety rather than reduce it.
Credits and Policies
SoulCycle FAQ: Riders must cancel by 5pm the day before class or they lose credits.
Reddit discussions show many riders feel “blindsided” when auto-enrolled after the cancellation window closes.
ClassPass and similar competitors often bury cancellation/refund rules in fine print, which confuses users and creates mistrust.
Notifications
Reddit riders report frustration about being auto-added overnight, losing credits while asleep or at work.
Competitors like Resy (restaurant reservations) use short accept/decline windows to prevent surprises.
Many riders express they’d rather get extra reminders than risk losing money or missing class.
System Behavior
Real-time updates feel trustworthy but can be resource-intensive and lead to notification fatigue.
ClassPass sometimes sends late-night updates, which frustrates users.
UX guidance suggests focusing on meaningful milestones instead of continuous updates.
-
The waitlist is avoided purposely: Committed riders and busy professionals skip the waitlist altogether, planning around class openings instead. The feature does not fail at the point of use, it fails at adoption.
Policies feel like traps to newcomers: First-time and casual riders often do not understand credits, cancellation windows, or auto-enrollment. Out of fear of losing money, they rely on friends to explain the rules. One wrong tap feels like it could cost them.
Reliability lives in the booking window: Riders anchor their planning around the Monday class release or Early Soul paid access. That release is treated as the real system of control, while the waitlist is viewed as a gamble.
Notifications lack impact: Regular booking alerts create excitement and confirmation. Waitlist alerts are vague, forgettable, or too late to act on, so riders ignore them. The signal does not change behavior.
Friends replace onboarding: Casual riders and newcomers depend on peers to interpret rules, choose classes, and decide whether to risk credits. The community is doing the work the app should be doing.
-
Visualizing the flow made clear where trust breaks down in the waitlist journey
Different rider segments struggle at different points, from policy pop-ups to late notifications
The Monday booking release acts as the real system of control while the waitlist feels secondary
Notifications in the waitlist lack clarity and timing, turning what should be excitement into frustration
Pain points show the issue is not only screen design but also transparency, policy communication, and timing
Key Insights
✅ Riders want clarity, not noise
Exact positions in line create false hope, while vague status feels unhelpful. Riders want a sense of likelihood at meaningful moments. → Show the total waitlist pool size and provide updates only at key milestones (e.g., evening before, 1h before class) instead of continuous micro-movements.
✅ Credit policies feel hidden and punitive
Strict policies like “cancel by 5pm the day before or lose credits” are hard to find, causing mistrust when riders are auto-enrolled→ Surface cancellation and credit rules upfront in the waitlist pop-up, with unavoidable bold text and a link to the full policy.
✅ Notifications are a source of stress
Riders feel powerless when added overnight or without confirmation. They prefer timely reminders and the chance to accept or decline.→ Add an evening reminder for riders still on the list, and when a spot opens send a “Tap to accept” notification with a 20-minute window before auto-enrollment.
✅ System updates must balance trust and feasibility
Real-time tracking is resource-heavy and overwhelming. Riders don’t need constant updates, just trustworthy ones. → Replace real-time tracking with a hybrid update model that emphasizes clarity at meaningful points while keeping engineering load reasonable.