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.
  1. Filter for fit.

  2. Establish value before cost.

  3. Answer recurring questions at scale.

  4. Set philosophical expectations early.

  5. Build SEO discoverability.

  6. 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

Preinformed

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.

0live

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