Mosaic Design System

Context & Problem

ICPSR's digital products had grown across separate team silos. Each product had its own Figma library, its own color tokens, and its own interpretation of shared UI patterns. A button looked different in every application. Spacing was inconsistent. Accessibility was applied inconsistently, or not at all. When teams needed to ship new features, they reinvented rather than reused.

The problem had three audiences. UX designers needed a component library to reference and build from in Figma. UX engineers and developers needed a code library with accessible, well-documented components they could drop into any product. Client-facing teams needed a coherent product story to communicate with funders. All three were underserved.

Lesson Learned

The first Mosaic cycle proved the value of a shared system, but it also made the system's structural gaps visible. The next version needs to be simpler, clearer, easier to maintain, and easier for both humans and AI agents to consume as product needs move faster than component updates.

• Simpler is better. Fewer dependencies, especially between Bootstrap 5 and React, make the system easier to scale and maintain.
• Code convergence is hard. Moving patterns across HTML, CSS, and React creates unavoidable complexity unless the system defines cleaner boundaries.
• Foundations matter. Missing design tokens made larger components harder to build, update, and reason about.
• Categories need sharper definitions. Atoms, molecules, organisms, patterns, and templates need clearer ownership and promotion criteria.
• Import workflows need structure. Teams need a more organized way to bring Mosaic components into real product work.
• Snowflakes need a place to mature. Project-specific components, such as a one-off hero for an ICPSR web project, should enter a lab phase before becoming official Mosaic components.
• Documentation should separate common from experimental. Official docs should focus on repeatable components, while project-specific patterns stay visible without bloating the core system.
• AI changes the system contract. Tokens, component rules, and documentation need to be structured enough for AI agents to consume without guessing, while institutional security and privacy constraints limit how directly AI tools can enter the workflow.

New Direction Workshop

I led a workshop with UX designers and UX engineers to translate these lessons into a new direction for Mosaic. The workshop focused on the people who use the system directly, internal designers and developers, and the end users who experience products built with Mosaic.

The result was a revised set of design principles that make system decisions easier to evaluate. They guide both interface quality and system governance: what we build, what we reuse, what stays experimental, what becomes part of the official foundation, and how Mosaic prepares for AI-assisted work without ignoring institutional constraints.

• Clarity Over Complexity. Layouts, labels, and interactions should feel obvious and predictable, especially for new users.
• Consistency Builds Trust. Reuse established patterns before reinventing, so users can transfer knowledge across products.
• Performance Is a Feature. Fast page loads, responsive interactions, and reliable services matter as much as visual polish.
• Accessibility From the Start. Mosaic should support diverse contexts, abilities, devices, geographies, and user backgrounds from the component layer upward.
• Simplicity Over Decision Fatigue. Every element should earn its place by supporting a core task or decision.
• Delight Without Disruption. Personality belongs where it reduces stress or improves understanding, never where it harms performance, clarity, or focus.
• Built to Evolve. Mosaic should maintain clear boundaries between system-owned patterns, third-party tools, experimental work, and AI-assisted workflows.

Designing for an AI-Friendly Era

The next Mosaic system also needs to prepare for AI-assisted product work. If AI agents are going to help designers and engineers build with Mosaic, the system has to be legible in code: tokens should be named predictably, components should expose clear usage rules, and documentation should explain the difference between stable, experimental, and project-specific patterns.

The constraint is institutional reality. Security and privacy concerns mean AI tools cannot simply be dropped into every design-system workflow. The governance plan needs a safer workaround: a way to keep tokens and component definitions synchronized between the codebase and Figma without requiring sensitive product context to pass through unmanaged AI tooling.

Current Outcomes