Designing a Service System for a Live Yoga Practice
How I built the digital infrastructure for a real, running business — and what the decisions looked like in practice.
Yoga × UX
50-60%
ONBOARDING TIME REDUCED
15-20
ACTIVE LIVE STUDENT
5-6mo
AVERAGE RETENTION
ROLE
YEAR
Sole UX Designer + Founder
2025 - ongoing
The Overview
THE PROBLEM
A live yoga service with 15–20 students and strong retention, but onboarding happened entirely via WhatsApp, every inquiry required 20+ minutes of manual explanation, and growth was capped by the founder's bandwidth.
A validated service with zero scalable infrastructure
MY APPROACH
Reframe the website as a service infrastructure
Not a promotional page. Design a clarity-first digital system that filters, aligns, and prepares students before they send an inquiry. Every page is designed as a component of a larger system.
THE OUTCOME
Operational onboarding time cut by 50–60%
Inquiries now arrive pre-informed. SEO discoverability established from zero. Foundation built for automated enrollment in Phase 2. Students are live, paying, and retained.
I was the sole designer and founder. That means I owned the UX work entirely — problem framing, IA, content strategy, UI, and service flow. I had direct exposure to every business constraint, every student conversation, and every operational failure that shaped the design decisions.
"
— Context · Vaidehi Yelkawar, Founder + Designer
15–20
Active students across 2 live batches
5-6 mo
Average student retention — the practice held people
~25 min
Per inquiry — enrolled or not — all manual
50 %+
Onboarding time reduced post-website
Four Lenses
These aren't positioning statements — they're descriptions of how I actually approached specific decisions. Each one shows up in the case study below.
Every page is a component of a system, not a standalone asset
01 / SYSTEM THINKING
I try to design with the product's future state in mind. On this project, that meant asking early: if inquiry volume doubles, does this hold? If I add a payment layer in Phase 2, does the current IA accommodate it without requiring a rebuild?
The website is one touchpoint in a longer arc
02 / SERVICE DESIGN
The real experience includes how a student first hears about the class — referral, flyer, search result — what they do after landing, what the onboarding conversation feels like, and whether their first class meets what the site promised. I designed the full arc.
Design decisions framed in business terms
03 / BUSINESS + UX ALIGNMENT
With an MBA background, I frame design decisions in business terms. The choice to keep enrollment manual in Phase 1 wasn't aesthetic — it was a retention decision based on what I'd seen work with early students.
AI surfaced options. I made choices.
04 / AI-AUGMENTED WORKFLOW
I used AI tools to accelerate content drafting, SEO structuring, and onboarding template creation. In each case, the AI produced a starting point, and I revised it against what I actually knew from real inquiry conversations. All design decisions remained human-led.
The service worked.
The system didn't.
Vaidehi Yoga grew through community referrals — no paid marketing, no formal funnel. Students found it, tried it, and stayed. Retention across the first batches was 5–6 months. That's meaningful for a small live service.
But everything operationally was held together by direct conversation. There was no website, no structured onboarding, and no single place where a potential student could understand what the service was before reaching out. Every inquiry started from zero.
What Onboarding Actually Looked Like Before the Website
Discovery
A potential student sees a flyer or gets a referral — no single source of truth
They message directly — with no prior context about structure, schedule, or pricing
I explain the structure, commitment, schedule, and pricing — every single time, from scratch
They fill in a form. I manually follow up per person.
First Contact via WhatsApp
Manual 20-30 Min Explanation
Google Form + Manual Follow-Up
Payment via Screenshot
No gateway, no automation - Screenshot confirmation sent manually
Class Details Sent Manually
Links, materials, and schedule sent individually per student. Entirely non-scalable.
THREE PROBLEM THAT NEEDED FIXING
PROBLEM 01
Every inquiry triggered the same 20+ minute explanation loop — structure, philosophy, schedule, expectations, pricing. I answered them individually in every conversation. That's not a relationship issue; it's an information architecture issue.
Manual Onboarding Bottleneck
PROBLEM 02
Expectation Misalignment = Drop-Off
Several students expected something closer to a fitness class — faster, more physical, results-oriented. Hatha Yoga is structured, deliberate, and philosophical. The gap led to early drop-off. This wasn't a product problem — it was a communication design problem.
PROBLEM 03
Growth Constrained by Bandwidth
Retention was strong, but new student acquisition was completely bottlenecked by how many manual onboarding conversations I could handle per week. There was no leverage in the system.
What I learned from
30+ conversations
I didn't run formal user interviews. What I had was better in some ways — 30+ real conversations with people actively considering enrollment, spread over six months.
FOUR KEY FINDINGS
METHOD
I reviewed 30+ inquiry threads and 25+ form responses. I coded them by recurring question type, expectation signal, and drop-off point. It wasn't a research sprint — it was treating data I already had as data.
Real inquiry data treated as data
FINDING 01
More than 80% of initial inquiries contained the same structural question: What is Hatha Yoga? How often are classes? What's the commitment? What equipment do I need? How much does it cost? This is an IA problem, not a communication problem.
Same 5 questions, every single time
FINDING 02
Students who expected a workout-focused class and encountered a structured, philosophical Hatha Yoga class dropped out within the first month. The product wasn't wrong — the filtering was. The entry point wasn't setting expectations correctly.
Philosophy vs. Fitness Expectation Gap
FINDING 03
In most conversations, students asked about pricing within the first few messages — before they had a real sense of what they were paying for. This led to early drop-off from students who might have enrolled had the value conversation happened first. The sequence mattered.
Price came up before value was established
FINDING 04
Students found the service through flyers shared on WhatsApp, Facebook, and Instagram — but there was no single authoritative source of information. Each channel told a slightly different story, leading to inconsistent expectations before the first conversation.
Discovery - Scattered and Uncontrolled
The problem wasn't the yoga. It was ambiguity — at every stage before a student ever showed up to a class. The design response to ambiguity is clarity
"
— Core Insight · Section 4, Research Synthesis
THE BRIEF
The surface request was straightforward: a web presence for the yoga service. A brochure would have helped a little. It wouldn't have solved the problem.
"Build a website."
THE REFRAME
The actual problem was different.
The research pointed toward a different framing: design a clarity-first digital system that filters, aligns, and prepares students before they send an inquiry.
THE DESIGN CRITERIA
Six jobs simultaneously.
Filter for fit.
Establish value before cost.
Answer recurring questions at scale.
Set philosophical expectations early.
Build SEO discoverability.
Create a foundation for Phase 2 automation.
From insight to decision
Every major design decision on vaidehiyoga.com traces back to a specific finding from my onboarding research. Here is that connection made explicit.
Decision Traceability Matrix
FINDING IT ADDRESSES
RATIONALE
Decision
FAQ Page with same 5 questions answered first
80%+ of inquiries contained the same 5 structural questions
Move information delivery out of WhatsApp and into a stable digital layer. Inquiry time drops because the conversation can begin further along.
"Who This Is For" section high on homepage
The philosophy vs. fitness expectation gap drove the early drop-off
Set expectations before value — so that students who enroll understand what they're committing to. Filters for retention, not just conversion.
No pricing on homepage. Pricing page exists but is not in primary nav.
Price came up before value was established in most conversations
Sequence matters: value before cost. A student who understands the practice before seeing the price is less likely to drop off from sticker shock.
One CTA: "Request Class Details" — not "Sign Up Now"
Impulsive sign-ups who didn't understand the commitment drove early drop-off
The wording signals the process is considered, not impulsive. Filters for serious students. Wording is a design decision.
Testimonials immediately before every closing CTA
Trust wasn't established when the CTA appeared — cost came before confidence
By the time a visitor reaches that point, they've read what the practice is, who it's for, and how it works. The testimonials confirm, not introduce. CTA is effective when trust is already built.
SEO structure with Hatha Yoga-specific metadata
Discovery was scattered and uncontrolled — no single authoritative source
Establish a canonical source of truth. Students searching "Hatha Yoga [city]" find the site, not a flyer that tells a different story.
Screens from the Live Product






