Project Brief
Problem: Inkling's neglected design system lacked process to sustain it. Designers and engineers lacked a single source of truth.
Solution: I established new process for maintaining and evolving the design system. I established new design standards for components and accessibility.
I owned the design system.
- 1 Design System Owner (me)
- 4 UX Designers
- 4 Engineers
Inkling is a corporate learning platform. Content creators build unique interactive content in a drag-and-drop authoring platform, then publish it out to employees who log in to train on or reference company documentation.
Users can access Inkling from web browsers or on native mobile including iOS, iPadOS, and Android. For parity across the platform, the design system needed to unify and disseminate itself across each environment.
Final Design
Here's just a few assets, components, and screens from the design system.
Before & After
Component Prototyping
I nested components together and configured multiple properties and states for easy UI and content manipulation.
Accessibility
Accessibility is often overlooked and then becomes a burden for teams to retrofit. This is why I'd perform regular accessibility audits on the design system to front-load the effort as much as possible. This way designers have less to worry about before handing off to engineering, and engineers had less remediation work to make the product meet accessibility standards.
As part of this audit, I would use the P.O.U.R method to evaluate and QA test design system components.
Platform Parity
The Inkling platform is accessed on all major web browsers from large (desktop) to small (mobile phone) devices, as well as native mobile apps on iOS, iPadOS, and Android devices. When I inherited the design system initially I frequently caught mismatched components within a design.
It was important to have brand and visual design parity across all components and screens, while also allowing room for deviation when it was called for. Mobile app design and the responsive web have different modalities. Therefore, I architected 3 separate Figma component libraries to house styles and components separately. In addition, I placed everything i a single documentation file and documented which components had parity equivalents across the system. This way UI could be compared for uniformity, or intentional deviations could be documented.
Atomic Design
I applied atomic design principles to unify brand and visual design across the user interface. Foundations were configured as Figma styles and variables, then linked within components. To help speed up design work I also created entire product screens with placeholder values. These premade screens were excellent starting points for designers to break apart and build upon as needed.
System Organization
Naming conventions and grouping structures were important for establishing a useful system. This evolved naturally by simply grouping similar elements together. As components were added to the system over time sub-groups emerged to organize components into deeper levels.
Process Rituals
All designers came together on a regular basis to review the component backlog and test and review components. A quarterly retrospective allowed our design team to openly discuss the vision and strategy for our design system and set goals for it over the upcoming product roadmap.
Outcomes
I constructed over 100 components and maintained them across 3 Figma component libraries. Fellow designers on my team estimated a 34% increase in design tooling efficiency.