Enhancing Figma Resources

Jeremy Dizon
Tap to Dismiss
Published in
10 min readSep 2, 2022


As design programs like Figma release new features, existing design system resources quickly become outdated. Yes, the existing components are still usable but they’re just not as flexible for system users or as efficient for library maintainers as they could be with the new bells and whistles. So designers increasingly detach components — our total monthly component detachments have nearly doubled over the past year. In fact, in our most recent systems survey, 29% of designers believed their product had designs that push the boundaries [of the system]. Tellingly, only 14% of engineers believed the same. Without incorporating the latest features, we inadvertently widen the gap between designers and engineers.

Unfortunately, from a design systems perspective, incorporating these new features isn’t as easy as it appears because they may result in breaking changes to the current component set or require system users to learn a whole new workflow.

At the end of the day, we must ask ourselves:

Will these enhancements add value to system users?”

And if the answer is yes, and there are breaking changes, the next important question we must ask should be,

“Is the effort to incorporate these enhancements worth it?”

Header image with block of text on the left and cropped phone screens on the right.

At the beginning of 2022, I led the project to enhance the Lyft Product Language (LPL) Native component library. In this blog post, I walk through the strategy we used, the reason behind incorporating lightweight user research, and some key learnings from this 6-month long project.

Our strategy

As I alluded to in the introduction, incorporating the new Figma features to the current LPL components resulted in breaking changes. But, we theorized that fully incorporating Auto-Layout and the Variants features into our components would ultimately decrease component detachment rates by making them more flexible and therefore usable across all product features. Paraphrasing Linzi Berry:

‘The juice IS worth the squeeze’

Given breaking changes were inevitable, we set out to minimize disruptions and avoid forcing system users to update their components all at once. I realized the best strategy was to essentially create a new version of each component within the existing library. Users would automatically have access to the new components without losing access to their existing components — empowering each designer to make the decision to migrate for themselves initially. This approach was also key when thinking through how to user test each enhanced component (stay tuned).

Two sets of Toggle button components on the same page; existing ones to the left and enhanced ones to the right.
New components placed to the right of the original component

Because we knew that system users use the Asset panel to search for components, I prefixed each enhanced component with [LPL Beta] to distinguish them from the existing [LPL] components.

Gif of Figma’s Asset panel and typing “LPL Beta” into the search bar.
Searching for “LPL Beta” components within the Asset panel

And once all the components are enhanced, the phased migration plan would include:

  • Communicating with product teams to plan for this work on their team roadmaps (at least a quarter in advance)
  • Creating tutorials and screen recordings to guide product designers how to migrate to the enhanced components
  • Renaming the existing components to [Legacy] and updating the enhanced components to use our standard [LPL] labeling
  • Setting the deadline to migrate all necessary Figma files which will also be the date the [Legacy] components will be archived, and,
  • Scheduling workshops where the design systems team and product designers perform the migration together (picture Apple’s Genius Bar)

The enhancements

Applying the new Figma features gave us a chance to re-architect our system components that admittedly still had structural holdovers from our old Sketch library. Let’s use a particularly gnarly component — the mighty List Item — as an example. This component hadn’t been touched since its creation over 3 years ago due to its almost infinitely reconfigurable permutations and its ubiquity in our products (510,000 instances to date)! We knew that if we changed the structure, Figma would default all 500k+ component instances to the original component’s content. So naturally, I tackled enhancing this component first.

A list item component broken up into 3 areas, Start, Middle, and End. The left version displays the order for left to right languages and the right version displays the order for right to left languages.
List item component consists of 3 areas: Start, Middle, and End

For context, the LPL List item consists of 3 areas: Start, Middle, and End which allows system users to swap to different elements. For example, within the Start area, the Drive Default size component supports either an icon, selection control (like a checkmark or radio button), and an avatar image. Similarly, the Middle and End areas have their own supported elements. That’s a whole lot of variations!

All the options that a List item’s Start area can have based on the size of the component.
Internal elements supported for the Start area

To help cut the number of variations down, I first simplified the “Internal elements” by applying the Variants feature which allowed me to group and organize similar components into a single container, like all the Start area elements. Now, the icon, checkmark, radio button, and avatar image elements are grouped together in a “Start” variant. I did the same for the End area elements, labeling that variant “End”.

For the Middle area that supported the required component content, I applied the Auto-Layout feature which allowed my content block to grow to fill or shrink to fit, and reflow as their contents change. Now, when system users hide a subtitle layer or copy-pastes in very long content, the content block resizes and wraps to a second or third line accordingly. Plus, by applying the Variants feature, the “Middle” internal elements went from 12 swappable options to only 2!

