Apeiron Design Systems - component architecture for enterprise scale
T-Mobile's first unified cross-platform design system, consolidating three legacy systems into one. My work: the research and documentation layer that turns a component library into something teams actually adopt.
ROLE
TIMELINE
SCOPE
HEADLINE OUTCOME
UX Designer II ( Research & documentation)
Jul 2022 – Jan 2023 (concurrent with MBA)
85% of designers building consistently across platforms # check this
Design tokens · Core components · WCAG 2.2 specs · Web, iOS & Android
The shipped documentation. The Dialog overview page in Apeiron's documentation site — component shown in light and dark themes, with direct links to Figma files, Storybook, and platform repos for both T-Mobile and Metro. Documentation as a product, with its own navigation, audience, and handoff paths.
Three design systems. One company. Zero shared language.
01 Context
T-Mobile's product surface spans web, iOS, and Android, built by teams who had inherited three separate legacy design systems. Same brand, three different buttons.
The cost wasn't aesthetic — it was operational. Designers re-decided solved problems. Developers rebuilt components that existed elsewhere under a different name. Accessibility was re-litigated per team. Apeiron was the answer: one unified, token-based system to replace all three.
My role sat at the layer where design systems succeed or quietly die: research and documentation. A component library without adoption is a Figma file; documentation is what turns it into infrastructure.
Documentation that works without a designer in the room
02 The problem
That test drove three requirements: consistency of structure (every component documented the same way), platform honesty (where Web, iOS, and Android genuinely differ, say so — don't average it), and accessibility as specification, not suggestion.
The test for every page I wrote: can a developer who has never met me build this correctly, on their platform, the first time?
Enterprise scale changes what documentation has to do. At a startup, a developer can walk over and ask. At T-Mobile's scale, the documentation is the conversation — across teams, time zones, and platforms.
What was mine on a team effort
03 MY CONTRIBUTIONS
Finding
Decision
Result
Every inquiry asked the same 6–8 questions (schedule, level, language, fees, equipment, trial). The information existed — it just wasn't structured anywhere findable.
Restructure the entire pre-enrollment journey around answering questions before they're asked: rebuilt information architecture, a single registration flow with Terms & Conditions built in.
Inquiries now arrive pre-informed. Onboarding conversation time cut 50–60%.
Design systems are inherently collaborative, so let me be precise about ownership. On Apeiron, I personally:
Finding
Decision
Result
Competitors split into two camps: high-volume marketplaces competing on price, and personal teachers competing on trust. The middle was empty, and the marketplaces' own reviews showed students missing personal attention.
Position deliberately as small-batch and personal: limited cohort sizes, a single intentional evening batch instead of scattered slots, premium-of-one pricing — raised for new students, honored for existing ones.
Free pilot participants converted to paying customers within 2 months of launch. Average retention reached 5–6 months in a market where month-to-month churn is the norm.
Finding
Decision
Result
Drop-off risk concentrated at the start of each class and in the gaps between classes — students arrived rushed, and silence between sessions read as indifference.
Design the ritual layer: a consistent class-opening protocol (students settle in Shavasana before class begins) and a warm, brief, predictable communication cadence between sessions.
The experience became recognizable and calm — the qualities students cited when they stayed. Retention is the metric this shows up in.
Designing the full arc, not just the screens
04 The system
The enrollment flow across three system states. Pre-website: every inquiry triggered a manual explain-and-clarify loop. Phase 1 (shipped): the website carries that conversation, so inquiries arrive aligned. Phase 2 (designed, ready to build): direct registration, integrated payment, automated confirmation — the backstage fully systematized.
I launched assuming more schedule options meant more value, multiple batches, and maximum flexibility. The service data said otherwise: scattered slots fragmented the cohort, diluted the group energy that makes a live class worth showing up for, and multiplied my operational load without adding students. I consolidated to one intentional evening batch. It felt like shrinking the product; it was actually the product decision that made retention possible. Flexibility is a feature only when users value it more than what it costs them.
A wrong assumption I had to unwind
The deliverable wasn't a UI — it was a service blueprint covering five stages, each with designed frontstage moments and backstage operations:
Discovery — content strategy across Instagram, Facebook, and YouTube Shorts built around a clear teaching identity, plus SEO discoverability built from zero so the service could be found, not just followed.
Inquiry → enrollment — one structured registration flow (form, expectations, terms, payment) replacing open-ended message threads. Expectation management designed in: level, language, equipment, and class protocol stated upfront.
First class — a designed first-session experience, because the first class is the product's onboarding screen. Protocol, preparation, and welcome communication all standardized.
Ongoing practice — scheduling, payment, and group communication systematized into repeatable workflows; a monthly thematic structure (an "asana of the month") giving the service a content rhythm students can feel.
Retention & renewal — feedback loops informing iterative service improvements, batch consolidation when data showed scattered slots diluted the experience, and special sessions offered only when genuinely warranted.
Registration wireframe. The form asks about practice history and injuries upfront — qualification designed into the form itself, replacing what used to be a 20–30 minute manual conversation. #add SC from something else here
Homepage wireframe. "Who This Practice Is For" sits directly under the hero — expectation-setting as information architecture. Filtering happens on the page, before the first message is ever sent. Live at vaidehiyoga.com.
Where AI made this faster and where it didn't get a vote
This project is where my AI-augmented process became a documented system rather than an experiment. The honest accounting:
05 The AI-augmented workflow
AI ACCELERATEd
Content production: first drafts of class communications, social content, and service copy — rewritten to my voice and standard.
Competitive scans — first-pass landscape mapping across 15+ services before I go deep manually.
Synthesis: clustering inquiry threads, student feedback, and competitor notes into candidate themes — hours instead of days.
Repeatability: reusable prompt workflows for recurring analysis, so rigor didn't depend on my energy that week.
I DECIDED
The positioning call: small-batch premium over volume — a strategy decision AI can argue both sides of, which is exactly why it can't make it.
The framing: that this was a service-system problem, not a marketing problem.
The framing: that this was a service-system problem, not a marketing problem.
The voice: every student-facing word. Warm, brief, and mine.
AI synthesis surfaced "price sensitivity" as a dominant theme and nudged toward discount-led growth. The source data said something subtler: people questioned price before understanding the service, and stopped questioning it after a structured trial experience. I killed the discounting direction and invested in expectation-setting instead — then raised prices. Retention went up, not down. That's the difference between AI output and design judgment, and it's why the ~40% acceleration figure refers to speed of synthesis and production — never to decision-making.
A theme I killed, and why it matters
Measured on a living practice
06 Outcomes
50–60%
2 months
5–6 mo.
reduction in onboarding friction — structured flows replaced open-ended message threads; inquiries arrive pre-informed.
from launch to converting free pilot participants into paying customers — validated product-market fit on real money.
average customer retention through iterative, feedback-driven service improvements.
~40%
From zero
Phase 2
faster research synthesis and content production via the documented AI-augmented workflow.
SEO discoverability and a three-platform content system (Instagram, Facebook, YouTube Shorts) built from nothing.
operational foundation ready for automation — enrollment, scheduling, and payments systematized for scale.
Because nothing here was hypothetical. Every persona was a person who paid me or didn't. Every flow was tested by someone who could simply leave. When a designer says "I'd validate with users," I can say: I did — and they stayed, for months at a time.
What I'd do next: Phase 2 automates the backstage, enrollment confirmations, payment reminders, and scheduling, while keeping every human touchpoint human.
07 What this project proves
Why a living practice belongs in a product portfolio
Next case study →
Apeiron Design System - component architecture for enterprise scale
© 2026 · Designed by Vaidehi Yelkawar, accelerated by AI