Lyft Product Language - Figma Enhancements

Initial strategy: revolution or evolution?

As a new hire at Lyft, I was immediately tasked with overhauling our Figma component library.

The first challenge was deciding on an overall strategy. Should the changes be rolled out as they were completed, or should publishing wait until the entire project was done?

This project had been started by a previous designer, but he left before completing it, and the changes had not been published. In the time since the outgoing designer had left, Figma had majorly updated how components are built (most notably through component properties and exposing nested instances). In addition, Lyft designers had already been waiting for this project's completion for nearly a year.

Those factors made the choice clear to me — further delays would risk declining adoption and erosion of trust.

As long as changes were well-tested and value adds clearly communicated, we could actually build further trust and potentially jumpstart adoption with this project.

Evolving Lyft's Figma libraries through strategy, education, and cross-department coordination

Phase 1: Audit (or, "What even are these things?")

To gain context, I first analyzed the library and created a spreadsheet where each component's usage was divided by its variant count (a proxy measure for complexity). The result, once normalized, was a score from 0-1 that allowed me to prioritize work based on components that would have the highest impact for the lowest effort.

Phase 2: Evolution & Education (or, "Here are the things!")

Next, I outlined areas for improvement per-component and set to work. As this project represented 1/3 of my workload, I tasked myself with updating 3 components per week, with some exceptions for high-complexity components (I'm looking at you, List Item).

As updates were completed and published, I would also create digestible 3-5 minute videos demoing the new functionality, posting them to our #product-design Slack channel.

‍

This worked like a charm — designers were energized and quite thankful for the steady trickle of updates.

This work continued for ~9 months before pivoting into migration mode.

Phase 3: Migration (or, "Please stop using those other things!")

The reality is that, for design-only updates, it is unrealistic and unnecessary to expect teams to migrate all of their work to new components. Most design files serve better as historical snapshots and don't require migration.

Instead of setting unreasonable expectations, at the project's outset I asked teams to identify 3-4 high-priority "source of truth" files by the EOY deadline and framed migration as a choice between two paths:

• 🐢 Tortoise Path: Migrate files gradually as updates arrive
• 🐇 Hare Path: Wait until all updates are complete before beginning migration

To incentivize Tortoises, I offered daily migration office hour signups during the component update cycle, and limited availability to 2x/week after that.

With every batch of component updates, I included robust migration guidance (both a textual/graphical guide, video guide, and FAQ).

‍

To be transparent, this is where trouble started. Midway through this project, the Product Design organization ceased to be — Lyft decentralized design, had a major reduction in force, and reorganized the entire product organization. Many of the designers assigned to migrate their team's sources of truth were suddenly no longer employed at Lyft. Those that remained were expected to fill in the gaps, leaving little time for migrations.

Thankfully, I'd set aside a month at the end of this project for me to assist with migrations directly. I handled the highest priority files (team-specific component libraries, for the most part).

The company's new direction had at least one silver lining: At this point, most teams were working on north-star, net-new work that did not rely heavily on older sources of truth.

These two factors combined allowed me to pull out of the nosedive and significantly improve adoption of the new component set.

Outcome / Impact

The goals of this project were to:

1. Increase inserts of the new components (which were then unfinished and only adopted by a small percentage of eager users)
2. Decrease detachments of instances
3. Simplify component architecture, in order to improve library performance, reduce maintenance costs, and make components easier to interpret
4. Increase goodwill amongst designers (as measured by "considered valuable" scores in our biannual LPL survey)

On three of four fronts, this project was a smashing success:

1. Once the EOY deadline hit and the v1 components were fully deprecated, v2 component inserts grew to from 55% to 98% of total inserts
2. Detachments also fell 72% (from 3.08% to. 0.87% of inserts)
3. Variant count reduced by an average of 85%

However, the fourth result was surprising: our satisfaction scores actually sank for the first time in the history of LPL, from 94% to 92% of participants reporting that LPL was either "valuable" or "extremely valuable".

While the scores were still quite high, my hypothesis was that teams needed more targeted attention from systems designers in order to evolve the visual design of these components to better suit their visions. After all, these components had been static in their designs for nearly two years, and our feature designers were innovating and pushing the system's limits on almost every project.

This hypothesis directly informed the Design Foundation's strategy for the year of 2024, where we devoted 1/3 of each systems designer's work to embedding in high-priority feature teams to better understand their needs.