Enhancing Figma Resources
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?”
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).
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.
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.
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!
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!
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.
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.
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.
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.
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.
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:
- Find early component usability testing valuable
- Understand the systems maintenance process and the effort involved
- 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.
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:
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!
