Democracy and fiber cable - exploring design system maturity through analogy
In my early days at Knapsack (aka a few weeks ago) I would ask Robin "What's a Design System?" as kind of a joke.
Over time, it's become clear that there's no clear answer to this question. Robin's writing often focuses on the challenges and approaches a design system takes to problem solving - not splitting hairs about what a DS actually is.
In this Dan Mall video, the challenge of definition is illustrated: a dozen definitions and six types are offered to attempt to describe design systems. This includes definitions like:
"Any set of decisions governed across an organization" Hayley Hughes, Trust Between Teams
and
The official story of how your organization designs and builds digital interfaces. Brad Frost, Design systems are for user interfaces
https://www.youtube.com/watch?v=hMSSg-pA9lk
Is "Design System" poor branding?
A "design system" is a bad label for a critical capability for any organization that delivers digital product. I've heard it said a design system is "horrible branding". Why is that?
I think it's because most people think of 'visual design' when they hear the word design. A job that makes things look a certain way. But design systems have everything to do with encapsulating decisions, and those decisions are far reaching:
- how does design intent reach a particular medium?
- how do we communicate what's available to a user in an accessible way?
- how does the brand get expressed without harming the usability?
- when a new medium or use-case arises (ahem, A.I.) how do we discover, ratify and distribute new patterns to all those who need it?
It's impossible to encapsulate all that meaning in a label. So, reaching for illustrations can help us.
Maturity as a lens
Recently a rallying point has been circulating across LinkedIn. A maturity model of Design Systems.
Maturity model by Vitaly Friedman. One way to discuss a complex system is through illustrating how it shifts in different phases over time.
Like we discuss a caterpillar vs butterfly, or a village, town or city – maturity is a lens we can use to discuss design systems in a way that better describes the state of the design system.
By using a maturity lens, we can highlight and navigate the evolution, problems and solutions that define a design system in context. And reframe the challenges of establishing and growing a design system through the needs of the organization.
Maturity Modeling
Maturity models have existed for decades. They are a way of explaining the evolution of a service's quality and efficiency. Some well known models are the Capability Maturity Model Integration (CMMI) which has been used for years by govt, service and consulting industries to model process maturity within organizations.
Some examples:
- DevOps Maturity Model - Assessment, Transformation and Benefits
- The Continuous Delivery Maturity Model
- Bruce Tuckman's Ladder of Team formation: Forming, Storming, Norming, Performing, (and later) Adjourning
- Wardley Map model of Market Evolution: Genesis, Custom, Product (+Rental), Commodity (+Utility)
| DS Maturity | CMMI - Process maturity (DevOps, CI/CD, etc) | Tuckman's Ladder of Team Formation | Common Challenge across Frameworks |
|---|---|---|---|
| L1 - UI-Kit | Ad-hoc - manual work by individuals or teams | Forming - a need is identified and goal takes shape | Recognition of need |
| L2 - Design Library | Repeatable - process can be repeated (sometimes called "managed") | Storming - conflicts arise and boundaries are tested | Agreement on goal |
| L3 - Design System | Defined - process is understood and has shared language | Norming - collaboration grows and members define roles | Alignment on initial solution/approach |
| L4 - Scaled DS | Managed - process can and is measured (sometimes called "measured") | Performing - roles defined, the team operates at peak | Executing the solution in practice |
| L5 - Public DS / Intelligent Delivery | Optimized - process is consistently improved | Adjourning - the work completed, the team dissolves (sometimes: "mourning") | "Automation" of solution delivery - a system that codifies what once were individual efforts |
Just like light is both a particle and a wave, a design system can be better understood by considering it from different perspectives.
Below I describe two different but useful analogies for design system maturity.
- Democracy - using American history as a lens to highlight the trials of expanding an idea to a form of governance
- Pipeline - using public infrastructure as a lens for the challenges for moving value from a source to a destination
DS Maturity as Democracy (Governance & Innovation)
| DS Maturity | Democracy Model | Historical Example | Governance Challenge | Governance Benefit |
|---|---|---|---|---|
| L1 - UI Kit | Revolution | 1765-1776: Colonists recognize British rule is intolerable, declare independence | Legitimacy: "Are we allowed to do this?" | Independence declared - breaking from the past methods. Small team dreams of new reality. |
| L2 - Design Library | Constitutional Convention | 1787: Founding fathers draft the Constitution in Philadelphia | Coherence: "Can we settle on shared, repeatable ideals?" | Constitution written, foundational concepts exist with a shared language. Definitions are discussed and aligned. |
| L3 - Design System | Ratification & Enforcement | 1787-1865: Constitution ratified, but Juneteenth shows 2.5yr delay from Emancipation Proclamation (1863) to Texas freedom (1865) | Adoption: "We've built it, how do we all use it?" Recognition of rule is tested (Civil War) | The rules are set. Union formed, but implementation gaps reveal adoption ≠ publication. Civil war tests system, but system survives. |
| L4 - Scaled DS | State "Laboratories" | 1990s-2020s: States pioneer policies (same-sex marriage, marijuana legalization, healthcare models), successful experiments spread | Decentralization: "50 experiments running—how do we adapt to realities without top-down control?" Localized requirements stretch centralized models to breaking points. Independent paths need to be reconciled. | Distributed Innovation - states experiment, best practices emerge through demonstration in context. Contributions improve entire system. Autonomous distributed governance allow scale innovation. |
| L5 - Public DS / Intelligent Delivery | Platform-Enabled Delivery | 2008-present: App Store, GitHub, Steam - small teams/contributors publish globally through automated validation, contextual rule adaptation (regional compliance, market-specific rules), bad actor detection at scale | Acceleration: "Can we build systems that validate automatically? How do we adapt rules per context? How do we catch violations at CI/CD speed?" Capability is global, scale ramps up, output must be localized. | Leveraged autonomy - small units operate with organizational-scale infrastructure, automated validation catches bad actors, contextual rules enable global reach with local compliance/restrictions |
Through this lens we see a design system through the method of how it's governed and made available to others. As you progress, the audience changes and your ability to respond to demand changes with it. I looked for examples of government that handled policy and scale faster than the 'State Laboratories' and had to fall to app stores as the final model. Where publishing happens at such a scale that there's not really time for debate.
DS Maturity as Pipeline (Curation & Delivery)
| DS Maturity | Pipeline Model | Infrastructure Example | Delivery Challenge | Delivery Benefit |
|---|---|---|---|---|
| L1 - UI Kit | Hand-to-hand | Town Crier, town well | Accessibility: "Where do I find the parts I need?" | Information spreads - the story gets out, though consistency isn't guaranteed past a certain point. |
| L2 - Design Library | Printing Press | aqueducts, printed pamphlets | Consistency: "Can we deliver the same thing every time?" | Guaranteed output - turn on tap, get water; call component, get same result |
| L3 - Design System | Standardized Delivery | Radio & Broadcast TV (ABC, NBC, CBS), basic cable, public utilities - everyone gets same experience | Adoption: "We built universal access, but are teams plugging in?" | Universal access - plug in anywhere in the system, it just works. Same experience for all (for better or worse). One centralized decision body. |
| L4 - Scaled DS | Bundled Packages | Cable packages (Basic, Premium, Sports), Cloud tiers (Free/Pro/Enterprise), Product lines (iPhone SE vs Pro) - same infrastructure, curated variants | Configuration: "How do we manage multiple packages/versions without breaking the core?" "How can regional constraints improve core product?" | Choice and Adaptation - teams select packages that fit their needs, all validated and supported by core infrastructure and expert decision councils that pre-package solutions. |
| L5 - Public DS / Intelligent Delivery | Contextual / Algorithmic Delivery | Streaming platforms (Netflix picks for you), REST APIs (same endpoint, dynamic payloads), Smart Grid (electricity adapts to demand) - infinite variants from same source | Personalization at scale: "Can we deliver the RIGHT thing to the RIGHT place automatically based on context?" | Feels bespoke, works at scale - system understands context (brand, region, platform, accessibility, device) and delivers appropriately without manual configuration |
In this model, we view the evolution through the lens of curation & delivery. With success and standardization, what goes through the pipeline becomes more and more bespoke to the consumer need.
In conclusion
Thinking about how a system works, is always a way to better understand the system. Where labels fail, try stacking models and seeing where things hold, or break.