How to Systematize Internal Products
We designed the Lyft Product Language mobile first. All of our design system attributes and components were crafted with small screens, unreliable internet connections, and touch inputs in mind. When we later expanded the system to support Consumer Web products on Desktop devices, we seemingly realized the promise of a mobile first design strategy. Screen designs grew elegantly across different surfaces and our core attributes and components largely stayed the same across platforms. But, like many design systems teams, we drew the line at Operational/Internal Web products.
Over time, Lyft’s suite of internal, operational, tools grew to over 75 — built and maintained by multiple teams of designers and engineers. These internal product teams were largely left to their own devices with no centralized resources and guidelines. As a result, the quality and consistency of these products suffered. In several cases, backend engineers created entirely new products without any designs, designers, or even frontend engineers at all.
70 products ended up being built on top of other systems like Material UI and 8 teams started their own systems — resulting in lots of duplicative work and disparate styles.
Over 6 months, we interviewed and surveyed designers and engineers across these product teams to understand pain points and inform our approach to systematizing ops products. We learned that screen designs and components are usually designed with just one product in mind and then adapted with patchwork solutions when new use cases come up. We also heard that due to time pressures and resource constraints, designers rarely have time to do accessibility checks, define all component states, or write documentation for new features. Understandably, we’ve ended up solving for similar interface constraints and data display use cases in pretty different ways across this fragmented product landscape.
In this series, we’ll cover how we approached reconciling these differences systematically and how we expanded a mature design system to support a whole new suite of products, users, and use cases.
Part 1: Growing (and Shrinking) Pains — Holistic spacing and visual density
Part 2: Typography for Data
Part 3: Russian Nesting Figma Libraries (coming soon)
Part 4: Building Blocks (coming soon)
Part 5: System Citizenship — Adoption, Contribution, and Migration (coming soon)
