As the Lead Product Designer at Reliance Matrix, I ensure that our design system helps us move faster, together. When I joined Reliance Matrix, I inherited an over-built and under-documented set of design system files that failed to translate into the front-end system. Then-to-now, I've established a scalable design system and a design ops practice to support its evolution. I've also kick-started the process on the engineering side, to make the design system a shared priority between Design and Engineering.
When I joined the organization, Reliance Standard Life Insurance had just merged with Matrix Absence Management to form Reliance Matrix. This meant, on the RSLI side, I had an underdeveloped, under-documented Sketch design system, serving 15+ products; and on the Matrix side, I had a bloated, under-documented Figma design system, serving 5+ products.
Documentation was lacking, and where it existed, it was out-of-date, and directed at engineers, for the immediate implementation of the component.
The Matrix system had components with complicated structures, wild properties, and confusing variants (many of which were totally broken).
In both systems, components didn't cascade, variants required breaking the component, or adding onto the long list of properties, and as a result, it was costly to make even minor adjustments to fix errors in the component.
For both design systems, I started the audit by cataloging all of the existing components, states, properties, color styles, and text styles, ordering them by how out-of-sync they were, and how critical they were to repair. Once cataloged, I created documentation for all of the existing components, and began to work toward deduplicating all of the existing design decisions.
The audit results were intense. For instance, as you can see in the right panel, there were 108 different colors used in one product, many disconnected, 9 different button styles, and a multitude of other components whose styles and properties were all over the place. All of these design decisions needed to be deduplicated and streamlined.
On the Matrix side, things weren't much better, 75 different colors used in a single product, all disconnected, 5 different button styles, and many components with styles and properties that were all over the place. Again, a high volume of design decisions that also need to be deduplicated.
My initial strategy was to avoid rebuilding components, from both systems, but it was clear to me, early on, it would take longer to fix the complex existing issues, than it would take to start over from scratch. Additionally, I needed to set a higher bar for design, so starting with a clean slate, on a brand new design system, made the most sense.
The transition strategy, then became: Everything net new is designed with the new design system. For the existing components, I would document them in-place, deduplicate design decisions, then rebuild the existing components in the new design system, establishing them as 'legacy components. This gave me the ability to work from a single design system file in Figma, support existing designs until they come up on the roadmap to re-design with the new design system, and design everything new with the improved design standards.
As I planned for the work of building the new design system, I also started a campaign across PDE to educate on how design systems could support our product strategy goals. My philosophy is to always be selling the design system, and always be working toward generating more design system buy-in. To support this effort, I wrote an internal memo on our design system strategy, and followed up with regular updates on the team's progress. This also supported the creation of a dedicated role in engineering to focus on design systems, which I helped recruit and interview for.
My internal memo on the value of design systems helped make the case for headcount increases and roadmap space for the new system.
With the existing/legacy designs audited, indexed, and rebuilt in Figma, it was now time to start building the new design system. I named the design system Matrix, and established 5 core pillars from which it's composed: Matrix Design Language, Component Library, Documentation, Developer Sandbox in Storybook, and Governance Model.
Matrix Design Language is composed of foundations like color, typography, grid system, units, depth, and icons. These foundations are managed, maintained, and expressed through a comprehensive set of design tokens.
Matrix Design Language Token System
Global tokens are the primitive values in the Matrix Design Language, represented by context-agnostic names. Global Tokens can be directly used, and are inherited by all other token types. Alias Tokens are context or abstraction-specific. Aliases help communicate purpose & intent. Component Tokens are an exhaustive representation of every design decision possible within a component. They often inherit from alias tokens, & are expressed in a way that allows both design & engineering teams to be as specific as possible when communicating design decisions.
Matrix Design System's tokens are expressed through Figma's variables. Matrix uses variables for virtually all of Matrix Design Language's foundations; color, typography, icons, grids, dimensions & units, depth, and theming. I even established variables for copy/content and prototypes. Other members of the design team were unfamiliar with token strategy and Figma variables, so I conducted regular training sessions and created documentation surrounding how to work with tokens and variables in Figma.
The Matrix Core Library is a set of code-aligned components, that are version controlled, & used as the building blocks of the design system.
The design documentation ties together the entire design system. The Matrix design documentation is a set of guidelines on how to consume the design system, for both designers and engineers. There is general documentation for each component that describes its purpose, how to use, how not to use, and its styling through tokens. The accessibility documentation ensures both designers and engineers know how to use each component in accordance with WCAG 2.2. The accessibility documentation also describes the process for testing new & existing components to ensure they meet the required standard.
As part of the design system’s standard tooling, the sandbox provides a place for developing components in isolation, including writing structural and visual tests. All the code for the component library is maintained in the developer sandbox. Engineers can also document intended use cases for components, UI kits, & product views, while sharing implementation notes & details to ensure a smooth process with less rework.
The governance model ensures Matrix Design System can continue to evolve, with organization-wide contribution. Design system governance also establishes comprehensive safety protocols that preserve the security & integrity of the system.
The New Process
I worked with engineering to create a shared vision of the design system, shared ownership of the design system, and a shared process through which we could work and collaborate.
I made use of Figma's branches capabilities to create rules for merging new components into the system. Designers were unblocked to incorporate new changes after they had received suitable review.
I built a Figma prototype to house the documentation, for external reference, and quick reference by the Engineering team. I also helped make a case for a dedicated role on the Engineering team, focused on building out the coded component library, and served on the interview panel to fill the role, with the goal of bringing the shared language closer together.
A critical piece to design system governance is measuring adoption. I lobbied for the implementation of Omlet Design System Analytics platform, as I felt it would be key to ensuring I could measure and track our progress toward sunsetting legacy components, and building all new products with Matrix Design system. It also gives me a high-level understanding of what is and isn't working for the design team, and gives me the ability to know where to look for things that the design team needs fixed.
