Design system architecture for a global commerce replatform

Role
Senior Experience Designer
Client
Victorinox
Year
2024–present

Skills

Design systems · Component architecture · CMS requirements & documentation · Design–engineering process & UX QA · Cross-functional leadership · Stakeholder communication

13 → 1 → 7
customs replaced by 1 Super Tile, 7 tile types
~60
components across 2 tiers
6 months
delivery timeline
70+
client-side stakeholders
6
full-time frontend devs
Summer 2026
tech MVP launch

Summary

Problem

Victorinox's commerce platform was being rebuilt globally on Salesforce, pulling together a dozen content and commerce systems. The existing component library had grown organically, was built for content editors rather than scalable product use, and couldn't keep a build of this size coherent.

What I did

I led the design-system architecture and its technical integration — a 3-layer separation of concerns that unified sprawling legacy components into a small, composable foundation, plus the documentation that let a 35-person delivery team build from one shared language.

Outcome

One “Super Tile” component now derives 7 tile types, replacing 13 previous custom implementations; five separate carousel implementations were unified into one. Tech MVP launches summer 2026.

Image placeholder — three-layer-diagram
The 3-layer separation of concerns — Layout, Image Tile, Slot.

Context

A global e-commerce replatform for Victorinox, built on Salesforce. The program ran across 70+ client-side stakeholders and a 35-person delivery team, including six full-time frontend developers over six months. The platform spans the full page-type catalogue — product listing, collections, search, product detail, cart, one-step checkout, the complete account area, content and inspiration hubs, press, careers, and a multi-region navigation system — and had to work across two rendering paradigms (a headless Arc frontend and Salesforce-rendered pages) while integrating roughly a dozen third-party systems for content, search, reviews, media, payments, address validation, age verification, and fraud.

I owned the system architecture and the design–engineering bridge at 100%, working alongside a second designer who led visual and UI craft. Beyond the component system, I stepped into ownership of the CMS requirements function — establishing a new documentation approach with my Figma as the single source of truth, driving requirement decisions with the Lead Commerce Engineer, setting up UX QA testing with the frontend developers, and presenting progress and design decisions to client-side stakeholders weekly.

The challenge

At this scale, fragmentation isn't untidy — it's expensive. Every duplicated component meant the same work rebuilt several ways across a six-developer team. The existing library had proliferated into many overlapping component types, each maintained separately, and built primarily for content editors. Design also had little influence over the underlying tech stack, so this couldn't be a clean rebuild: the new architecture had to bring order to an inherited foundation while holding together across two rendering paradigms and a dozen integrations.

Key decisions

Renamed to reframe: “Banner” + “Card” → “Image Tile.”

Two component families maintained as separate things were structurally the same. Unifying them under a single renamed component — one source with overlay variants, hover states, and five responsive formats — made consolidation possible. “Banner” and “Card” invited separate builds; “Image Tile” invited reuse.

Image placeholder — image-tile-matrix
The Image Tile variant matrix — variants × responsive formats.

A 3-layer separation of concerns.

Layout owns spacing and grid and decides what goes where; Image Tile owns image, overlays, hover states, and formats; Slot owns content. Every surface composes from the same foundation instead of being bespoke. A shared variable system (color, spacing, typography, responsive formats) drove both pre-built and custom components.

Built for derivation, not duplication.

Two tiers: a foundational core of ~19 components unified through the variable system, and ~40 composed components across 7 families on top. One “Super Tile” derives 7 tile types (Button, Category, Tall, Support, Complementary Support, Feature, Illustrated Feature), replacing 13 custom implementations; five carousels collapsed into one.

Image placeholder — super-tile-before-after
Before / after — the variant explosion vs. the unified Super Tile system.

Stepped into requirements ownership and made design the source of truth.

As the build scaled, CMS requirements ownership was falling through the cracks. I stepped in: established a new documentation approach with my Figma as the single source of truth, drove requirement decisions with the Lead Commerce Engineer, aligned the flow cross-functionally, and set up UX QA testing with the frontend team so design intent was verified, not assumed.

Outcome & reflection

The developers adopted the system as their build foundation: the Super Tile sourced 7 tile types rather than 13 separate builds, and the unified carousel replaced five divergent implementations. The tech MVP launches summer 2026.

Image placeholder — carousel-5-to-1
Optional — Content Grid Carousel, the 5 → 1 unification.

Reflection. What I'm proudest of is the design–engineering fluency this demanded. Redesigning the entire journey in six months on roughly 55 hours of weekly design capacity only worked because the system was built to be understood and reused — documentation the developers could actually build from, a shared language that streamlined output rather than adding overhead. Speaking the developers' language, and designing the system so they could move fast, was the real leverage.

More workView all projects →