Design Systems Are Governance Projects, Not Design Projects — Most Organizations Build Them Backwards
The Claim
Most design system failures are organizational failures misdiagnosed as technical ones. Teams invest in component libraries, token architecture, and Figma files, then discover that adoption stagnates, components get detached, and teams route around the system. The primary causes are governance gaps, not design quality gaps.
The Panel Evidence
EvolveDigital Toronto's design system panel — practitioners from Thomson Reuters, Bell, RBC, and Lyft — spent 61 minutes systematically dismantling the 'component library' misconception. Arena Stoka's framing was precise: a design system is 'a relationship between design and development, kind of like a contract that has to be maintained.' Andrea Ang invoked Kevin Foster's principle that 'if you build it, they won't come,' positioning adoption as active community work that must be resourced and sustained, not a passive outcome of technical quality.
The panel identified the canonical failure patterns: - Designers detaching components for convenience, then not communicating changes upstream - Teams adopting the system without understanding their maintenance responsibilities - Misaligned technical stacks making adoption impossible regardless of intent - High-visibility products being given political exceptions that undermine the system's credibility
The Loblaw Case Study
James Harrison's four-year Helios design system journey at Loblaw Digital adds texture to the panel's claims. Running a federated model across 20 websites and 9 apps, Harrison described the federated approach as 'extremely difficult to govern' and explicitly advised against it, citing Nathan Curtis and Spotify as organizations that abandoned federated models after painful experience. His workarounds — Figma school, dev school, a volunteer shadow team, a steering committee — were all governance and community interventions, not technical ones.
His most striking insight: allowing imperfect components into the system was strategically correct because **being in the system was more important than what the system was**. This is a governance principle, not a design one. Technical purity, enforced rigidly, produces a beautiful system no one uses.
The McGill Scale Test
Joyce Peralta's presentation on McGill's 1,000-site Drupal ecosystem — 1,300 active content creators, 6,000–8,000 weekly edits during peak periods — demonstrated that at institutional scale, governance is the only mechanism that works. After five years of governance framework development, Peralta described the community of practice as 'the most scalable tool for implementing digital standards.' Technical standards without community infrastructure are unenforceable at scale.
The Counter-Argument
Dmitry Mayorov showed that technical constraints (theme.json, custom block definitions) can enforce design system compliance mechanically, without requiring organizational buy-in. This is real — but it requires organizational authority to implement those constraints in the first place, which circles back to governance. You need buy-in to deploy the constraints that make buy-in less necessary.
Strategic Implication
Organizations planning design system initiatives should allocate the majority of their planning time not to component architecture, but to stakeholder mapping, adoption sequencing, education programs, and community infrastructure. The technical work is comparatively straightforward. The organizational work is where systems succeed or fail.