Lilt: Streamlining the Design with a Design System
🧩

Lilt: Streamlining the Design with a Design System

Worked on
startup
design
design system
👀
TL;DR: Lilt’s UI was all over the place when I re-joined. Set out with the other designer to create a cross-functional design system guild, created Figma Library, documentation of components and patterns, worked with Engineeering on creating Storybook and integrating it into the documentation, ended up taking the number of UI-related tickets to near-zero.
Company
Lilt
Scope
Component library (Figma), implementation (React + Storybook), documentation (Zeroheight), accessibility audits (Able, Stark)
Team
Design System Guild comprised of 2 designers, product managers, engineering managers, and a couple of front-end engineering volunteers
My role
As one of the “founding designers”, I advocated across the company for building a design system, helped coordinate the design systems guild and eventually worked on inventory of the interface, creating a Figma Library and collaborated with front-end engineers on implementation and documentation.

Background

When I re-joined, Lilt was a rapidly growing Series A startup preparing to raise more investment and rapidly grow
This meant growing the teams, growing the business, and growing the product - and also meant that solid foundational work had to be done
I joined in August of 2020 as one of two “founding designers” to establish a proper design function in the company after it relied on contractors for most of its existence

Goals

Improve design-engineering handoff
Lower the amount of reported UI bugs & debt
Streamline the interface and marketing design
Create a repository of live components for developers to use

Creating a guild

I strongly believe that if you only have designers working on a design system, you have a UI kit, at best, not a design system. I wrote about why Design Systems should be products that build products before and I still believe this is a case.
Because of this, our work as designers started with finding people across a rapidly growing company who cared about the goals of this project. This involved finding Product Managers, Engineers, and Executives who wanted to grow out of patched-together interface. This initiative concluded with creating an opt-in, cross-functional design system guild with regular meetings and own plans of action. Doing so helped us seed the idea across the company and grow from there.

Interface inventory

For the first couple of weeks of work, we spent a lot of time just dilligently documenting all the components, patterns, and variations we have, basically going screen-by-screen and flow-by-flow through the entire application. We created Figma documents per functionality or persona and started pasting the screenshots of the application to later group them into thematic groups that would represent components:
notion image

Laying the foundation

Before we jumped to design, we decided to create a set of foundational building blocks and design tokens that would help us ensure consistency across our designs. These were initially just documented, but later moved into Figma Tokens to be able to eventually move them to Github and allow them to inform CSS.
notion image

Streamlining components and patterns

Possibly the biggest chunk of work was taking a good hard look at all the components and interaction patterns that existed across the entire application and radically simplifying them. Luckily, Figma Autolayout and Variants were just released and helped us heavily to accomplish this:
notion image

Documenting

Every reusable component and pattern that got identified got documented in Zeroheight. We chose Zeroheight because it was a lightweight tool that allowed us to document components from Figma as well as Storybook, allowing the reader to quickly compare design, code, and even test out the live component and its variants if needed.
notion image
notion image

Documenting patterns and states

While we worked, we also took a look at common interaction patterns and states inside the application and made sure to document those, too:
notion image

Accessibility Audit

At some point, we realized our marketing color palette might not be completely compliant with contrast requirements of WCAG, and we had to revisit it because we want to keep inclusivity in mind when designing our products. We ended up proposing a minimally different base palette for the product that was fully WCAG AA or WCAG AAA compliant.

Results, learnings & takeaways

Lilt Design System is alive and kicking, supporting the growing front-end engineering and design teams
Number of UI-related implementation bugs and acceptance testing issues went to near-zero for new features using the design system
Speed and consistency of design-engineering handoff definitely improved - in a survey we ran with the front-end team, 100% of people were aware of the design system and used it at least once
Creating the guild helped us manage a cross-functional team of people that cared about delivering great user experiences and that was the major contribution to DS success - planting a seed of design system thinking in every team was what allowed it to grow and thrive
Current contribution process is a bit ad hoc, which works at our scale, but might have to be formalized as the team grows
Some more work needs to be done around onboarding new Engineering hires to the Design System - after doing some ethnographic research and surveying we realized there’s a lot of knowledge around Storybook / live components, but barely any around patterns & documentation

Live examples

🔗
Documentation on Zeroheight