Go1 · 2025
Scaling a Design System
TL;DR
Elysium, Go1's design system, was theoretically enforced but practically ignored. A rigid, process-free system with no documentation had pushed designers to work around it rather than with it. As Design System Lead, I reframed the problem — from one of compliance to one of governance — and introduced a federated model that gave designers a legitimate, structured way to handle variation. The result is an ongoing cultural shift: active contributors grew from zero to three, conversations about system decisions are happening before work ships rather than after, and a team that previously worked around the system now understands it well enough to make good decisions independently.
Certain information has been omitted or obfuscated in this case study. The opinions presented here represent my views alone, not of my current or past employers.
Elysium is Go1's design system, shared across a team of six designers working across different product streams. As Design System Lead, I'm the sole specialist — responsible for both the strategic direction of the system and the hands-on work of building and maintaining it.
That dual responsibility is both the role's strength and its central tension. It means I'm close enough to the work to understand what the team needs, but stretched thin enough that scalability isn't optional — it's essential.
The Problem — Life Finds a Way
When I took on the role, Elysium was built on a philosophy of control. The designer who created it believed that locking the system down would force adoption — if designers had no flexibility, they'd have no choice but to follow the rules.
In theory, sound. In practice, chaos.
Rather than working within the system, designers found ways around it. Components were detached and modified locally. Custom variations were built in isolation, invisible to the rest of the team. Product teams shipped their own solutions without anyone else knowing. The system wasn't being ignored out of laziness — it was being bypassed because it offered no legitimate path for handling the real complexity designers faced every day.
Compounding this was the absence of any supporting infrastructure. There was no process for requesting changes, no documentation explaining how to use the system, and no framework for deciding when a custom solution was appropriate. Designers weren't equipped to engage with the system confidently, so most didn't try.
Reframing the Problem
The instinct in this situation is to tighten the controls — better enforcement, stricter rules. But that was the approach that created the problem in the first place.
The real issue wasn't designer behaviour. It was the model itself. A locked-down centralised system assumes that standardisation and flexibility are opposites, and that compliance can be achieved through constraint. What it actually achieves is a system that works on paper and fails in practice — because designers, under real project pressure, will always find a way to get the job done.
The shift I needed to make wasn't about rules. It was about governance: giving the team a structured, shared understanding of when to use the system as-is, when to build on top of it, and when a one-off solution is the right call.
The Solution — A Federated Governance Model
Distributed Ownership
The core shift was moving from a centralised model — where everything flowed through me — to a federated one, where each designer became a formal representative for their product stream. Rather than consuming the system passively, designers were now active participants in it: responsible for evaluating their own work against the system, making documented decisions about when and how to deviate, and contributing solutions back when they had broader value.
This reframing was as much cultural as structural. Contribution stopped being something designers did by accident when they happened to build something reusable. It became an explicit part of how the team was expected to engage with Elysium.
The Three-Tier Taxonomy
To make distributed ownership work in practice, designers needed a shared vocabulary for the decisions they were now responsible for making. The three-tier taxonomy provided that: Design System Components are the shared, rigorously maintained foundation available across all product streams; Recipes are product-specific compositions built from system components, legitimising work that would previously have been done in secret; and Snowflakes are acknowledged, documented one-offs for genuinely unique problems. Rather than a binary choice between “in the system” and “going rogue,” designers now had a structured, legitimate way to handle the full spectrum of real-world complexity.
The Decision Framework
To operationalise the taxonomy, I built a decision framework and flowchart for both designers and developers — a practical tool for answering the day-to-day question of “what kind of component is this, and what do I do with it?” The framework also acknowledges something the previous model ignored: teams work under real deadline pressure. Rather than treating timelines as an excuse for non-compliance, the process explicitly factors them in, helping teams make the right call for their current situation without being paralysed waiting for a perfect system solution.
Critically, the model isn't a one-way street. Recipes and snowflakes have a defined path back into the core system. When a product-specific solution proves its value — used consistently, stable in production, and generalisable beyond its original context — it becomes a candidate for graduation into Elysium. Custom work no longer disappears into product codebases. It feeds back into the system, making it stronger over time.
Outcome
The governance transformation is still underway — cultural change at this level doesn't happen in a quarter. But the signs of progress are meaningful.
Three designers are now actively contributing to the system — up from zero when the governance model was introduced. Ad-hoc workarounds haven't disappeared, but they're decreasing as the team gains confidence in the new framework. More importantly, the nature of conversations has changed. Designers are now talking to their teams — and to me — about system decisions before they make them, rather than after. That shift from isolation to dialogue is, in many ways, the whole point.
What this work has reinforced is that design systems are fundamentally a people problem. The components matter, but the model that governs how people interact with them matters more. A system that demands compliance without offering understanding will always lose to the workaround — because under pressure, people don't follow rules they don't believe in. They follow frameworks they trust.
Building that trust is slower than building components. But it's the only thing that actually scales.