Overview
The Cimpress component library had become an outdated, inconsistent, and unsustainable tool. Fragmentation across teams and domains meant multiple versions of the library were supported simultaneously, with little alignment or documentation between teams and domains. To address this, we launched Cimpress UI, a fully-supported and scalable design system.
As a core member of the design system team, I split my time evenly between product work and design system work. I’ve led the design direction for Cimpress UI—shaping the foundational design language, designing components, writing documentation, and helping establish a cross-domain ecosystem and contribution model.
The Challenge
Legacy component library
Our original library had become a bottleneck for design and development efficiency. The most recent version release, v16, introduced Emotion CSS without migration support for teams, making migration time-consuming with little benefit. Most teams refused to upgrade, leaving us to be forced to support multiple versions.
When this project started, 83% of UIs were using outdated versions (that is, on v14 or earlier). Over 60 UIs were still on v10 or earlier, which was released more than 6 years ago. Despite there being individual advocates who championed the component library, there was no leadership support to encourage migration or consistent version usage.
Cimpress UI
In 2024, a dedicated part-time team was created to solve these issues by creating a design system that would be intentional, supported, and forward-looking. We spent a year designing and building the foundation for this system and have officially launched our version 1 in July 2025. Cimpress UI has been built on several key principles: consistent, modern, configurable, accessible, and guided.
Consistent
We started by establishing a shared design language supported by a token system. These tokens became the foundation for Cimpress UI and are used consistently in Figma, code, and documentation.
The result is a unified experience across domains: colors, spacing, typography, and interaction patterns now align with a single system, without eliminating the flexibility teams need.
Modern
Cimpress UI components were rebuilt from the ground up using modern standards. This wasn’t just a visual refresh, it was a rethinking of how components should look and function. Every component was redesigned to be forward-compatible and reflective of current best practices in UX design, visual design, and development.
Configurable
A key priority for the system was flexibility. In Cimpress UI, components are highly configurable, but that configurability is intentionally shaped by our token and prop systems. The variables you see in Figma are the same ones you use in React, and our documentation reinforces the same language. This alignment reduces friction between designers and developers, while still enabling product teams to tailor components to their needs.
For example, the Disclosure component allows for restricted configuration. Users can adjust layout, style, and behavior, but only within defined boundaries that preserve consistency and accessibility. The Disclosure header bar is restricted to only supporting specific sub-components and interactions to maintain accessibility with screen readers and keyboard navigation, but is flexible in the Disclosure body to support any use cases.
Accessible
Accessibility was a major weakness in our legacy system. Components had poor keyboard support, unreliable screen reader compatibility, and color palettes that failed contrast requirements.
With Cimpress UI, we rebuilt every component with accessibility in mind. Our color system was redesigned to meet WCAG standards. Interactive components are tested against keyboard and screen reader use cases. And we didn’t stop at the components themselves—we also built extensive accessibility documentation to guide teams toward proper implementation in UIs.
Guided
The legacy component library lacked design or usage documentation which was a consistent source of frustration. Even when teams used the same component, they often implemented it in completely different ways because there was no guidance on usage, intent, or best practices.
Documentation is an important pillar of Cimpress UI. Nothing is considered complete without both design and development guidance. We include design rationale, usage guidelines, examples, accessibility notes, and consistent language across all touchpoints from Figma to code to documentation.
The Ecosystem
Building one design system for six autonomous domains, each with its own product strategy and users, is exponentially complex and Cimpress UI cannot exist without a supporting ecosystem that is intentionally shaped.
The core of the system is Cimpress UI, composed of universal components, patterns and layouts, and guidance. These are building blocks that are flexible enough to support needs in any domain.
Domain Expansion Packs
We knew that one central library couldn’t cover every use case. So we introduced Domain Expansion Packs. These are libraries composed of domain-specific components and patterns that don’t make sense for the global system. These packs allow teams to move fast and build domain-aligned experiences without diverging from the broader system.
While the Expansion Packs are managed at the domain-level, we support them centrally by offering tooling, collaboration, and design guidance to ensure quality and consistency.
Community contributions
Our contribution model allows components to move between the Expansion Packs and Cimpress UI. When a domain-specific component gains traction across multiple teams, we begin conversations to adopt it into the core library.
We stay connected with teams through a dedicated Slack channel, regular check-ins with domains, and ongoing feedback loops with developers and designers. We know Cimpress UI is still young and we aim to constantly improve and evolve based on real-world use and cross-functional collaboration.