Case study · 2019–21

Greenroom

Design system and component library

Greenroom — summary

Problem
Six product teams had six visual languages and different keyboard behavior for the same controls.
Role
Front-end lead
Years
2019–21
Stack
TypeScript · Svelte · Storybook · Playwright
Components
48
Product teams
6
UI defects
down 37%

Greenroom.md

This case study is sample content. Replace it with verified work before production deployment.

A migration path is part of the component

The library shipped with examples that matched real product screens, codemods for the mechanical changes, and a compatibility layer that let teams move one route at a time.

Behavior before appearance

We wrote keyboard and screen-reader behavior into each component contract. Visual variants came after the interaction model, which kept small product differences from turning into different controls.

Ownership stayed distributed

Product engineers could propose and maintain components. A small core group guarded the contracts and release process rather than becoming the only team allowed to change the interface.

Make the hard choice visible.

A durable decision leaves enough context for the next person to understand the tradeoff, not merely the outcome.

Go to

↑ ↓ moveEnter openEsc close