.svg)
Limeade
Building a consistent design language across teams
Team
- 1 x Product Manager
- 4 x UX Designers
- 1 x Engineer
- 1 x UX Researcher
Role
Year
Overview
Limeade is an employee experience platform that focuses on well-being and workplace culture. As engineers began to migrate the product to React, I was tasked with addressing design inconsistencies and providing visual design guidance for new React components. With no source of truth for design styles, addressing inconsistencies and preventing new ones was a challenge.
The scope soon grew to building buy-in for a new design system and leading the creation of a shared pattern library. I worked cross-functionally with designers, researchers, and engineers to establish a central source for design assets and align on what good design means at Limeade.
Impact
3+ hours saved
Average time saved on each project not having to recreate design assets
80+
components
Published as a team library along with the latest updates to accessibility
Improved consistency
From outdated and inconsistent style guides to a single source of truth for design styles
The solution - one brick at a time
We approached the problem in small, manageable steps to demonstrate value and build buy-in for a design system. The foundational elements were missing and served as the low-hanging fruit. We focused on establishing a visual design language and pattern library to quickly improve design consistency and productivity. As we made progress, our goal was to sustain the momentum and build organizational support.
Challenges
The primary risk to building a design system was the lack of dedicated resources. Designers and engineers had to prioritize roadmap initiatives over design system work. Since I was tasked with addressing design inconsistency, I could devote more time to this effort. However, for this project to continue, dedicated resources would be essential.
Research
Our first step was analyzing the current state of design practice at Limeade. This began with a visual UI audit to identify design inconsistencies. We then interviewed designers, engineers, and PMs across the company to expand our knowledge of the way teams work and communicate.
Designers and engineers highlighted the amount of wasted time searching for the latest designs or finding out if UI exists. The only way designers stay up-to-date is through critique sessions, browsing old files and check-ins. We also discovered a disconnect between marketing and product. Teammates from marketing also found it difficult to stay current on the latest designs and product initiatives.
Not knowing if a UI component exists or not is a big concern.”
- Engineer
“We tend to look at what marketing has done but sometimes it is unclear how the product should look or behave.”
- Designer
Making the business case
To build buy-in and make a stronger business case for a design system, we presented our research findings and UI audit to key stakeholders. We focused on how a design system would align with company OKRs and highlighted the benefits of a design system such as increased productivity and product quality.
Aligning on design principles
Design principles served as the starting point for building a shared language and greater alignment. Prior to this, Limeade had no product design principles. To establish new ones, I facilitated a 2-day workshop with teammates from product and marketing. After aligning on new principles, we presented the results of our workshop to other teams and demonstrated how design principles act as a compass for design decisions.
Design foundations
Close collaboration between teams made progress towards a consistent design language possible. While we pushed for better guidance on branding and white-labeling, small steps were made in the meantime. Reviewing styles from the recent rebrand and our UI audit presented other opportunities for alignment and design consistency. Our efforts resulted in a single style library that could be referenced by teams and used for future design components.
Improvements to accessibility
I incorporated WCAG contrast levels with each color to simplify design decisions and eliminate guesswork. As the Limeade product went through a series of accessibility tests, this gave designers and engineers a place to reference when addressing contrast issues.
Building a scalable pattern library
I used atomic design as the framework for building our pattern library. Using the visual styles we defined, I began with the smallest atomic components and combined them to form progressively more complex patterns and templates.
Green light for design tokens
After meeting with engineering leads, we received the green light to work on a proof of concept for design tokens. One of our goals with the POC was to gain more engineering buy-in for the design system. We used Figma and a tool called Style Dictionary to manage the tokens. This step involved lots of back and forth collaboration with the engineer as we learned how to structure the design tokens and JSON files properly. Once set up, we were able to update visual styles across all platforms from a single source.
Design token architecture
I was tasked with defining the naming structure of our design tokens and documenting them in Figma. Base tokens served as the building blocks for providing consistency and flexibility. Once the base tokens were defined, I moved on to decision tokens. Lots of research went into this step along with close collaboration with the engineer.
Engineering hand-off
The hand-off process involved some trial and error. I used a Figma plugin to generate the JSON files needed for design tokens. For the tokens to work with Style Dictionary, I had to manually update the JSON before handing it off to the engineer. There was lots of room for improvement but we came up with a system that worked for the proof of concept.
Changing priorities and accessibility
Unfortunately, a change in roadmap priorities and leadership caused the design system effort to be put on hold. Resources grew very thin with engineers and designers, including myself, being pulled into different initiatives. I continued to chip away at documentation and a mobile pattern library but progress became slow.
Accessibility testing of the product became one of the top priorities. I worked part-time with the accessibility team to address design bugs from testing. Since we now had a central source of truth for design assets, I could quickly update components to reflect the latest accessibility changes.
Areas of improvement
As the scope of this project grew, we were presented with bigger challenges. Addressing issues such as legacy code or white labeling were difficult problems to navigate. We did our best to take small steps forward and embrace the learning process. However, it would have been great to have someone there that could accelerate the learning curve. Seeking mentorship or consulting with someone with prior design system experience would have been ideal.
