A library is not a system
The components existed and were used, but teams worked around the library, not with it.
The feedback was blunt:
"Who maintains this component?"
"It's faster to start from scratch."
"Changes happen but we don't know when."
"We don't know how to submit updates."
— Design system feedback, 2021None of it was about component quality. It was ownership, communication, and trust. The technical foundation existed. The organizational one didn't.
The real feedback — actual frustrations in the team's own words
First, everyone needed to mean the same thing by the same word
A five-stage lifecycle gave every component a shared, known status.
- Snowflake: product-only, documented but ungoverned
- Experimental: proposed to the system, monitored in use
- Frozen: locked for stability, gathering feedback
- Stable: adopted, versioned, fully documented
- Deprecated: removed or archived
For the first time, a designer and an engineer could say the same word about the same component and mean the same thing.
Snowflake → Experimental → Frozen → Stable → Deprecated
A real component tagged with its status badge — the abstract lifecycle made concrete
Then the process had to survive contact with the roadmap
Three rituals made the governance real.
Contribution workflow. A five-stage path from Slack request to version release, every step owned. Triage (design and engineering deciding together what belongs in the system) killed both the rebuild-what-exists pattern and the DS-team-as-bottleneck pattern.
Every step had an owner — triage was the one that changed everything
Office hours. A standing open slot for anyone to bring questions. The point wasn't the answers, it was lowering the friction of asking. That's where we learned what the system was missing.
Office hours — a standing ritual, not aspirational
Domain listening sessions. After the Figma file structure rollout landed badly, I ran per-domain check-ins with Hospitality, Dashboard, Financial Services, and Guest. The dev-ready file model got killed by consensus, not a top-down call, and a Confluence index replaced the master Figma file.
Listening session synthesis — the decision came from the teams, not a top-down call
The point was to stop being the gatekeeper
We moved to a federated model where teams own their components and the core team enables instead of blocks.
Ideas start in Playground, get documented in Component Lab, and only finalized reusable assets get promoted to Aero, with real criteria: stable in production, clear guidance, accessibility considered, lead sign-off.
Teams stopped asking "is it ready yet?" and started contributing improvements back. We also defined guidelines beyond components (accessibility, content, illustration) so the system covered how things get made, not just what's in the box.
Playground → Component Lab → Aero → Dev Ready
The honest part: governance is easy to design and hard to keep alive
When the engineering team was cut and the weekly syncs stopped, the system drifted.
The framework was sound. Then layoffs hit, priorities shifted, and the weekly Aero 2.0 alignment calls stopped. The drift wasn't a design system failure. It was a resourcing consequence.
A system's health is only as stable as the org's willingness to protect the capacity that maintains it. When that capacity disappears, the documentation, the lifecycle stages, and the contribution model don't help. The system drifts, quietly, until the damage is already done.
The quiet drift — the weekly sync cadence goes dark, and the system keeps moving without the coordination layer
So we redefined success as adoption, not output
I built the OKR framework that measured whether teams actually build with the system, not how many components exist.
| Status | Teams |
|---|---|
| Fully using Aero | 24% |
| Partially using | 43% |
| Not using the system | 28% |
| Still on legacy Nexus | 5% |
Adoption tracked three things: whether a PM protected the investment, whether engineering had bandwidth, and whether a product was new or legacy. Teams with aligned PMs and dedicated eng used Aero consistently. Teams without either rarely did, no matter how good the components were. Adoption isn't a design system problem. It's an organizational one.
24 / 43 / 28 / 5 — the adoption snapshot as a visual, readable in one second