Designing a Component Platform at Enterprise Scale

Context

att.com supports a wide range of business needs, from upper-funnel acquisition to small business conversion. Over time, these needs outpaced an older Sketch-based design library.

New business requirements, increased A/B testing, and a migration to Figma exposed gaps in consistency, scalability, and component ownership. What was needed was not a refresh, but a durable component platform that teams could rely on under active experimentation.

My Role & Ownership

I worked as a Senior UX Designer embedded within experimentation and creative workflows. My ownership focused on individual components, contribution standards, and usage strategy, as well as structuring the Sketch → Figma migration.

Rather than designing a full system in abstraction, I focused on making components usable, governable, and scalable in day-to-day production.

The Problem

The existing library could not support evolving business needs. Teams increasingly created one-off solutions to meet experimentation timelines, introducing inconsistency, accessibility risk, and rework.

Without clear standards or scalable components, speed and quality were in constant tension.

Constraints (Enterprise Reality)

• Legacy code constrained component flexibility
• Accessibility requirements applied across all variants
• Stakeholder disagreement around standards and ownership
• Tight timelines driven by continuous A/B testing

My Approach

Designing for Scale, Not Perfection

Each component was designed to meet immediate business needs while remaining flexible under experimentation. Decisions prioritized reusability, accessibility, and predictability over bespoke visual solutions.

The goal was not visual consistency alone, but operational consistency.

Sketch → Figma Migration

As part of the migration, I defined component structures, variants, and responsive behaviors in Figma to reduce ambiguity and make intent legible across teams.

This work focused less on tooling preference and more on clarity of usage at scale.

Establishing Usage Standards & Review

To prevent fragmentation, I helped define standards for how components should be used, participated in governance and review discussions, and worked with creative teams to align on when to reuse vs extend components.

The goal wasn’t control — it was predictability and trust.

Component Platform Overview — att.com

Click to enlarge

Tip: click/tap to zoom. ESC closes.

Speed Test Tool — Component Anatomy & Decision Boundaries

Click to enlarge

Tip: click/tap to zoom. ESC closes.

Component Governance & Usage Flow

Click to enlarge

Tip: click/tap to zoom. ESC closes.

Scale & Reach

• 5–8 core components
• Used across all att.com surfaces
• Adopted by upper-funnel teams, small business teams, PMs, strategists, and creatives
• Designed for desktop, tablet, and mobile

These components became default building blocks rather than optional assets.

Impact

This work improved component adoption across teams, reduced creative rework, and enabled faster experimentation. Strategists and PMs were able to rely on shared components to execute tests more efficiently and connect execution more directly to KPI outcomes.

The impact was cumulative rather than tied to a single launch — a defining characteristic of platform work.

What Made This Staff-Level Work

This case wasn’t about inventing a new UI pattern.

It was about:

• Designing components that could survive organizational change
• Balancing governance with speed
• Creating standards that people actually wanted to use
• Making experimentation easier without sacrificing consistency or accessibility

This is the kind of work that only shows its value over time.

Reflection

This project reinforced that design systems succeed through adoption, not elegance. Components that flex for real business needs become infrastructure; those that don’t are bypassed.

Designing for longevity, governance, and leverage continues to shape how I approach platform and AI-adjacent work.