Case Study

Establishing a design system

tl;dr

I established Compass Digital’s first design system for its healthcare product team, aligning separate product teams around a shared codebase. Adopted by more than 10 designers, the system paired reusable components with a release process that kept Figma and production code in sync.

Design Strategy 60 Days

One codebase needed one shared set of decisions

At Compass Digital, designers owned separate products while engineering maintained a shared platform. Teams solved similar problems differently, leaving engineers to rebuild components and negotiate inconsistencies feature by feature.

Teams solved similar problems independently across products sharing one codebase.

The issue went beyond visual consistency: teams needed agreement on which patterns to reuse and how new ones should enter the platform. I brought Product, Design, and Engineering together to establish that framework.

Without shared standards, each feature triggered another round of design and engineering negotiation.

Standardizing decisions that already worked

I audited the product suite for patterns worth retaining and reviewed the component architecture with Engineering. Because the team maintained its own implementation, we could shape the system around our products rather than adapt a third-party library.

A cross-functional workshop established a common model for the system and surfaced senior engineers who became early allies. Together, we reviewed foundations for typography, color, spacing, elevation, icons, and layout before building components on top of them.

Foundations, content guidance, and components form a shared product language.

Making components an agreement between design and code

Each component defined behavior as well as appearance: interaction states, validation, accessibility considerations, and usage guidance. Designers and engineers reviewed patterns against product needs and implementation constraints before accepting them into the system.

Button documentation makes variants and states part of the shared component contract.
Anatomy and usage guidance clarify when to use an input stepper.
Text-area guidance covers states, validation, accessibility, and content.
See all artifacts/documentation
Semantic color tokens give products a common palette and reusable implementation values.
Reusable spacing and radius tokens replace one-off measurements.
Usage guidelines explain which spacing token to choose in context.
A shared icon library pairs consistent assets with usage guidance.
Reusable text styles establish a common hierarchy for headings, body copy, and interface text.
Elevation tokens define shadows for cards, menus, and headers.
Table documentation covers interaction states, empty states, sorting, and drag-and-drop behavior.
Component properties let designers switch variants and states without rebuilding the element.
Responsive layout guidance defines how card-based patterns adapt across screen sizes.

Keeping the published library aligned with implementation

I established a contribution process using Figma branches. Proposed changes went through design and engineering review, then Engineering implemented them in the shared library. Only after implementation did we merge and publish the corresponding Figma branch.

Figma changes are published only after review and implementation in the coded library.

This release sequence meant designers could work with components that Engineering could support. It also gave both teams a repeatable way to extend the system without letting design and code drift apart.

A common starting point for product teams

More than 10 designers adopted the system. Teams spent less time recreating existing solutions, engineering rework decreased, and interface decisions increasingly became extensions of an agreed foundation.

The live Storybook gives designers and engineers a shared reference for component behavior and implementation.

Next Case

Improving real-time operations oversight