ux
Pace Design System Improvement & Adoption
Introduction
This document is part of a larger initiative that I proposed for the holistic improvement of Pace’s IOS/Android native apps, React Native, Merchant App and Internal Tooling.
The Problem
The current system is referencing over 12 UI kit libraries and over time its usage, iteration, maintenance, and enforcement have taken a backseat leading to inconsistency and not-so-efficient building of interfaces that meets Pace’s standards.
Growth has also presented the new branding guideline on which our digital experiences should base their foundations as well.
Growth has also presented the new branding guideline on which our digital experiences should base their foundations as well.
Pace's component libraries in different Figma teams
Objectives
1. Help teams achieve the following in building Pace products:
- Consistency, Reusability, Speed
- Iteration of components over time — more thoughtfulness can be put into each component as they are refined.
- Empowers non-visual designers to create beautiful things
2. Improve the current Design System by using Design Tokens
Current State of The Design System
We started documenting our UI components in Figma more thoroughly and opened it up for other Product Designers to contribute. But, we're still missing thorough documentation for our motivations, the principles behind our UI components, and how to use them. Since we’re still quite small and things are always changing, a quick Slack message or a walkover to a desk can clarify any additional cases quite easily and effectively.
Structuring a design system
Growing Pace's design system
Teams must consider three areas of focus to support the maturing of a system. These aren’t sequential. It’s a cycle where we essentially do all three at once.
Educate to Create Awareness — This is advocacy for the idea of a design system and the concept of why a design system will be necessary for the organization. It will be more one-way interaction. Identify how we will approach the system, communicate with other teams, inform how to engage the system, and what nuances & rituals to set up.
Engage Teams — Establish two-way interaction and will start to learn from your design system users - Designers/Developers. We will get feedback, and it will help to grow the system. Including others is necessary for mass adoption and contribution to the system.
Evolve and plan for the future — At this point, it should be a team effort, and your shared objective is to improve the system. The system requires iteration, testing, evolving, and prioritizing of your design system assets, documents and process.
Educate to Create Awareness — This is advocacy for the idea of a design system and the concept of why a design system will be necessary for the organization. It will be more one-way interaction. Identify how we will approach the system, communicate with other teams, inform how to engage the system, and what nuances & rituals to set up.
Engage Teams — Establish two-way interaction and will start to learn from your design system users - Designers/Developers. We will get feedback, and it will help to grow the system. Including others is necessary for mass adoption and contribution to the system.
Evolve and plan for the future — At this point, it should be a team effort, and your shared objective is to improve the system. The system requires iteration, testing, evolving, and prioritizing of your design system assets, documents and process.
From top: Salesforce's Lightning and IBM's Carbon design systems
In the end, a mature design system accelerates design, prototyping, and development and decreases the time you spend fighting your code.
Design Tokens
Design Token is a concept created by Salesforce in 2016. Design Tokens are the basic atoms of a design system such as Salesforce’s own Lightning Design System.
They are the single source of truth that stores design decisions distributed across design tools and coding languages. Use them for colors, typography, shadows, border radius, spacing, borders, animation, icon sizing, etc. It is an essential practice to effectively maintain consistency across design and the production product.
They are the single source of truth that stores design decisions distributed across design tools and coding languages. Use them for colors, typography, shadows, border radius, spacing, borders, animation, icon sizing, etc. It is an essential practice to effectively maintain consistency across design and the production product.
Design tokens are platform-agnostic variables that represent the look and feel of your brand and product.
The Basic Workflow – Without Design Tokens
- Designer updates a style in a design tool
- Designer documents the changes for the design handoff
- Engineer updates the component’s properties (CSS, LESS, SASS, etc.)
- The design team confirms the changes during quality assurance (QA)
There are several problems with this workflow:
- Creates more work and attention to detail during the design handoff.
- It is prone to errors and miscommunication.
- Creates more tickets, thus increasing technical debt.
- It costs unnecessary time and money making the changes and fixing any corresponding errors.
Solution: The Design Token Way
- Designer creates/updates a style in Figma (Figma specifically because we will be using a figma-specific plugin)
- A design tokens generator (platform/figma plugin) updates a centralized repository creating a platform-agnostic file (JSON/YAML)
- Engineers pull the new repo, add any new tokens, and automatically update the project’s styles specific to the platform (iOS, Mobile, Web, etc)
Design Tokens are platform-agnostic hence they can be shared across different disciplines, tools, and technologies.
Design decisions from various tools are converted into platform-agnostic format such as .json to be consumed by different technologies
Project Details, Timeline and Status
Screenshot from my confluence document
The project timeline in my confluence document
The whole exercise took about 3 months to complete on the design part. At present, we are working with our entire development team to make changes to the front-end so we can fully utlilize the power of design tokens within our design system.
Updating foundational design element such as the colour on the Pace app is now faster based on the POC the devs have implemented. Instead of updating all instances of the colour element in order to implement the change, they only need to extract the new .json file with the properties to their component styles. This is work in progress. A design system will never be complete as long as someone is using it.
Updating foundational design element such as the colour on the Pace app is now faster based on the POC the devs have implemented. Instead of updating all instances of the colour element in order to implement the change, they only need to extract the new .json file with the properties to their component styles. This is work in progress. A design system will never be complete as long as someone is using it.
Pace 2.0 Design System
Key takeaways
Constant communication within the team was paramount to the success of the project. We know that a design system will only be effective if everybody is doing their part.
Most importantly, design tokens help scale products to improve consistency, reusability, speed, and maintainability of a design system.
Most importantly, design tokens help scale products to improve consistency, reusability, speed, and maintainability of a design system.
%402x.svg){kind=icon}