Leading the Way for Under Armour's Design System Component Library

- Context
- Under Armour
- Role
- Architect and maintainer
- Built with
- React, TypeScript, Storybook, Next.js, Playwright, Figma
- components
- 30+
- engineers on the system
- ~12
- design QA rounds
- 3 → 1
- accessibility
- WCAG AA (audited)
The problem
Under Armour's eCommerce site is built by a lot of hands. Multiple teams ship into the same storefront every week, and for a long time the shared component library lived off to the side in its own repo. Every library change meant a separate ticket, a hand-built package, and a manual test inside the real app before anyone could publish it. So people didn't bother. They styled around the library instead, one-off overrides piled up, and the site slowly drifted away from what designers had drawn in Figma.
Design QA was where you felt it. A feature would go through three rounds of "this padding is off, that color is wrong" before it matched. Nobody was doing bad work. There just wasn't a single source of truth that both designers and engineers trusted.
My role
I architected UA's React component library and I maintain it alongside the rest of our eCommerce web team, about 12 engineers who use it and contribute to it every day. I also lead and mentor a group of 9-10 frontend engineers, so a big part of the job was making the system something people wanted to use, not something they had to be policed into.
Key decisions
Make the library the source of truth, and mean it. We set a simple rule: product code doesn't override component styles. That only works if the components are actually right, so we mapped Figma naming one-to-one to CSS custom property tokens for spacing, color, and typography. A designer's "spacing-m" is the same "spacing-m" in code. I also used Figma MCP workflows to keep the two in sync in both directions, so coded components could port back into Figma for documentation and reuse.
Turn exceptions into variants. When a team needed something the library didn't do, usually on a deadline, the answer wasn't a one-off override. If the need was real and likely to come back, it became a proper variant in the component. That kept the rule from feeling like a wall, and the library got better every time someone pushed on it.
Give designers a seat before release. We added a step where designers sign off on components before they ship. They welcomed it. It gave them a say at the point where it actually mattered, instead of after a feature was already in QA.
Own the hardest component instead of renting it. Our carousels ran on a third-party library that didn't play well with our server-side rendering work and added weight we didn't need. I replaced it with our own carousel and media components: infinite looping, responsive breakpoints, keyboard navigation scoped so it doesn't hijack the page, and vertical scrolling with virtualization for shoppable video. I rebuilt our story-style player with custom autoplay, per-slide timing, and progress tracking, migrated the rewards, product recommendation, and social product carousels, and then removed the old dependency completely.
Make the system safe to change. I brought the library into the main eCommerce monorepo as a workspace package, so a library change and the feature that needs it ship in the same pull request, tested in the real app, while the library keeps its own versioned publishing. I unified our Storybook with theme switching and per-PR previews so designers can review changes before they merge, and repaired 22 broken stories along the way. For visual changes I built a Playwright visual regression tool and an AI skill that turns a plain-language request into a test. It caught real differences between the old and new carousels before they reached customers.
Teach the agents, too. As AI coding agents became part of how we work, I wrote AGENT and SKILL files that point every agent at the library's docs and conventions. Agent-written code reaches for our components instead of inventing new ones, which is the same rule we hold people to.
What happened
- The library now has 30+ components, adopted across every UA eCommerce web property and co-maintained by the whole web team.
- Design QA dropped from three rounds to one.
- When teams use components as designed, builds match Figma nearly 100%. The library even started catching inconsistencies in the Figma files themselves.
- Accessibility is built in: WCAG AA compliance confirmed by a third-party audit, with ARIA roles and attributes throughout the components.
The bigger change is cultural. The library stopped being "the thing you work around" and became the fastest way to ship something that looks right.
What I'd do next
Two things. First, extend the agent playbook so Figma MCP workflows apply designs to the same standards our coding agents already follow, closing the loop from design file to merged code. Second, generate tokens for Figma and code from a single source with a proper token pipeline, so a change to a color or spacing value lands everywhere at once instead of being kept in sync by hand.
Further reading
- 42% of React Code Is AI-Generated. Your Design System Isn't Ready.With 42% of React code now AI-generated and climbing to 65% by 2027, design systems are the last line of defense against fragmented, hallucinated component code.
- Design Systems as Living ArchitectureDesign systems are now critical infrastructure. The W3C Design Tokens spec, React Server Components, and micro-frontends are reshaping component architecture. Here's what that looks like from inside an enterprise eCommerce stack.