How AI was actually used
AI tools were used to accelerate specific parts of the workflow. In each case, the AI produced a starting point, and I revised it against what I actually knew from real inquiry conversations. Critically, I kept all design decisions human-led.
What AI Actually Did
✔ Drafted initial website copy — I revised every sentence for tone, accuracy, and alignment with student expectations
✔ Structured the FAQ section — I edited the questions based on what I actually heard in onboarding conversations
✔ Generated onboarding message templates — I refined them through real conversations
✔ Helped structure the IA — I made final decisions on navigation and page hierarchy
✔ Accelerated SEO keyword research — I validated against real inquiry language and context
What AI Actually Did
✖ AI did not make a single design decision on this project
✖ AI did not conduct or synthesize the research — I did that from real inquiry data
✖ AI is not embedded in the product — there is no AI feature on the live website
✖ AI did not determine the phased rollout strategy — that came from product thinking and business judgment
✖ AI did not choose the IA sequence that prioritizes value before cost — that came from the inquiry analysis
Why the UI looks the way it does
The visual decisions on this project weren't aesthetic preferences — they were communication decisions. Here is why each design choice was made, grounded in the service's pedagogy and the user's expectations.


Playfair Display (serif)
Playfair Display (serif)
Playfair Display (serif)
Lato (sans-serif)
Lato (sans-serif)
Lato (sans-serif)
Lato (sans-serif)
Lato (sans-serif)
Lato (sans-serif)
Lato (sans-serif)
Earthy warmth over clinical white
DECISION 01 / COLOR
Traditional Hatha Yoga is rooted in nature, breath, and the body — not performance or productivity. A cool, minimal palette (white, navy, sans-serif everything) would signal "fitness app." The earthy tones — terracotta, sage, off-white — signal depth, tradition, and care. This primes the user before they read a single word.
Playfair Display for headings, Lato for body
DECISION 02 / TYPOGRAPHY
Playfair is a classical serif with real presence. It communicates seriousness and tradition without being heavy or academic. Lato provides clean, accessible readability for longer explanatory copy. The pairing reflects the dual nature of the service: rooted in tradition, delivered with modern clarity.
One CTA: "Request Class Details" — not "Sign Up Now"
DECISION 03 / CTA
Multiple CTAs create friction through choice. More importantly, "Request Class Details" rather than "Sign Up Now" signals the enrollment process is considered, not impulsive. That framing filters for students who are serious, which is exactly who this practice is for.
Testimonials before the final CTA — always
DECISION 04 / TESTIMONIAL PLACEMENT
On the homepage, Offerings page, and FAQs page, testimonials are placed immediately before the closing CTA. By the time a visitor reaches that point, they've read what the practice is, who it's for, and how it works. Testimonials at that moment confirm — they don't introduce. The CTA is effective when trust is already established.
No pricing on the homepage, no urgency copy. Urgency copy — "Only 3 spots left!" — attracts the kind of decision that doesn't hold up when someone realizes this is a committed, philosophical practice rather than a drop-in fitness class.
"
— DECISION RATIONALE · UI + Content Strategy
50–60 %
Estimated reduction in operational onboarding time per inquiry
Pre→informed
Inquiries now arrive with context — no longer starting from zero
SEO discoverability established from zero — Google Search Console live
Measured outcomes
Honest caveat: Because this is an early-stage live service, I don't have pre- or post-analytics data with statistical significance. These outcomes are based on observed behavioral patterns and founder-logged inquiry notes. I am currently building the measurement infrastructure for Phase 2.
0→live
Phase 2
Foundation built for automated enrollment — IA accommodates payment layer without rebuild
15 –20
Active paying students — live, real, retained
Average retention held across both batches — the practice works
5 – 6 mo
What was built,
what comes next
Every phase decision came from a product question: what does the service actually need right now, and what would adding too early break?
Trust Infrastructure
PHASE 1 - LIVE NOW
Goal: Replace manual explanation with a reliable digital source of truth. Keep enrollment human-led while that trust layer is built.
Clarity-first website handling the recurring questions. Manual enrollment is preserved — every student speaks to me before joining. That manual step isn't a compromise; it's intentional at this stage. In the early months of a practice like this, the founder-to-student conversation does work that a form can't: it filters for seriousness, catches misalignment early, and builds the kind of initial trust that turns into long retention.
Payment + Registration Automation
PHASE 2 - PLANNED
Goal: Remove the founder from mechanical steps while preserving judgment calls.
Website-based enrollment with payment gateway (Stripe/Razorpay). Automated confirmation and onboarding email sequence. Structured intake form replaces the current manual conversation. The IA built in Phase 1 accommodates this layer without a rebuild — this was a Phase 1 design constraint.
KPI: Inquiry quality + reduction in onboarding conversation time
KPI: Enrollment conversion rate + founder time freed
Community Expansion
PHASE 3 - FUTURE
Goal: Serve a larger audience without a proportional increase in founder bandwidth.
Larger batch sizes or a cohort-based model. Student community dashboard or resource library. Potential async content layer alongside live classes.
KPI: Revenue per founder-hour + student lifetime value
Four things I'd change if starting today
Set up analytics before launch, not after
IN HINDSIGHT · 01
I launched without proper analytics infrastructure. I have behavioral observations — not data. For Phase 2, I'm adding event tracking on key funnel steps: page visit → FAQ read → CTA click → inquiry submitted. Starting earlier would have given me a cleaner before/after picture.
Test the Inquiry Form sooner
IN HINDSIGHT · 02
The current CTA leads to a contact form. I haven't tested whether a more structured intake form (with qualifying questions) would improve inquiry quality further. This is a live experiment for Phase 2 — I should have set it up as a test from day one rather than a later iteration.
Establish an SEO baseline before launch
IN HINDSIGHT · 03
I set up Google Search Console after launch. Starting with keyword tracking from before Day 1 would have given me a cleaner before/after SEO picture. Lesson learned — infrastructure before launch, not after.
Document Research More Formally
IN HINDSIGHT · 04
My "research" was real — 30+ conversations, observed patterns, and form data — but I didn't formalize it at the time. If I'd started a simple inquiry log from the first conversation, the insights would be the same; the documentation would be stronger for a portfolio context.
What this project
demonstrates about
how I work
The most useful thing about this case study is that the product is real. Not a redesign concept, not a hypothetical — a live service with paying students, a measurable before state, and documented decisions.
I designed this as the sole UX practitioner and as the founder. That combination meant every design decision had direct consequences — if the expectation-setting copy didn't work, I saw it in the drop-off data. If the FAQs didn't cover the right questions, I heard about it in the next WhatsApp conversation. That feedback loop made the work sharper.
What the documentation above shows: research that came from real inquiry data, design decisions that traced back to specific findings, a phased approach built around what the service actually needed at each stage, and honest accounting of what I'd measure differently.


Live Product
Solo Designer
Service Design
AI-Augmented
UX + Business Alignment
2025

Vaidehi Yelkawar
UX Designer · Service Design · MBA
HOME
WORK
ABOUT
