Dev Mode Pilot

Bridging the gap between designers and developers in Figma

With a mature component library and high adoption, my focus shifted towards tooling to improve the designer-developer experience at Lyft. As Figma has increasingly become a place designers invite developers to collaborate, I saw the potential for Dev Mode to better facilitate not only the handoff, but also the messy in-between stages throughout the product development cycle.

This project was entirely self-guided and self-lead, though I had a Design Program Manager (the stupendous Tisha Woods) who assisted with scheduling biweekly meetings and served as a thought partner throughout the project.

Process & Experience

The central question: Would Dev Mode's benefits justify its costs? Specifically, would the financial investment and workflow adjustments deliver measurable time savings? And if so, what would be the magnitude of this return?

To gather consensus and approval from my team, I first created an Assessment Plan, which outlined the key objectives of each phase of the project.

Here I've included an excerpt, as well as my comments on each phase of the process:

Phase 1: Initial Feasibility Check (1-2 weeks)

Objective: Assess Dev Mode compatibility with existing workflows and infrastructure.

• Evaluate integration with current design/development workflows (Example: Connect variable updates to codebase via REST API)
• Test custom code generation plugins with our development stack
• Brainstorm potential Dev Mode plugins beyond code generation
• Assess version comparison tools for designer-developer communication

Comments: The crux of this phase was to rule out any unknown unknowns. It went smoothly, running under schedule as I'd already been exposed to Dev Mode earlier in the year and had reviewed their documentation.

Phase 2: Pilot Project / Plugin Testing (8 weeks)

Pilot Project

Objective: Gather feedback on Dev Mode usability and effectiveness.

• Select diverse designers/engineers to use Dev Mode in active projects
• Collect qualitative feedback through biweekly 30-minute discussions, as well as from those requesting Dev Mode seats throughout the project
• Collect quantitative survey data at the outset of the project, assessing time to complete a variety of tasks
• Analyze for common themes, benefits, and improvement areas

Comments: This was the bulk of the project work. The biweekly meetings were fruitful and educational on both ends — we uncovered interesting pain points (annotating in Dev Mode was much more frictionful than expected, and low visibility to stakeholders unless they were also viewing in Dev Mode), while simultaneously educating folks on some of the more tucked away features of Dev Mode (like the Feed).

Plugin Testing

Objective: Demonstrate Lyft-specific Dev Mode benefits in a more tangible way.

• Create prototype of a Dev Mode plugin, if we've aligned on a direction

Comments: Despite being the single largest dependency on this project, this sub-phase still ran on time. I worked with our Android engineer (a Figma plugin specialist) to create a proof-of-concept prototype for LPL Codegen, which engineers were extremely enthusiastic about.

Phase 3: Cost Benefit Analysis (2 weeks)

Objective: Evaluate financial implications versus anticipated benefits.

• Calculate additional Dev Mode subscription costs
• Estimate time savings and efficiency gains in financial terms
• Make recommendation based on findings
• Present to Design leadership for buy-in (Dev Mode seats come from Design budget)

Comments: This was, perhaps, the most important phase of the project. I synthesized findings and presented them to leadership through an interactive presentation that allowed them to see the impact of Dev Mode per-project and per-engineer/designer.

The most interesting insight we saw from the data here was that designers actually annotate less with Dev Mode. The annotations they create also take less effort. Despite that, engineers have an easier time interpreting design, likely due to how well Dev Mode surfaces things like LPL spacing values, variables, etc. in the UI.

Challenges foreseen

• Quantitative estimations
  • Dev Mode is a collection of small features, and there may not be one standout feature offering tremendous value.‍
  • Potential strategy: A plugin offering large productivity gains that relies on key Dev Mode features could be an exception. We can also ask Figma for case studies or examples from other orgs.
• Adoption barriers
  • The introduction of new tools and workflows may encounter resistance due to the learning curve associated with integrating Dev Mode features.‍
  • Potential strategy: Develop a comprehensive training program that includes hands-on workshops, documentation, and support resources. Encourage early adopters to share their experiences and best practices with their peers.

Comments: These actually didn't end up being much of problems at all, mainly due to the way Dev Mode is designed. Being a collection of small features allows it to serve different engineering archetypes well. Some engineers loved how LPL Codegen simplified writing code, while more "analog" engineers appreciated how well it surfaces variables.

Likewise, integrating Dev Mode features is second nature, as long as designers link to Dev Mode views, which was an easy ask.

Impact

The results here speak for themselves — with an average effort savings of 46% (design) and 32% (engineering), and an estimated ~2,700 hours (design) and ~8,000 hours (engineering) saved per year, Dev Mode was an obvious value add to the business, saving nearly $600k per year (a conservative estimate).

Dev Mode seats are now available to all front-end engineers at Lyft.

The most glaring shortcoming here was biweekly sync attendance — in the future, I'd incentivize attendance either through some sort of leaderboard, or align with a single feature team to more deeply integrate the checkins with their process to maximize qualitative insights.