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 Area
  • 2022-Present

    Year
  • Lead Designer

    My Role

Background

Reliance Matrix's Product Development Team is comprised of 50+ Designers, Product Managers, & Engineers who come from massively diverse backgrounds, across 5 countries. The team's body of work is equally as diverse, with 25+ products across desktop applications, mobile apps, and websites.

The Problem

When I joined Reliance Matrix, there was no formal design system, design language, or even a centralized style guide that governed design decisions. Additionally, hand-off was slow, team collaboration was low, and product development was not scalable.

The Solution

In order to organize, streamline, and scale Reliance Matrix's approach to product development, I developed Matrix Design System to solve the core problems I encountered as I worked to globally expand Design Operations, the Product Design Team, and our product offerings.

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.

Token naming schema

Designing a token naming schema was the most challenging aspect. I needed to design a schema that ensured both expandability and scalability to multiple design systems, multiple brands, multiple themes, & multiple products.

There are 4 core tenants at the top-level hierarchy:

Namespaces, Objects, Bases, & Modifiers.

The core 4 tenants have a series of subgroups which enable the aforementioned exhaustive representation of design decisions. In Zenkit, I designed a comprehensive filter logic which allowed designers and developers to easily find & navigate the entire token library. The token management system also allows the token library to be exported in every needed format (YAML, JSON, CSS, SASS, etc).

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.

Epic Figma Component Library

Feel free to browse a demo version of the Epic Component Library in Figma.

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

Outcomes

Reduction In Onboarding Time
3x
Matrix Design System's governance model reduced new employee onboarding time by a factor of 3.
Reduction In Errors
90%
Matrix Design System reduced design & development errors & mistakes by 90%.
Reduction In Hand-off Time
60%
Matrix Design Systems comprehensive spec documentation, and hand-off processes reduced total hand-off time by 60%.
Increase In Efficiency
2x
Matrix Design System increased efficiency in overall product development by 100%, as assessed by time to launch new products, & time to iterate consecutive versions of existing products.

Additional Outcomes

1. Both designer, product owner/manager, and developer satisfaction increased, gauged as I conducted yearly reviews.
2. Enabled Andela to generate new business, by being able to white label design system for Andela's clients.