Scaling Telecom Commerce at T-Mobile

Skills Applied

Design | Research | UXUAT | Stakeholder Alignment

Softwares Used

Figma | Jira

User/Consumer Base

E-Commerce

Industry Experience

Telecom

The Problem

T-Mobile operates across multiple design systems that diverge at the atomic level. These systems are owned and maintained by an external agency (Kettle), with a rigid intake process that makes even minor changes slow and bureaucratic.

As a result:

• Designers routinely detach components to get work done

• Variants are rebuilt locally and scattered across files

• Deprecated atoms, molecules, and organs are removed without warning

• Teams are left scrambling to relink broken components

• Poor file hygiene makes components difficult to find or reuse

The net effect is predictable:

Designers stop trusting the system, velocity drops, and inconsistencies multiply.

Our team’s mandate

Our UI team exists to shield product and UX designers from this chaos by:

• Building organ- and organism-level components using Kettle’s atoms

• Fixing breakages immediately when Kettle deprecates assets

• Gradually eliminating reliance on Kettle’s organ-level components

• Creating a Toolkit that designers can actually ship with

My Role

I worked as a Senior UI Designer on the E-commerce team, partnering closely with UX and product designers across PDP, PLP, Cart, and Checkout experiences. As part of a 6-person Toolkit team, I focused on building organ- and organism-level components that could scale across core commerce flows.

My responsibilities included:

• Designing and maintaining Toolkit components and screens

• Rebuilding existing e-commerce flows using the Toolkit

• Creating missing variants and components as gaps surfaced in real product work

• Reviewing and QA’ing externally managed system updates

• Supporting UX designers by unblocking work in-flight

Rather than designing components in isolation, I built and validated them directly within live e-commerce experiences.

How Work Actually Got Done

We started by auditing end-to-end e-commerce flows including PDP, PLP, Homepage, Cart, and Checkout. Components were built or extended as they appeared in real usage, ensuring the system evolved alongside actual product needs.

In addition to static components, we incorporated prototyping directly into organs, organisms, and screens, allowing designers to:

• Validate interactions early

• Communicate intent more clearly to partners

• Reduce rework caused by ambiguity in complex flows

Tools

• Figma for component design, screen builds, and interactive prototyping

• Jira for tracking fixes, deprecations, and coordination

Working With Kettle

Kettle managed foundational assets and regularly deprecated components with little advance notice.

To reduce disruption:

• I joined their sprint demos

• Asked directly about upcoming deprecations

• Flagged missing variants that designers still needed

• Communicated changes immediately to internal teams

This reduced surprise breakages and helped designers recover faster.

The Most Complex Area: Cart & Checkout

Cart and Checkout were the most complex areas due to multi-step flows, pricing logic, order summaries, and state-based variations. These experiences surfaced the highest number of edge cases and missing variants.

I rebuilt large portions of these flows using the Toolkit, designing components and interactive prototypes that accounted for:

• Checkout stages and transitions

• Order summaries and purchase breakdowns

• Status changes across the funnel

This work stress-tested the system and ensured it could support real-world e-commerce complexity at telecom scale.

Impact

By grounding the Toolkit in real e-commerce flows and interactive prototypes, designers were able to move faster with fewer workarounds.

Based on direct feedback from UX designers and team leads:

• Average rebuild speed improved by ~70%

• Fewer detached components were created

• File hygiene and findability improved

• Turnaround time for core commerce work decreased despite a heavy intake process

Constraints

• No control over atoms or molecules

• Frequent uncommunicated deprecations

• Dependence on an external agency with delayed processes

These constraints shaped every decision and required constant triage.

What I’d Change If I Had More Control

Own Atoms and Molecules Internally

I’d establish internally owned atoms and molecules instead of relying on externally managed foundations. This would reduce breakages from unexpected deprecations and give product teams a stable base to build on without constant rework.

Reduce Dependency on External System Decisions

Critical product flows shouldn’t be vulnerable to changes outside the organization’s control. Bringing more of the system in-house would improve speed, predictability, and accountability across teams.

Design Systems Around Real Product Flows

Rather than treating the system as a standalone artifact, I’d continue grounding it in real, end-to-end product experiences like PDP, Cart, and Checkout. Systems scale best when they’re validated against real complexity, not idealized use cases.