Standing up Atlas
Atlas is the design system powering Walmart's internal product suite — a shared foundation for hundreds of teams building at scale.
The problem
Walmart's internal products were built across dozens of teams, each maintaining their own component libraries, design files, and visual conventions. The result was inconsistency at every level — from typography and spacing to interaction patterns and accessibility standards. Shipping new features required redundant effort, and quality varied wildly between surfaces.
The ask was to build a single shared foundation: one component library, one Figma library, one set of standards. Atlas.
Starting with audit
Before building anything, we spent six weeks auditing the existing landscape. We catalogued over 400 unique button variants, 60 different type scales, and 12 separate icon sets in active use. The audit surfaced the real scope of divergence and became the foundation for every decision that followed.
We used that data to prioritize ruthlessly — starting with the components that appeared most frequently across products and had the highest impact on consistency.
Building the core
The first release of Atlas shipped 24 components covering the most common UI patterns: buttons, inputs, selects, modals, tables, and navigation. Each component was built with accessibility as a constraint from the start, not a retrofit.
We established a token system grounded in semantic naming — color.text.primary rather than gray.900 — so teams could adopt Atlas incrementally without breaking their existing implementations.
Adoption as the real work
Shipping the library was the easy part. Getting teams to adopt it was not. We ran office hours, embedded with product teams during critical sprints, and built migration tooling that automated the most tedious parts of upgrading.
Within 18 months, Atlas was powering over 60% of Walmart's internal product surface area. The more meaningful metric: teams reported a 40% reduction in design-to-dev handoff time on projects that used Atlas end-to-end.
What I learned
A design system is a product. It needs a roadmap, versioning, release notes, and a support channel. The teams that treated it like infrastructure — something that just exists — struggled. The teams that treated it like a product they were partnering with moved fast.
The hardest decisions were always about what to leave out. Saying no to one-off component requests, holding the line on token naming conventions, and keeping the API surface small enough to be learnable — that discipline is what made Atlas durable.