All the Start, Middle, and End options displayed in a single frame when utilizing Auto-Layout and the Variants features in Figma.
Supported internal elements after applying the Auto-Layout and Variants features (top row: Focus size, bottom row: Drive size

This was the strategy I used to enhance the rest of the Native components, finding opportunities to group elements and components as Variants as well as apply Auto-Layout for those components with variable content.

The Plot Thickens

During the project, Figma actually launched a few new features including Component properties. {Sarcastic tone} Thanks a lot, Figma! Just kidding.

Figma video tutorial: Component properties

This new feature gave systems maintainers the option to apply these properties to components with a parent-child relationships:

Though super powerful, I didn’t immediately add this to the project’s scope. But it did justify the need for the design systems team to plan for enhancement work on our project roadmap.

User research

Even before this project began, I knew I wanted to find a way to get feedback from design system users. Design systems mostly play the reactive game and so this was an opportunity to incorporate actual user testing right from the start to help speed up the feedback loop for the enhanced components.

To set the tone with system users, I leveraged them to create a prioritized list of components to enhance. I first placed each component in a group based on similar functionality (ie Button, Circular button, Icon button, and Text button were placed in the Button group while Inline message card, Toast, and Tooltip were placed in the Messaging group). I then created a Slack post where they could vote on which component groups should be enhanced first.

Message posted in Slack with component groups listed from 1 to 9.
Slack survey to help decide which component groups should be enhanced first

To be honest, the component group I thought users would choose first didn’t align with the actual results. Right off the bat, user feedback proved valuable! From here, I set my project roadmap and began strategizing the LPL Beta Tester program.

What’s the LPL Beta Tester program?

I’m glad you asked! I wrangled at least 1 product designer from each feature team to join together to systematically test each component within a component group. Within the project roadmap, I set up testing weeks for each component group and provided all the necessary artifacts to make it easy to stress test enhanced components either asynchronously or during testing workshops scheduled during that week. Among the artifacts, I created robust testing instructions, a Figma file playground to perform the testing, and a Google Drive folder for those async testing users to place their screen recordings of their testing. Let’s dive into each artifact together.

Message posted to Slack outlining the LPL Beta testing program.
Slack message to kickoff the LPL Beta Testers program

Testing instructions

For each component within a component group, for example, the Button component, I provided step-by-step instructions to fully test both the functionality and flexibility of the enhanced version. The first obvious test was ensuring beta testers could effectively find the [LPL Beta] Button component within their daily workflow, which is why I provided a link to where it was located in the main library file as well as give them the option to use the Figma Asset panel search.

3 Google doc screenshots layered on top of each other, displaying instructions how to test the enhanced Button component.
Testing instructions to test the enhanced Button component

Next, the instructions asked beta testers to perform specific tasks to test the flexibility of the enhanced Button component by using the Design panel to swap to different button types as well as replace the label content. I also included a screenshot of what the testing results should be for those visual learners like me.

Finally, to complete the [LPL Beta] Button component testing, I posed questions for beta testers to answer to help focus the feedback I was looking for.

Figma playground file

To help consolidate all the beta tester’s work, I created a playground file with different pages broken out for each component of a component group. Taking our Button component group example, the playground file consisted of 5 pages with specific testing instructions copied over from the testing instructions gDoc.

One page within the Figma playground file displaying the testing instructions on the left and testing area on the right.
Each component had a page in the Figma playground file for beta testers to test them

Async testing recordings

I didn’t want beta testers to feel obligated to attend a testing workshop during testing week, so I provided a Google Drive folder link within the testing instructions for those who prefer to test asynchronously to save their screen recording to. All I asked async beta testers to do was talk through their process as they screen recorded, allowing me to observe their experience testing the enhanced components and understand their thought process.

What we learned

This project allowed the design systems team to not only make our current component set more flexible to accommodate the various use cases across product teams but also really connect with our users. The LPL Beta Tester program was a true gauge to get a sense if product designers would:

  1. Find early component usability testing valuable
  2. Understand the systems maintenance process and the effort involved
  3. Want to collaborate with design systems more often

Halfway through the project, I asked for specific feedback from LPL Beta Testers about the program and got some interesting thoughts. A beta tester said,

“I joined into the testing process late, during the List component week; however, the materials that Jeremy prepared made onboarding extremely easy and straightforward. The testing instructions and Figma files he provided were very comprehensive, so it was clear how to test the component regardless of the testing format (workshop-style or async). The thoughtfulness and craft that Jeremy put into the testing materials definitely stood out to me.

I even got a really nice tidbit from a design systems teammate as well,

When I had to fill-in for Jeremy as the host of one of the testing sessions, it was so easy because everything was explained in detail in the instructions and I was able to answer beta tester questions just by referencing the doc.

Countless beta testers commented they hoped for more testing opportunities in the future as well which helped validate the extra effort involved to create a testing program for a project that traditionally only involves the design systems team. But the appetite from product designers to support lightweight user testing really opens up the door to get them more involved with other design systems projects moving forward.

A page displaying the LPL Beta Tester participant badge at the top and the beta tester’s name and role below.
Props to all the LPL Beta testers for going on this 3-month journey with us

Education opportunities

Any kind of change to the existing libraries will not only require communicating to users what changed but also a way for them to understand the impact of those changes. Whenever Figma releases any new feature, they also provide a Playground file that clearly breaks down the feature to help users feel comfortable. For this project, I planned to reuse the testing scenarios within the Testing instructions and playground files I set up to help showcase the flexibility and efficiency of the enhanced components. But I didn’t want to just share the LPL Beta testing resources and call it a day. I planned to create short videos and gifs to dynamically show their value all while providing further education about those powerful Figma features like Auto-Layout and Variants:

A gif displaying an Auto-Layout demo on the left and Variants demo on the right.
More flexible components that utilize Figma’s Auto-Layout and Variants features

In addition to these videos and gifs, I planned to host a Figma lab or lunch and learn session to give users the opportunity to learn and ask questions in a more casual environment. This also would provide a good baseline on which educational method resonated with users the most so the design systems team can utilize that data for future projects.

In conclusion, this project broke ground to not only get product designers involved in the systems maintenance and enhancement nature of design systems but also helped benchmark the level of effort it takes to incorporate the latest and greatest Figma features. With this project, prioritizing Figma enhancements on our roadmap becomes more important to continue providing usable components that allow the flexibility to support product designers in their current projects as well as future ones.

To continue the discussion on how to update components when there are breaking changes, check out this amazing article.

This article was written by a former Lyft product designer, Jeremy Dizon, who is now a member of the Design Systems team at Disney Streaming, and Runi Goswami, a design systems manager at Lyft. Please subscribe!



Jeremy Dizon
Tap to Dismiss

Product Design / Design Systems super-monkey 🐵 | @jeremydizon on Twitter 💬