Design System

When I started building Mosaic, The Archive's designers were producing work in parallel across multiple products with no shared component vocabulary. Visual inconsistencies accumulated across products, design-to-development handoff was expensive — the same component would be re-specified and re-built multiple times — and there was no system for tracking whether a design decision had been implemented correctly.

I built Mosaic on Atomic Design principles — starting with primitive design tokens (color, typography, spacing, radius, shadow) before building components, and components before assembling patterns. The token architecture was the foundation: every visual decision in the system traces back to a named token, which means every change propagates consistently and intentionally.

Mosaic's core values — Responsive, Accessible, Themable — were not just aspirational statements. They were architectural constraints. Responsive meant every component was designed mobile-first with defined behavior at every breakpoint. Accessible meant WCAG 2.1 AA compliance was built into components, not added as a post-hoc audit. Themable meant the token architecture was designed to support alternate brand skins from day one, which enabled Mosaic to serve as infrastructure for non-The Archive products as well.

The audiences I designed for simultaneously: UX Designers (who reference components in layouts), UX Engineers and Developers (who use the code library directly in builds), and client-facing teams (who use Mosaic to communicate product capabilities to funders and partners). Each audience has a different relationship to the system, and the documentation had to serve all three.

Design systems have a lifecycle that most case studies don't document: the period after initial delivery, when a new team takes over and the system quietly degrades. At The Archive, there was a period when I transitioned ownership to another team member. When I returned, I found significant drift — components modified without updating token references, new patterns built outside the system, and documentation that no longer matched the production implementation.

The recovery process was more valuable than the initial build, because it forced me to develop a systematic approach to drift detection. I audited every component in production against its specification, categorized deviations by type (token override, structural modification, undocumented variant, documentation gap), and prioritized repairs by impact on cross-product consistency.

The governance lesson: design systems don't maintain themselves. They require an owner with authority to approve changes, a process for requesting additions, and a regular audit cadence. The system I rebuilt after recovery was structurally identical to v1, but the governance model around it was fundamentally different. Adoption rates improved. Drift slowed. Mosaic became a living tool rather than a static artifact.

The human systems around a design system are as important as the design system itself. Who can commit to the system? What triggers a component update? How do you handle exceptions without creating entropy? These are governance questions, not design questions. Answering them is the real work of a design system lead.

The current phase of Mosaic is preparation for an AI-native design workflow. This is not about adding AI features to components. It is about making Mosaic's architecture consumable by AI tools — so that when AI agents generate UI, they do so within the system's constraints rather than outside them.

Specific work: restructuring token schemas so AI models can consume them in a predictable format; designing component APIs that specify behavioral contracts alongside visual properties (what this component does, what it should not be used for, what content types it accepts); and developing governance protocols for AI-assisted design contributions.

My Graduate Program training in machine learning pipelines and model input requirements directly shaped this work. A token file optimized for human readability is structurally different from one optimized for model consumption. I redesigned Mosaic's token architecture to serve both — maintaining the designer-readable structure while adding the machine-readable metadata that AI tools need to generate compliant outputs.

The harder question: how do you maintain system coherence when AI tools can generate plausible-looking components that don't fit the system? The answer is that coherence can't be enforced at the generation layer — it must be enforced at the governance layer. Mosaic now has review criteria explicit enough that they can be applied to AI-generated proposals without relying on a reviewer's intuition.

Most design system case studies end at 'we shipped it.' Mosaic has a measurement layer. GTM tag architecture tracks component usage across every The Archive product. GA dashboards built for non-technical stakeholders show adoption trends, identify under-used components, and surface pages where production has drifted from design intent.

When I rebuild a component, I measure whether the rebuild improved adoption — not just whether it got positive feedback in a design review. This is what separates a design system lead from a design system builder: the ability to close the loop between specification and outcome.

Three lifecycle phases of Mosaic taught me that design systems are infrastructure, not products. Products are built and shipped. Infrastructure is maintained, evolved, and occasionally rebuilt. The instincts required for infrastructure work differ from those for product work: patience with slow progress, commitment to consistency over novelty, and willingness to do the unglamorous governance work that keeps a system usable at scale.

The AI-era preparation phase has been the most intellectually novel — there is no established playbook for making a design system AI-native. I am building that understanding in practice, at a real organization, with real consequences for the products Mosaic powers.