Nike CMS
Building the Content Management System behind Nike's global digital presence, across nike.com, SNKRS, Nike+, and more.
Overview
Context
Nike's content was running through a stack of off-the-shelf publishing tools. They were expensive, and getting them to actually do what Nike needed meant layering on complex workarounds no vendor tool was built for. Those workarounds broke often, and when they broke, an actual person had to fix it, usually at a bad time. Multiple live-revision scenarios, mistakes, corrections mid-launch. Content needed to go live on a schedule, so authors were staying up in the middle of the night to launch things safely on weekends.
Nike decided to build its own CMS instead of continuing to bend outside tools to fit. Engineering had already built a proof-of-concept that confirmed the idea worked: Nike could publish content through something built in-house. It could handle text and a single image, a solid foundation to build the rest of the system on top of.
I came on in October 2016 as a contract Sr. UI/UX Design Lead, hired to take that POC and build the actual UX around it. The scope I was hired for was CMS, full stop. There wasn't a broader mandate handed to me on day one. What happened after is that the system-level thinking that went into designing CMS itself, restructuring flows, breaking authoring into contextual sections, building consistent components, ended up being useful to other teams building their own tools. That's what pulled the work wider, not a scope change from above.
By 2018 I'd been hired on full-time and promoted to Lead Product Designer, working on the same body of work. About a year and nine months total, start to finish.
My Role
What I designed
The core authoring flow and every screen inside it: sections broken out contextually by function, options, settings, and tools surfaced only where they were relevant
Approval gateways and status indicators, so anyone looking at a piece of content could see exactly where it sat in the pipeline
The block editor, including an inline multi-viewport preview across languages and Nike's various apps
The integrated language tool, with its own workflow and automated push/pull to a third-party translation agency
Section-based permissions, so a team like SEO could work inside their own scope without touching content they weren't responsible for
The early foundation of Nike's enterprise design system, later spun into its own formal team with company-wide rollout to internal tools
What I led
Design of the entire CMS, including design operations, scheduling, review cycles with leadership, and cross-functional partnership across multiple product and engineering teams
Author interviews and shadowing across multiple content categories to find out what was actually broken, not just what was ticketed
Internal pushback on the idea that enterprise tools don't need the same design attention as consumer products
Off-the-shelf publishing was costing Nike money and costing its people sleep
Nike was running its content on off-the-shelf publishing tools that were expensive, hacked together, and breaking in ways that showed up in people's lives, not just their workflows. Authors were staying up through the night to launch content safely on weekends. Approvals got missed. Things went live that weren't ready.
Nike's engineering team had already built a proof-of-concept, enough to confirm they could publish content internally instead of paying for the old tools. I was hired to take that POC and turn it into an actual system, one that could handle real authors, real approval chains, real languages, at Nike's scale.
I spent time sitting with the authors who'd be using it, watching what actually broke their days. Most of what I found wasn't subtle. People had no way to see what state a piece of content was in or who needed to approve it next. That gap, more than anything else, shaped the system I built.
Partway through, my design director and my UX research partner both left the project. I became the sole design owner of an enterprise content management system, without anyone reviewing my work for quality, and without a research partner to run studies with. The questions I got asked changed from "is this good" to "does this work."
The system, called IRIS internally, now runs content across nike.com, SNKRS, Launch, Nike+, and Bootroom. It still does, today.
Keep reading below for the full story
Design Problems
Nobody could see what state their content was in
An author would have a piece of content somewhere in an approval chain with no way to check where it actually stood. Content occasionally went live before it was supposed to, because there was no status system telling anyone otherwise. This wasn't a subtle research finding. Sitting with authors made it obvious fast: the basic, expected things weren't there, and their absence was making people's jobs miserable.
The old tools weren't built for how Nike actually published
They were general-purpose CMS platforms bent into shape with workarounds, not built around Nike's own approval structure, language needs, or release cadence. Every workaround was one more thing that could break during a live launch.
Language and global scheduling were a mess
Content had to go out in multiple languages on asynchronous schedules across regions. Getting a translation through a third-party agency and back into the right place at the right time was manual and error-prone.
Asset management was its own broken thing entirely
Cumbersome, clumsy, disconnected from the rest of the authoring process.
Challenges
Turning a promising proof-of-concept into a full system
The POC proved Nike could publish something internally, a strong starting point, but it still needed a workflow, approval logic, language handling, and asset management built around it. There wasn't a dramatic insight that unlocked the design. It was closer to: everyone already knew what was missing, and the job was building it well, at the scale Nike actually needed.
Coordinating across more than one engineering team
CMS wasn't one team's problem to solve. Core platform engineering, the language/translation integration, and the teams responsible for getting content into each Nike property all had to move together. None of that consolidation happened automatically, it took real coordination to keep the design coherent across all of it.
Losing my design director and research partner mid-project
Partway through, both left. I became the only designer on an enterprise CMS, with no one left to review my work on quality. The senior PM I kept working with still fed me functional requirements, deep knowledge about what the system needed to do that I wouldn't have had on my own, but the conversation shifted from "is this good design" to "does this meet the requirement." I also lost my research partner, so what research I could still run got a lot more informal, done on my own, without the structure a dedicated researcher would have brought.
Making the case that enterprise tools deserve real design attention
There's a common assumption inside most orgs that internal tools don't need the same care as anything customer-facing. I don't buy that. A customer uses a product for a few minutes at a time. An employee lives inside an internal tool all day. It's their actual daily touchpoint with the brand, and shipping something cheap there is a statement to your own people, not just a UX shortcut. I gave internal presentations making that case and pushed to bring real Nike-level design polish to CMS instead of treating it like a backend utility.
Solutions
A workflow with actual state, not a black box
Every piece of content carries visible approval gateways and status indicators, so anyone looking at it knows exactly where it sits and what happens next. That single change addressed most of what was making authors' lives difficult, work going live before it was ready, no visibility into where something stood in the chain.
Authoring broken into contextual sections instead of one dense tool
Options, settings, and controls only show up where they're relevant to what an author is actually doing at that step, instead of surfacing everything all the time.
A block editor built to preview reality, not a guess
Inline multi-viewport preview across languages and across Nike's different apps, so an author could see what content would actually look like before it went anywhere.
Language handling built into the workflow itself
With automated push and pull to a third-party translation agency, instead of someone managing that process by hand.
Section-based permissions
So specialized teams like SEO could work inside their own scope of the tool without needing broader access or bumping into content they had no business touching.
A component library that came out of the work, not a separate initiative
Building CMS itself meant designing the same patterns over and over, so I started pulling those into a shared library to move faster. That library is what let me help stand up tooling for a couple of other teams quickly, the g11n team's localization tooling and an asset management tool called Perspective, both built directly with those teams using components that already existed. Neither of those took real additional design effort to speak of, the system built for CMS just ported over.
Conceptual CMS preview app for iOS
Results
The CMS is still running Nike's digital publishing today. I don't have publish volume or adoption numbers to point to, and I don't think the story needs them. The system I built is still the one doing the job.
The component library that came out of building CMS eventually grew into its own dedicated enterprise design system, with its own team, and went on to become the foundation for most of Nike's internal enterprise tooling that followed. That specific foundation was sunset for new design work this year, but most of the enterprise tools currently in production at Nike were built on it.