Matrix Design System
Creating a single source of truth that enables design decisions to be scaled across the design organization.
Project Details
Design Systems, DesignOps
Primary Practice Area2022-Present
YearLead Designer
My Role
Background
The Problem
The Solution
The Users
Design Team
Engineering Team
Reliance Matrix Users
How I Think About Design Systems
At the top-level, my approach to creating design systems exemplifies 4 core philosophical principles: Ontology, Epistemology, Phenomenology, & Logic. Applying these 4 principles to design system creation ensures the design system has the philosophical grounding necessary to scale.
Philosophical principles
Ontology ensures there is a collective, shared meaning across Design, Product, & Development; along with a unified, collectively agreed upon language/vocabulary through which the meaning is expressed.
Epistemology ensures the design system serves as the single source of truth for Design, Product, & Development. And, ensures the design system acts as the knowledge hub through which all three teams collaborate.
Phenomenology ensures the design system is engaged through an excellent, productive, & positive experience for all who use it.
Logic ensures the design system exemplifies an easy to understand file structure, project structure/flow, and system of processes.
My Design System Design Process
Matrix Design System Composition
The 6 core design system elements
Since a design system's makeup can be subjective, & vary from organization to organization, I first needed to formalize the minimum compositional makeup of Matrix Design System. At the most fundamental level, I decided these 6 core elements needed to be present from the beginning: Design Language, Design Kits, Component Library, Developer Sandbox, Documentation, & Governance Model.
Matrix Design Language
Design language composition
The primary composition of Matrix Design Language consists of:
1. Color System
2. Typography
3. Grid System
4. Icons
These foundations are managed & maintained through a comprehensive set of Design Tokens.
Managing Matrix Design Language With Design Tokens
Tokens are a unified & collective design vocabulary through which the Matrix design language is expressed.
The Design Tokens:
1. Exemplify the sole epistemological source of truth for the entire design system.
2. Enable both designers & developers to think about design from the perspective of symbols.
3. In thinking from the perspective of symbols, it enables a completely platform-agnostic approach to design & product development.
4. Exemplify all possible design decisions within the design system.
Token overview
I believe it is crucial to have well-defined design tokens, because they help ensure the component library is fully code-aligned. To maintain a fully code-aligned component library between all platforms, I developed the mentality that every new component or token created, must exhibit full parity between design documentation, Figma, & the code repositories. If a new component doesn't meet the parity requirement, it doesn't get published to the core library.
Global
Semantic
Component
Token types
1. 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.
2. Alias Tokens are context or abstraction-specific. Aliases help communicate purpose & intent.
3. 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 & development teams to be as specific as possible when communicating design decisions.
Tokens in Figma
The tokens are executed through a comprehensive token naming schema and synced to native variables in Figma. I use variables for color, dimensions, typography, theming, content, and prototyping.
The Component Library
The Matrix Core Library is a set of code-aligned components, that are version controlled, & used as the building blocks of the design system.
Comprehensive Design Documentation
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.
Scaling beyond Google Sheets
Initially the design documentation, and component structure was managed through a set of spreadsheets. This was a good starting point, but I knew it wouldn't be easy to scale in Google Sheets.
Using Zenkit to manage the design system
I decided to use Zenkit in order to manage all of the documentation outside of Figma. I created a Wiki Library to manage both the general documentation & accessibility documentation.
Managing the documentation in Figma
To enhance the designer's experience, I wanted to ensure the designers could access the most up-to-date design documentation directly in Figma. In Figma, all of the design documentation lives adjacent to the core library, utilizing anchor links within, to make navigating the documentation incredibly fast & easy. As a failsafe, and for efficiency, we created a Figma plugin that enables automatic syncing between the Figma documentation and the external documentation wiki in Zenkit.
The Code & Development Sandbox
Standard tooling for development
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
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.
Establishing roles & permissions
The governance model forms the basis for a solid DesignOps program, establishing clear personnel roles & permissions. This is critical to ensure secure collaboration across the organization.
Going beyond roles & permissions
The governance model goes far beyond roles & permissions for collaboration, management, & maintenance.
In addition to the personnel & permission structure for Design Ops, I designed a complete inheritance structure for the design system, along with a comprehensive strategy to handle versioning, branching, snapshots, and backups, which ensures the integrity of the system as it progresses, grows, & scales.
Comprehensive onboarding, collaboration, & hand-off processes
The last piece of the governance model is comprehensive process documentation for how new team members are onboarded, how existing team members collaborate across design, product, and development, and how development hand-off is executed. The process documentation also details how Reliance Matrix documents specs, how designs are organized, and how teams are structured. This dramatically decreases onboarding & ramp-up time, decreases hand-off time, increases product development velocity, and makes for very happy team members.
Design Kits & View Libraries
Design Kits & View Libraries are where product-specific design patterns are created to iterate and execute designs. The design kits enable the core component library to be kept light, lean, & highly manageable, by enabling designers to create independent design patterns without altering the core library.
Once a product or project begins the formal iterative design process, the final versions are then iterated upon in the Views Library, in order to keep the core system isolated, as mentioned above.
Below are a few examples of how the Design Kits are customized at the product-level, from the core component library.
Reliance Matrix Secure Authentication
Reliance Matrix Workflows
Reliance Matrix Claims Portal
Reliance Matrix Website
Reliance Matrix Native Apps