Design Systems & Prototyping at Nike

The Problem

116 different buttons. 470 different icons. 97 different uses of type. That is one audit of Nike's consumer surfaces, and it is what happens at this scale without a shared system: thousands of digital products, internal and external, each drifting from the last until design and engineering stop speaking the same language.

What I Built

It started with SNKRS, in 2016. Four of us wrote Nike's original Core Style Sheet and Tour Guide for the global launch. We built it to ship one product.

It outlived the product. Other teams reached for that sheet because it was the one that already existed, and a thing drawn for a single launch quietly became what Nike designed from by default. That is how it grew into the One Nike Design System: one shared language, a consumer side for the storefronts and an enterprise side for the internal tools. Alongside the systems, I designed Bowerman, Nike's prototyping platform, and built its first version; Jacob Ross then built and scaled it with me. I started on that style sheet as one of four engineers. Eight years later I was a Principal setting the direction of Nike's design-system practice. What I helped seed became the default other teams designed from, and Bowerman was the platform they prototyped on.

On the enterprise side, that work became the shared design language for 86,000 employees, the common vocabulary under an internal ecosystem Nike's own audit stopped counting at 2,600+ apps and sites.

Inside the Enterprise System (DEE)

That enterprise system had a name: DEE, the Digital Employee Experience, which ran Nike's HR and workplace products the way the consumer system ran the storefronts, the same discipline turned inward on the tools an employee uses to get paid and take time off. I led the design-systems work on it with a small team. None of it started from a wish to be consistent; it started from what the real HR products needed, and became parts any team could build from.

Everything lived inside one NIKE, Inc. Human Resources shell: a shared masthead and a fixed top navigation (Pay and Benefits, Time and Vacation, Career, Policies and Forms, Networks) that every internal product inherited. Solve the shell once, and every team downstream starts in the same place.

That navigation was not a guess. Four of those sections (Pay and Benefits, Time and Vacation, Career, and Policies and Forms) went out to Nike's Experience Insiders panel, roughly 600 employees who volunteered to test real prototypes. We gave members one task, finding Employee Discounts, and built it four ways, one per navigation pattern, filed under color codenames (Cyan, Magnolia, Volt, RacerBlue), then ran it past 19 members in the first pass, scored on task success, difficulty, and preference. Two patterns pulled ahead, each getting about nine in ten of them to Employee Discounts without trouble; the full-page hamburger overlay landed last. But the readout did more than crown a winner. Across every variant the second-level menu read as too much information, and people kept expecting Employee Discounts under Benefits, not wherever the taxonomy had filed it. So the call was to thin the menu and fix where things lived, not just pick a pattern. We shipped the structure people actually found their way through, not the one that won the room, and it went live on the global HR website.

The core was the DEE Component Library v1: about twenty component families, each with its own states and variants, specced against the real HR products it had to serve (the HR portal, onboarding, and NikeU among them), not screens invented to show the components off. Speccing against those live products surfaced where they broke down first: the empty states, the confirmation dialogs, the tables no one had styled. So v1 was drawn to cover exactly those failure points, the places a system comes apart, for everything from heroes and carousels down to the table and tout. Most systems draw the happy path and stop; this one started at the edges.

Consistency starts with type. The DEE type scale set the ramp and the vertical rhythm: Trade Gothic at 60 point for page titles in all caps, Helvetica Neue for everything under it (H1 at 36 point, H2 at 20, body at 16 on a 28-point line), with a 100 / 50 / 25 pixel spacing system marked down the margin. The decisions were written down once, not relitigated on every screen.

What made it a system and not a sticker sheet was governance, the part that keeps a system alive after the launch buzz fades. In a Confluence space called Design System at Nike, we ran a real intake and release path, the Component Contribution and DS Release Process: a request form for any team that needed something new, a governance workshop and product kit to onboard them, and later the migration from Sketch to Figma. A component was not "in the system" until it came through that door and held up against a real product need, which is how the system kept its shape across the teams building on it for eight years instead of fragmenting the moment people stopped watching. None of those teams reported to me; the system held because it earned its way in, not because anyone was made to use it, which is the harder kind of adoption to win. The IA questions we settled with the Experience Insiders panel; the component questions we settled at that same door.

