Alyne: Booking and Payments System for Wellness Social App
Designing group booking, payments, and social coordination for modern wellness users.
↑ Click the banner to move
Timeline
April 2025 – June 2025 (6 weeks)
Company
Alyne is a consumer wellness startup building a social booking and payments platform for boutique fitness and wellness classes.
Role & Team
Lead Product Designer, collaborated with 1 PM, 1 front-end engineer, and 2 back-end engineers.
Responsibility
Led the end-to-end product design over a 6-week sprint.
Social Booking UX, Payments Flow, and System Design.
Architected a mobile-first social booking and payment experience that enables group coordination, split payments, and shared commitment states—transforming fragmented wellness planning into a single collaborative flow.
Context & Background
Alyne is a mobile app designed to simplify the messy coordination problems around booking boutique fitness and wellness classes with friends.
While wellness itself is deeply social, the underlying infrastructure hasn’t caught up. People still rely on group texts, Venmo links, calendar screenshots, and scattered booking platforms to coordinate something as simple as a class together.
Existing platforms like Mindbody lacked a modern social layer and were not designed for collaborative booking, shared payments, or group commitment. The goal of Alyne was to make booking feel collaborative, connected, and easy to return to.
The Problem
Booking wellness classes isn’t just a transactional action. It’s a behavioral chain that requires shared intent, commitment, and coordination.
Coordinating availability across group chats and shared calendars
Splitting payments manually through Venmo or Zelle
Managing last-minute dropouts and no-shows
Tracking who had committed and who hadn’t
While booking solo worked reasonably well, booking as a group introduced friction at every step.
Key Improvements
Group booking with split payments
designed a group booking system that allowed users to book together while confirming and paying independently. The booking only locked in once everyone committed and paid, giving users clarity around group intent and reducing last-minute dropouts.
Why This Mattered?
It replaced fragile social contracts (“I’ll Venmo you later”) with a deterministic commitment model.
Impact
Reduced coordination overhead & flake risk
Intent-based discovery feed
Instead of surfacing only achievements, I designed a feed that highlighted intent signals, "Wants to try, Upcoming plans, Wishlist activity". This allowed friends to discover classes and studios organically, without the pressure to perform or compete.
Why This Mattered?
It turned discovery into a social coordination surface, not just a content feed.
Impact
Drived social stickiness without performance pressure
Studio discovery, social, local, and actionable
Instead of filtering through endless anonymous listings, users explore studios based on real-world proximity, social signals, and shared intent, where friends go, what’s trending nearby, and which offers are actually relevant.
Why This Mattered?
It preserved class utilization while making last-minute changes socially and operationally safe.
Impact
Reduced no-shows & preserving community flexibility
Booking transfer system
Designed a booking release and transfer system that allowed users to give up their spot if they couldn’t make it, and let others in the community claim it.
Why This Mattered?
It shifted discovery from anonymous browsing to socially grounded decision-making.
Impact
Increased booking relevance and follow-through by anchoring studio discovery
Design Approach
Before jumping into UI, I mapped how people actually coordinate wellness plans in real life. Most users relied on texts, calendar screenshots, studio links, and Venmoㅡ stitched together manually. This process wasn’t just fragmented; it failed to support:
1
Understanding the current behavior gap & coordination breakdown.
Before jumping into UI, I mapped how people actually coordinate wellness plans in real life. Most users relied on texts, calendar screenshots, studio links, and Venmoㅡ stitched together manually.
Highlights at this stage
Mapped the real coordination flow (Discover → Invite → Confirm → Pay → Attend)
Identified commitment ambiguity as the core systemic failure
Isolated the highest-friction moment: group confirmation & payment alignment
Reframed booking as a behavioral chain, not a single action
2
Consolidating fragmented flows into a shared coordination system.
There was no single place where group intent, commitment status, and payment state were shared. So instead of designing isolated screens, I re-architected Alyne as a coordination system, organizing the product around shared intent and commitment.
Highlights at this stage
Restructured the product from 12 scattered pages into 4 clear hubs
(Explore & Feed, Booking Hub, Profile & Community, Menu)Introduced shared commitment states (invited → confirmed → paid)
Anchored group chat, booking status, and payments to the same booking object
Designed solo, duo, and group bookings on a single core model
3
Validating coordination & commitment flows.
To ensure the coordination system worked in real social contexts, I built high-fidelity prototypes and ran lightweight usability sessions with early users and studio owners.
Early Testing Quotes
(Early users & studio owners, lightweight usability sessions)
⚠️ Commitment state ambiguity
“I honestly couldn’t tell if this class was actually booked yet or just ‘kind of happening.
It still felt like a soft plan, like a group chat decision.’”
“I assumed it wasn’t real until everyone paid.
There wasn’t a clear moment where it switched from ‘maybe’ to ‘confirmed.’”
⚠️ Payment status visibility (Follow-up breakdown)
“I see that Emily hadn’t paid… but then a day passed and I just forgot about it.”
“We didn’t realize one person was still pending until the class disappeared.”
Iterating on the coordination system based on user validation.
Using insights from real user testing, I refined the coordination and booking flow to fix the exact points where users still got confused or dropped off.
These iterations focused on making group commitments explicit, surfacing forgotten payments, and preventing silent booking failures.
Key UI changes based on validation
Explicit commitment state transitions
Payment follow-up toasts & reminders
① Explicit lock-in moment + state transition UI
② Toast + Follow-up payment reminders
Retrospective & Conclusion
Designing booking and payments as one system
This project showed me that booking and payment aren’t separate flows; they’re a single coordination system with financial consequences. I learned to design explicit financial states, lock-in moments, and recovery mechanisms that turn soft intent into real transactions.
Designing for shared financial accountability
Group booking broke down not at discovery, but at the moment money and responsibility entered the flow. By making commitment and payment states system-defined and visible, I reduced silent failures caused by forgotten payments, unclear responsibility, and delayed follow-ups. This reinforced my belief that trust in financial products comes from clarity, not just automation.
Bridging human coordination and financial logic
My role in this project was to translate messy human coordination into clear, system-enforced financial flows. I focused on: "Explicit commitment state transitions, Multi-party payment coordination, System-driven reminders, and Recovery flows" to ensure plans didn’t collapse after money entered the picture.
