Shipped / Design Systems

Scaling a shared e-commerce system across multiple client builds

Applying an existing design system responsibly to support scale, flexibility, and long-term maintainability across enterprise clients.

Impact

Enabled multiple enterprise retail clients to ship faster on a shared platform, without fragmenting the underlying system.

I applied an existing design system at scale, balancing delivery speed, brand flexibility, and long-term maintainability across storefronts with very different needs.

Context

A shared system supporting many clients introduces different risks than a single-product environment.

Rather than designing new systems per client, the challenge was adapting real product needs to a shared foundation while preserving consistency, flexibility, and delivery speed over time.

I worked at a digital commerce agency supporting multiple enterprise retail clients on a shared, desktop-first e-commerce platform. The platform relied on an internal design system intended to accelerate delivery across storefronts.

Problem framed as Risk

Using a design system irresponsibly can break both speed and scale.

The challenge wasn’t the absence of a design system.
It was how to use one responsibly across many clients.

On the other end, overly rigid system usage resulted in:

  • Poor fit for real client requirements
  • Limited brand expression
  • Increasing workarounds that quietly fractured the system

On one end of the spectrum, bespoke client builds led to:

  • Slower delivery timelines
  • High design and engineering overhead
  • Repeated reinvention of common patterns

Without clear guidance, the platform risked becoming neither flexible nor scalable, undermining the very efficiency the system was meant to provide.

Constraints and Non-Negotiables

This work had to operate within fixed technical and organizational constraints.

  • An existing internal design system already adopted by teams
  • Multiple enterprise brands with distinct visual and structural needs
  • Desktop-first layouts with responsive breakpoints
  • Close alignment with established engineering patterns and third-party e-commerce integrations

The goal wasn’t visual reinvention, but sustainable system application over time.

System Strategy

Scale came from reusable structure, not surface-level customization.

Rather than designing one-off solutions per client, the work focused on defining reusable patterns that could flex across implementations.

This included:

  • A shared catalog experience that scaled across breakpoints while preserving information hierarchy
  • Baseline product detail layouts designed for reuse across clients
  • Variant behaviours handled through shared logic, not bespoke layouts
  • End-to-end transactional flows designed for consistent behavior across builds

The emphasis was on structure, predictability, and reuse, not cosmetic customization.

A shared catalog experience scaled across breakpoints while preserving information hierarchy.

A baseline Product Detail page designed for reuse across multiple client implementations.

Variant behaviours handled through shared logic rather than bespoke layouts per client.

End-to-end transactional flows ensured consistent behavior across client builds.

My Role

I focused on systems integration and delivery enablement, not visual polish.

I was responsible for:

  • Auditing and mapping existing system usage across key pages and flows
  • Mapping screens to existing components and identifying gaps
  • Defining page-level information architecture to support reuse
  • Delivering screen inventories and scoped plans for implementation

This work translated abstract system rules into practical guidance teams could reliably ship against.

Key TradeOffs

Protecting the system required deliberate decisions about what could flex.

Key decisions included:

Tokens vs Components

Deciding which values required flexibility and which should remain fixed

Fixed vs Themable Layers

Enabling brand differentiation without fragmenting structure

Extension vs Enforcement

Extending the system only when reuse would block real client needs

Information Architecture

Designing layouts that encouraged reuse rather than exceptions

These decisions ensured the system stayed adaptable without becoming bespoke.

Outcome

The system scaled more reliably as new clients and requirements were added.

This work led to:

  • Faster onboarding of new client builds
  • Reduced custom design and development effort
  • Clearer system adoption across teams
  • More time spent improving UX quality instead of rework

Most importantly, it established guardrails that allowed the platform to grow without sacrificing coherence.

Reflection

At scale, flexibility isn’t about how much a system can bend, but how consistently it behaves under change.

Designing for multiple clients required resisting short-term customization in favor of long-term system health. By prioritizing shared structure over surface-level differentiation, the platform remained adaptable without becoming fragmented.

This case represents my strength in systems thinking, long-term judgment, and designing for durability across teams, clients, and time.