Apollo Merchandising System

The door I opened first

The most important decision I made on Apollo wasn't a design decision — it was to open the door. I established weekly office hours: open sessions where any of the 250 merchandisers could bring questions, frustrations, or ideas directly to me. No tickets. No product manager as intermediary. Just a designer and the people using the platform.

That single structural choice transformed the relationship. Skeptical users became invested collaborators. The platform improved faster because feedback came from the people doing the work, not just the stakeholders managing them. And every time a merchandiser saw their feedback turn into a visible improvement in the next release, the trust grew.

• Shipped MVP early to build credibility through delivery, not promises
• Maintained regular release cadence with visible improvements each cycle
• Designed split-panel Rule Management — build rules on the left, see live gridwall preview on the right, before anything publishes
• Built Collections to handle multi-market scoping intuitively — one collection, targeted to specific channels and geographies
• Abstracted complex boolean search logic behind a structured interface — merchandisers make decisions, not code

Before the screens

The design work on Apollo started on whiteboards and table surfaces, not in Figma. The most important decisions — how rules related to actions, how the data model should be structured, what the interaction patterns should be across 7 interconnected tools — were worked out in sessions like these before a single pixel was placed.

Building block flow — defining the decision sequence

The 6-step user flow for Building Block Nav Creation mapped before any wireframes were drawn — select trigger, select type, select geo, display available components, override defaults, preview, save. Defining the sequence first meant the wireframes that followed were solving a known problem, not exploring an undefined one.

Interface exploration — six concepts from the same session

Six parallel layout concepts sketched immediately after mapping the flow above — list view, detail view, grid view, and split-panel variations. These two artifacts are sequential: the flow defined what had to happen, the sketches explored how it would feel. Committing to a direction here, in the room, before moving to Figma.

Rules data model — structural thinking before UI

Mapping the relationship between Rules and Rule Actions before designing any interface. The data model defined what the UI had to express — getting this right meant the interaction patterns that followed were grounded in how the system actually worked, not how it looked in a vacuum.

Sprint planning — scope management across 7 tools

Features organized by theme across delivery sprints — pink headers for epics, teal cards for tickets. Running 7 interconnected tools as a single designer meant the planning work was as important as the design work. This board kept delivery sequenced around what engineering needed, not just what was designed next.

The work

Rule Management — See the consequence before you publish

Build a rule on the left, see the live gridwall result on the right — in real time, before anything goes live. On a platform running across 56 countries simultaneously, this preview is the guardrail. No rule reaches production without the merchandiser seeing exactly what it will do first.

Collections — Global complexity, simple interface

A single collection scoped to Spain, Portugal, Italy, France — with active and inactive product states at a glance. Merchandisers think in products and seasons, not system logic. The interface handles the complexity; they handle the decision.

Search Management — Abstracting the complexity underneath

Dense boolean expressions spanning channel IDs, product status, marketplace exclusions, and thread types. Merchandisers never write this — the structured interface generates it. This is the gap the design bridges: the difference between what the system needs and what a human can confidently operate.

Who uses Apollo — and when

Apollo sits second-to-last in Nike's entire digital commerce chain — products flow through assortment planning, product data management, and content systems before reaching Apollo, then publish directly to Nike.com. The people operating it aren't experimenting. They're the last human checkpoint before $21B in commerce goes live.

Commerce User Journey Map — Apollo's position in the chain

Apollo is the merchandising layer between content and Nike.com — the final configuration step before products reach consumers. Users span Global Digital Experience Ops Managers, Global SEO Specialists, Global Site Experience Operations, Digital Site Merchants, Category Merchandising Managers, Geo Merchandisers, and GEO SEO Specialists across 56 countries. One platform. One designer.

A side effect that became infrastructure

About six months in, I noticed the same components being rebuilt across different Nike teams — buttons, tables, filters, status patterns — each slightly different, none of them shared. That was a systemic problem, not just a design problem.

I proposed and co-created SALT — a shared component library built in React, designed alongside Engineering to be usable by both designers and developers. What started as an Apollo efficiency decision became Nike-wide infrastructure. A companion Design System Manager bridged Figma and code so both sides spoke the same component language.

What it delivered

• Office hours turned a skeptical user base into invested collaborators — the clearest signal the trust had shifted
• Guardrail system prevented a class of configuration errors that previously reached production
• 10,000+ seasonal products managed across 7 interconnected applications
• SALT became org-wide infrastructure — designed to scale, not just to ship

From the people who were in the room

"Andrew led the charge on designing the Apollo merchandising platform, which became the go-to toolset for our global merchandising team... What truly sets Andrew apart is his ability to navigate the complexities of design, technology, and business operations and bring invaluable insights and ideas to the table. He's not just an exceptional designer but also an incredible thought partner and collaborator."

What this taught me

The most important thing I did on Apollo wasn't a design decision — it was opening the door. Once merchandisers believed their feedback led to visible change, the quality of input improved dramatically. The platform got better faster because of that relationship, not despite working alone.

SALT taught me something about leverage: good component work outlasts the project it was built for. The most durable decisions aren't the ones that solve the immediate problem — they're the ones that create infrastructure others can build on.