Design System Foundation

Lung DS

Building a production-minded design system that could support healthcare workflows, reduce UI drift, and create a shared language between design and engineering.

Focus

Tokens, primitives, components, patterns, governance

Live reference

Open Lung DS

System model

TokensPrimitivesComponentsPatternsProduct

Hero image placeholder for Lung Design System overview — Lung DS pattern directory.

Framing

Building a system that could survive real product pressure

I treated the design system as an execution layer. The goal was to create reusable structures that could support dense healthcare workflows, improve design and engineering alignment, and scale with the product.

Context and role

At Numo / Curie, I created a design system to support rapid product iteration while staying close to production. My role was to define the visual language, structure reusable primitives, and turn recurring product needs into scalable system patterns.

Early dashboard screen showing product complexity and inconsistency before the design system matured — An early dashboard view: dense product surfaces, repeated UI decisions, and patterns that needed a more consistent foundation.

System-level thinking

I organized the system in layers: tokens, primitives, components, and patterns.

Tokens handled foundations like color, spacing, type, radius, and elevation. Primitives became building blocks like buttons, inputs, tabs, and containers. Components expanded into denser product UI, while patterns captured how those components behaved together. Prototypes were used to test patterns in dashboards, tables, and clinical workflows.

Lung DS tokens overview — The system was organized as a stack of reusable layers, starting with tokens and expanding into components, patterns, and prototypes used in product work.

Scalability and governance

I built it close to implementation using Next.js, Tailwind, CSS variables, and reusable UI patterns that engineering could reference directly. That reduced visual drift, improved handoff, and helped the system evolve with real product needs instead of becoming static documentation.

The live Lung DS homepage shows the system as a coded product surface, not just a static artifact, making adoption easier across design and engineering.

Collaboration

The work happened in close partnership with engineering and product. We discussed component states, data density, theming, responsiveness, and how reusable each pattern really was. In a healthcare environment, design decisions were also shaped by compliance needs, clinician workflows, and the practical reality of shipping under uncertainty.

This live pattern view shows how states, density, and reusable clinical structures were shaped through close collaboration between design and engineering.

Accessibility considerations

Contrast, type hierarchy, spacing, focus states, and scannability were built into the foundation. Many clinician workflows happened under time pressure, so the system needed to support quick recognition, reduced cognitive load, and calm presentation of important information.

This live patient pattern highlights accessible hierarchy, readable density, and calmer information grouping designed to reduce cognitive load.

Impact and learnings

The biggest outcome was alignment. The design system created a common language between design and engineering and made it easier to prototype, validate, and scale product decisions. My main learning was that design systems become valuable when they are tightly connected to real workflows, not when they live in isolation.

Impact image placeholder for Lung Design System — Prototyping was the best way to validate the design system.

Next case study

See how this system performs inside a real product

The RPM case study shows how these design system decisions held up under dense data, clinical notes, patient history, and actionable dashboard workflows.

View RPM Workflow