The 2020 One Nike Audit

The enterprise system grew by accretion, one launch's style sheet at a time. The three numbers this piece opened on came from the other side of the house. In early 2020, Nike's Global Digital Design studio audited every consumer surface (Nike.com, the Nike App, SNKRS, NRC, NTC, Retail, Email, Fit, and Adapt) and put the drift on the record before anyone drew a fix. The audit deck at the top of this page walks through the strongest slides, and those numbers are the argument for One Nike:

• 39 different uses of color, narrowed toward a core of black, white, and gray plus one status green and one status red, with every value rated for contrast against WCAG 2.0 AA. The deck scores each swatch, from near-black at 18.88:1 down to the status pair at about 4.5:1.
• 97 different uses of typefaces, thinned to 26 sizes, with legacy Trade Gothic retired from headlines and CTAs.
• 470 different icons, headed for one family that holds up in light, dark, and transparent contexts.
• 22 vertical spacing sizes, reduced to 8 on a 12-pixel base grid.
• 116 different buttons, consolidated into 5 types, 4 styles, and 3 states. The same pass collapsed 39 card types into four categories, 17 carousels into three, and unified 14 navigation patterns.

Every cut followed the same rule: cluster by function, keep the one canonical and accessible form, and rate every survivor against a standard, not a preference. Take each count from dozens down to a handful, and design and engineering stop arguing about which component is right and start building from the same source of truth. That is the consolidation discipline I ran with DEE on the enterprise side. The consumer audit was the studio's collective work, and this deck is the clearest record I have of it: the same case argued outward for the storefronts that I was arguing inward for DEE.

The Prototyping Platform (Bowerman)

Systems name the parts. Prototyping is where you find out whether they hold together, and that had a home I designed and first built, then scaled together with Jacob Ross. Bowerman solved a specific problem: a static comp only ever pictures what might ship, so in the handoff to engineering the design and the shipped code drift apart. Bowerman had Nike's teams prototype real, coded pages instead of comps, and it wrote the design system straight into the markup.

It was not a drawing tool. It was a live code editor with a real Nike page rendering beside it, so a prototype was the actual HTML a build team could read and ship from. The parts came from the system, not from scratch: the grid is the NCSS design system's own classes, the icons are Nike's g72 glyph set, and the accessibility hooks (an aria-label on every navigation link) are in the markup because they were in the system. Because a prototype is only worth anything if you can iterate on it, Bowerman versioned every page, so a design could move forward without losing the one before it.

This was the loop the rest of the work ran on. The system defined the parts; Bowerman was where teams assembled them into something real, checked it against a live render, and versioned it forward, then handed engineering the very markup that would ship. Prototype and product could not drift apart, because a team shipped from the prototype directly instead of rebuilding a comp by hand.

Impact

One shared design language and one prototyping platform behind Nike's digital products, internal and external, for eight years. It is the rare kind of work whose success is measured in what stops happening: the drift, the duplication, the standing meeting where three teams defend three different buttons. So measure it the only honest way, by what survived: roughly twenty component families that earned their way through the governance intake, and a design language still standing eight years on, long after the redesign cycle that usually erases this kind of work. No one pinned a formal cross-team adoption number to it, since the org kept restructuring out from under the count, but a system that outlives that many reorgs has made its own argument. And the value compounds: a new internal product now starts from that shared shell and those component families instead of a blank page, so the slow work of deciding what a button or a table should be is already done before a team starts. The screens were never the point. I helped seed the design language Nike works from, and I designed and first built the platform it prototypes on, then scaled it with Jacob Ross.

The System Today

The lineage lives on as Podium, Nike's current design system, described in its own words as "our connected source of truth." That is the same principle I now build Calafai on: you cannot trust an output if you cannot trust the system behind it.