← Back to home

Case Study · Indeed · Design Systems

Lunchbox Design System

Designing a flexible multi-platform design system architecture that scaled across hundreds of product teams while supporting theming, brand evolution, and implementation consistency.

Product systems Design system architecture Theming & tokens Engineering implementation Governance & scale

Scaling consistency without creating rigidity

Indeed’s product ecosystem spanned hundreds of teams, repositories, workflows, and user experiences across employer and job seeker products. As the platform evolved, the design system needed to support a growing range of product needs without fragmenting into inconsistent implementations.

The challenge was not simply creating reusable components. It was designing a system flexible enough to adapt across product surfaces while maintaining consistency, accessibility, and long-term maintainability at scale.

Key problems included

The system needed to support

Building for flexibility without fragmentation

The system architecture focused on separating foundational design decisions from implementation-specific styling so products could evolve without breaking consistency.

Several principles shaped the approach:

Semantic abstraction

Instead of tying components directly to raw values, semantic tokens created an abstraction layer between design intent and implementation.

This allowed:

Constraint-driven flexibility

Flexibility was intentionally structured. Product teams could adapt layouts, workflows, and presentation patterns without creating entirely separate systems.

The goal was:

Platform durability

The architecture needed to survive long-term organizational change, including:

The system was designed as operational infrastructure, not just a UI kit.

Token architecture and scalable theming

The theming model introduced a layered token structure that separated foundational primitives, semantic intent, and component-level implementation. This created a single source of truth while preserving flexibility across products.

The architecture supported:

Rather than hardcoding presentation decisions into components, components responded to semantic intent provided by the token system.

This reduced:

It also allowed visual refreshes to happen at system level instead of requiring large-scale product rewrites.

Bridging design intent and production reality

A major focus of the work was ensuring the system functioned inside real engineering workflows, not just inside design tooling.

This required close collaboration across:

The system integrated into:

The goal was reducing the operational cost of consistency.

The system became easier to adopt because it reduced friction rather than introducing additional process overhead.

Making the system usable at organizational scale

One of the largest challenges was balancing centralized standards with decentralized product development.

Adoption depended on:

Rather than enforcing consistency through strict control, the approach focused on creating systems that product teams could realistically use within their day-to-day workflows.

Governance included:

This allowed the system to evolve without destabilizing product teams already shipping at scale.

Operational consistency at platform scale

94% Design system adoption across employer product teams
73% Reduction in UI fragmentation
65% Faster design-to-development handoff
$4.2M Annual productivity savings

The system enabled large-scale visual consistency while preserving the flexibility required across diverse product workflows.

Semantic theming architecture reduced implementation overhead and allowed visual changes to scale across the platform without requiring widespread component rewrites.

Equally important, the system became operationally sustainable. Product teams were able to move faster while maintaining higher consistency, accessibility, and implementation quality across hundreds of repositories and workflows.

Design systems as operational infrastructure

The most important outcome was not the component library itself. It was creating a durable system architecture that supported how products were designed, implemented, and evolved across the organization.

The work established:

The design system became part of the operational infrastructure of the product organization rather than a standalone design resource.

Read more case studies