Lyft / developer platform / open source
Clutch_
Six years designing the platform Lyft engineers use to manage projects, run workflows and ship code, starting with its design system.
- My role
- First in-house designer, now lead product designer
- Timeline
- Nov 2020 → now
- Team
- Developer Experience
- Users
- Engineers, engineering managers and PMs
- Designing Clutch
- 6 yrs
- Workflow groups
- 11
My role and who I worked with
I joined the Developer Experience team in November 2020 as their first in-house designer, working directly with the co-founding engineers on a complete redesign of the platform. I own:
- The Clutch Design System, from the first components to ongoing audits
- The dashboard, project detail page and Toolbox
- Workflows, onboarding flows and documentation surfacing
- A reusable “New” feature badge system
- Design audits and interactive HTML prototypes as the main design artifact
- Kanchan GaurMELead Product Designer
- Developer Experience teamEngineering partners
- TanmayCross-functional design partner
- Carlos Carbajal#control-systems, observability spec
Lyft/Developer Experience/Clutch
Summary
Clutch is Lyft’s open-source platform for streamlining infrastructure management, where engineers see their projects, run operational workflows and deploy through ShipIt.
As Clutch geared up for its open-source launch, with contributions coming from internal and external developers, it needed a rebrand, a well-thought-out user experience and a design system that could scale. I set up and still manage the Clutch Design System, and I’ve designed the product from its first screens to today:
- Restructuring the dashboard and Toolbox
- Defining clear layout states for project pages
- Creating a system for announcing new features
- Bringing documentation into the product
The problem and the goal
What needed solving
- An open-source launch on a tight timeline. Internal and external contributors needed one consistent system to build with, and the product needed a rebrand.
- A growing, dense UI. Projects, workflows, deploys and alerts all compete for space on the same screens.
- Workflows that were hard to scan. The Toolbox had to hold 11 workflow groups without becoming a wall of links.
- New features that went unnoticed. Engineers had no consistent signal for what had changed.
- Docs living somewhere else. Guidance sat in infradocs.lyft.net, away from the workflow it explained.
The goal
Help engineers find and run the right workflow fast, notice what’s new without extra noise, and get guidance in context, on a system that scales as Clutch grows.
Less hunting, more doing
- Faster paths to the workflows and projects they use most
- Help that appears inside the task, not in another tab
A UI that scales
- Reusable components that internal and external contributors can build with
- One set of tokens and color rules across every screen
My process
- 01PartnerWork daily with Developer Experience engineers
- 02AuditReview existing screens and patterns
- 03PrototypeInteractive HTML prototypes as the main artifact
- 04IterateUsability studies and reviews with engineers
- 05Spec and shipLayout rules, tokens and interaction specs
Prototyping in the medium
Most of my Clutch work is explored as interactive HTML prototypes, so engineers can click through real states (panels sliding in, cards changing, badges retiring) instead of reading static frames. The prototype grew with each round of feedback:
- Card differentiation
- A Quick Guide panel
- Pinned workflow shortcuts
- A PagerDuty alert interaction
- An inline feedback widget
Building on validated concepts
Tanmay’s “archetype recipes” prototype showed how documentation could appear by page type. I treated it as a validated concept rather than a final spec, then defined the placement rules for each archetype myself.
Building the Clutch Design System
One of my first and biggest tasks was setting up, and then managing, a new design system for Clutch.
A library of components with usage guidelines, built to be accessible and scalable, so internal and external contributors could build consistent screens without a designer in every review.
Strategic approach
As the only designer, I had to build the design system while handling fast-paced UX work. With tight deadlines and rapid iteration, it had to be scalable from the start. Together with the developers, we set clear short-term and long-term priorities, focusing on reusable components and a template-driven approach to layouts, so we kept consistency while speeding up development for the MVP launch.
- 01ResearchDefine scope and goals
- 02BuildIdentify, design and document components
- 03Hand offSpecs and variants for developers
- 04TestTest and iterate with users
- 05MaintainDesign audits, updates and upkeep
Designing not just components
I embedded user research into the system through usability studies on prototypes and other discovery activities, so the component library and interaction patterns were shaped by real user insights. Working with developers on the flow of data, I designed with real data to anticipate edge cases early:
- What if a card description runs longer than one line?
- What if a service provider doesn’t have a logo?
- What if a workflow has more than five steps?
Foundations
Accessibility-driven design
- Color contrast: high-contrast components designed to meet WCAG guidelines
- Keyboard navigation: every interactive element works by keyboard, with clear focus states
- Dark mode: light and dark themes that stay legible in different environments
Developer collaboration and handoff
Developers implemented the components in Storybook with React, and I worked closely with them throughout.
- Figma documentation for every component covered usage, states and variants, for accurate handoffs
- Combined component variants showed developers how each component behaves, reducing the need for extra mockups
Keeping it consistent with a design audit
As Clutch grew quickly, the design system, Storybook and the live product drifted apart. With no dedicated design system manager, I took the lead:
- Proposed and led a design audit, cataloging every component, its properties and its state across Figma, Storybook and the live product
- The audit became a single source of truth for resolving inconsistencies one by one and streamlining future development
How I solved it
A Projects home with guidance built in
- One searchable grid: every service as a card, with a star to favorite the ones you use
- Favorite Workflows bar: shortcuts under the top nav for the workflows each engineer runs most
- Getting Started panel: opens beside the grid and explains Projects, Toolbox and how to start, without leaving the page
Project pages built around what engineers check first
- Summary up top: who is on call, the latest deploy and open PagerDuty alerts, with links out to Loki, Grafana and other tools
- Environment controls: switch environment and refresh rate in one place
- Facet tabs: Facets, Storage, Networking, Taskqueue, Cost and Settings
- Health at a glance: SHA breakdown and healthy pod counts, then a filterable pods table
- Two clear layout states: with and without the map features block, so the page never reflows unpredictably
Documentation where the work happens
- A Quick Guide slide-in panel, later reused for workflows
- Placement rules defined for each page archetype
- Content pulled from infradocs.lyft.net, styled with LPL tokens
- An inline feedback widget inside the doc panel
One pattern for every workflow
I designed a single pattern that every Clutch workflow follows, so engineers can configure a change and execute it the same way each time:
- Title and breadcrumbs: the workflow name, its group and a one-line description of what it does
- Stepper: Lookup, Modify and Confirmation, so you always know where you are
- Resource health: CPU, memory and CPU request shown before you act, with metrics you can configure
- Easy to configure: common settings up top, regions toggled on or off, and each value shown as current versus new
- Clear action: one primary button that executes the change, with Back to step out
Outcome
Designing Clutch, from its first screens to today
Workflow groups organized in the new Toolbox
- A scalable, documented design system with light and dark themes, implemented in Storybook with React
- A design audit that became the single source of truth across Figma, Storybook and the live product
- A dashboard, project page and Toolbox that scale as new workflows ship
- A reusable “New” badge system with clear rules for when markers appear and retire
- Documentation and feedback brought into the product
- Consistent color rules: magenta for actions, blue for navigation, purple for what’s new
Learnings
Clickable HTML prototypes got faster, clearer feedback from engineers than static frames.
Giving magenta, blue and purple one job each made a dense UI easier to scan.
Capping markers and retiring them after use kept “New” from becoming noise.
Without a dedicated manager, Figma, Storybook and the product drifted. Auditing all three brought them back in line.