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.
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.
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 Epic Design System. At the most fundamental level, I decided these 6 core elements needed to be present from the beginning: Design Language, Design Kit, Component Library, Developer Sandbox, Documentation, & Governance Model.
Design language composition
The primary composition of Epic 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.
Tokens are a unified & collective design vocabulary through which the 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.
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
Alias
Component
1. Global tokens are the primitive values in the Epic 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.
The tokens are executed through the 'Figma Tokens' plugin, & synced to Figma's native variants.
The Epic 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 Epic design documentation is a set of guidelines on how to consume the design system, for both designers and developers. 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 developers know how to use each component in accordance with WCAG 2.1. The accessibility documentation also describes the process for testing new & existing components to ensure they meet the required standard.
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
Again, using Zenkit, I created a Wiki Library to manage both the general & 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 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.
Developers 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 Epic 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 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, 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 Andela 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 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.
AndelaPay Product
Andela Chat Product
Andela Client Portal Product
Andela Client Portal Mobile Product
Andela Desktop Website
Andela Mobile Website
I design products & experiences that create outcomes & influence user behavior.
