🔗 Sections: Project details | Prework required | Building the libraries | Creating guidance | Feedback & results
This project appeared simple because the obvious goal was to migrate the Lyft Product Language (LPL) from one design program to another. However, because this was a new tool that most product team members were unfamiliar with, it was very important to adopt a beginner's perspective to ensure this migration didn't cause more problems.
Because this was my second chance at migrating a design system from Sketch to Figma, I heavily focused on applying the good things that I learned from the first experience. This was also an opportunity to make enhancements to the component structure to work better in Figma.
There are several attribute libraries within the Lyft Product Language along with three component libraries.
⬆️ Back to top
To begin the project, I created all the various library files including: Colors, Typography, Layout, Elevation, Iconography, Android/iOS components, and Web components. These were basically empty files to help plan out the work between myself and contractor, Dorian Romero. This not only helped us visualize what we needed to do but also allowed us to take advantage of Figma's collaborative feature of working in the same file at the same time.
In order to take advantage of Figma’s advanced features we opted to recreate the libraries rather than import from Sketch. I learned from my past migration project that it is more efficient to build from scratch instead of updating imported components.
The internal spacing system that I created ensured consistency on each component page.
First, I created a system within a system that would apply to every element in the file which would essentially build in a certain level of quality and consistency into the library. By taking the time to do this, I was confident that every LPL library would be set up the exact same way even though multiple people were building the files out.
Additionally, I set up a visual hierarchy to help distinguish between the core components and the internal components that make them up. All the core components are placed in frames that have a 4px inner outline without a background fill; these act as the component sticker sheet.
The internal components are placed in a Frame with a white background. Displaying all of the internal components allows the maintainer to see a snapshot of the options that can be used to reconfigure the core component into the supported variations.
An example of the core component and internal components for LPL's Carousel Page Indicator.
⬆️ Back to top
Dorian and I worked over the course of 3 months to build out all 10 of the LPL libraries. As we worked on each library, I considered how we could leverage internal components (shared elements) across multiple core components. For example, since the Dropdown, Text Area, and Text Field components were similar in structure that included a text layer and background outline, I built all these components using the same internal components (elements shown in the outlined frames below).
Shared text and background elements used to build Dropdown, Text Field, and Text area components.
Another aspect that we considered is how the current components were named. A design system Android engineer, Alex Lockwood, and I took a pass at updating the naming structure and came up with one that could be applied to all components and its variations as well: