The primary composition of Epic Design Language consists of:
1. Color System
3. Grid System
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.
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.
Feel free to browse a demo version of the Epic Component Library in Figma.
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.
Again, using Zenkit, I created a Wiki Library to manage both the general & accessibility documentation.
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.
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.
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.
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.