How design systems reflect your organization
Despite the rise of design system discourse in the last few years, evidence suggests that only a minority of organizations have adopted a design system in a way that endures. Surveys of practitioners and organizations show that adoption, contribution, and maintenance remain among the top challenges reported by teams working with design systems, and that many systems, once launched, struggle with inconsistent usage and fragmented governance over time. Even among companies that claim to have a system, coverage and active use across products can be difficult to measure.
In my daily work with startups and scaleups, I see the same pattern repeat itself with remarkable consistency. Teams invest early in ideas, in features, in speed. They debate frameworks, hire strong engineers, refine product-market fit. But when the conversation turns to structure, to architecture, to shared systems of building, there is hesitation. Design systems are postponed. Deferred. Framed as something to “add later,” once the company is bigger, calmer, more certain of itself.
This deferral is rarely framed as a decision. It is presented as pragmatism, as focus, as speed. But the absence of a design system is also a decision. And like most decisions made implicitly, it carries consequences that surface much later, when they are harder and more expensive to address.
The justification is familiar: a design system is “just” a set of building blocks. Components. Variables. Tokens. Something a team can assemble quickly once the need becomes obvious.
Yet this framing misunderstands what design systems are, and what they do.
A design system is not unlike architecture, or a game built from blocks. The blocks matter, but they are never the whole story. What gives them meaning is the instruction, the agreement, the shared understanding of how they can and cannot be used. The rules of the game. The logic of the structure. The people who play and build within it. Without those agreements, blocks accumulate, but coherence does not.
I began asking myself why so many teams seem uneasy about design systems at the very moment when they would be most useful: when the first lines of code are written, when the first frontend flows take shape, when habits are still forming. Do founders and teams truly believe design systems are trivial? Or do they sense, perhaps correctly, that the subject is more complex than it appears, and prefer not to open it yet? From experience, I suspect it is the latter.
Design systems touch architecture. Not just frontend architecture, but organizational architecture. They surface questions about ownership, decision-making, responsibility, and long-term intent. They are not neutral. And because of that, they are often postponed.
But postponement does not remove the work; it converts it into debt. Not only design debt, and not only technical debt, but something more diffuse: process debt, knowledge debt, and eventually human cost. If a product scales, this debt will be repaid. The only variable is price. Which brings us back to the beginning of the story: before tools, before frameworks, before maturity models. Back to the question we rarely slow down to ask.
What do we actually mean when we say “design system”?
On Defining Design Systems
The confusion around design systems begins, quite simply, with definition. Or rather, with the abundance of definitions that each describe a fragment of the phenomenon, while leaving its center of gravity unexamined.
Alla Kholmatova, whose work has shaped the field, defines a design system as a collection of reusable components, guided by clear standards, that can be assembled together to build any number of applications. It is a precise and practical definition. It gives us reuse, standards, and scalability. What it leaves implicit is the social infrastructure required to create, maintain and scale those standards.
Nathan Curtis sharpens the lens when he describes a design system as a product serving products. In that framing, a design system is no longer documentation, it has users, stakeholders, and a lifecycle. Maintenance and evolution become unavoidable topics. Still, the organizational conditions that allow such a product to exist remain mostly assumed.
Enterprise systems such as Salesforce Lightning or IBM Carbon emphasize scale, efficiency, and speed. Their definitions reflect environments where fragmentation is costly and consistency is a necessity. Brad Frost’s Atomic Design, perhaps the most enduring metaphor, frames design systems as connective tissue, atoms and molecules that allow complex products to exist without collapsing under their own weight.
These definitions are not wrong. They are incomplete.
They focus on artifacts, sometimes on process, occasionally on scale. What they rarely address directly is the fact that design systems are social systems before they are technical ones.
More recent maturity models attempt to capture this complexity. Vitaly Friedman’s layered approach, moving from UI kits, to libraries, to design systems, to scaled and public systems, is one of the most ambitious attempts to map the terrain. It rightly includes governance, analytics, automation, and influence.
But embedded in this ladder is an assumption that deserves scrutiny: that a “real” design system begins only once an organization is large enough to afford it.
Startups and scaleups, by this logic, are implicitly excluded from system thinking until they have accumulated enough complexity to justify it. Structure becomes a reward for survival, rather than one of the conditions that make survival possible.
What is missing here is intentionality.
Versioning does not require scale. Documenting decisions does not require a dedicated team. Shared vocabulary does not require a public roadmap. What it requires is a decision to treat structure as part of the product, not as an afterthought.
This is where I find Brad Frost’s metaphor most instructive. Connective tissue does not appear at the end of growth. It enables growth in the first place. From that perspective, a design system is not a level to be reached, but an environment to be cultivated.
At its most basic, it can be described formally, almost mathematically: a set that includes components, variables, and design tokens along with rules for their use. Add to this tone of voice and the contexts that shape it: platform, audience, accessibility needs, industry constraints. Add processes for how these elements are combined to create software. And finally, add the people who design, build, review, and maintain them. What emerges is not a library, it is an ecosystem.
A design system is a shared agreement about how an organization builds. It is a social contract, informed by good practices that are partly universal, partly contextual. It acknowledges that different platforms, audiences, and industries require variation, but insists that variation be intentional, documented, and understood.
Seen this way, design systems do not merely organize interfaces; they organize work. They do not only standardize visuals, they standardize decisions. And they do not exist to make products look consistent so much as to make organizations function coherently over time.
This realization did not come from theory alone. It came from observing how teams operate, what breaks, what gets postponed, and what eventually demands attention. Again and again, the same gap appeared, not in tools, but in definitions. In the absence of a shared understanding of what a design system actually is and why it exists.
So we went back to the beginning. To definition and standardization. To the possibility that if we could agree on what a design system truly encompasses, and automate the processes of implementing, using, maintaining, and scaling it, we could remove much of the friction that currently makes systems feel optional, intimidating, or “too much, too soon.”
Tidying the beginning of the story, it turns out, is not a philosophical exercise. It is a practical one. And it is where the real work begins.
A Simple Test: What Your Design System Reveals
When people ask how mature an organization is, the conversation usually turns to scale. Headcount. Funding rounds. Tooling stacks. These indicators are easy to name and easy to compare. They are also incomplete.
What tends to be overlooked is how the work actually happens. How software is delivered. How decisions move through the organization. Whether processes are designed or improvised. How much friction teams carry, and how much debt, technical, design, and procedural, accumulates along the way. A more reliable signal sits closer to the work itself.
If you want to understand the maturity of an organization, observe how its (design) system behaves when something changes. When requirements shift. When a frontend framework is replaced. When a new person joins the team. When a company is acquired and software must be integrated into a different ecosystem.
Change offers a particularly revealing lens. In resilient systems, change is ordinary. New requirements arrive and are absorbed with minimal disturbance, because the system was built with movement in mind. Boundaries are clear enough to allow flexibility without chaos. In more fragile systems, even small adjustments feel dangerous. A single modification ripples outward, breaking assumptions and creating unintended side effects. Change becomes an event to endure rather than a condition to expect. This is not a failure of effort. It is a consequence of structure.
Pressure makes these differences even harder to ignore. When time runs short or resources tighten, something always gives way. Documentation is skipped. Accessibility is deferred. Consistency is sacrificed. Or people absorb the cost themselves, working longer, carrying more, compensating for what the system does not provide. These breakdowns are rarely accidental. Systems fail along the lines they were never designed to protect.
Design systems are useful precisely because they do not explain or justify. They record. What looks like a technical artifact is, in practice, a ledger of decisions, what was prioritized, what was postponed, and what assumptions were made about the future.
There is no scoring mechanism hidden in these observations. No maturity level to unlock. The value of this reflection lies elsewhere. What emerges is not a judgment of individuals, but a portrait of the environment they work within. The system, not the person, sets the terms of what is possible.
Design systems do not create organizational culture. They make it visible. And visibility matters. Because once patterns are seen clearly, they can be questioned. And once they are questioned, they can, if an organization chooses, be redesigned. That choice is where systems begin to change.
Learning to Think Systemically
Design systems rarely fail because teams lack competence. More often, they fail because they are approached from the wrong direction.
In many organizations, systems begin with visible artifacts. Components are designed, tokens are named, libraries are assembled. Structure is expected to emerge later, once the pieces are in place. When it does not, the system becomes brittle. What looked like progress turns out to be accumulation.
This sequence is understandable. Components are concrete. Structure is abstract. One can be drawn, the other must be agreed upon. But reversing the order is what makes the difference between a collection and a system.
Before any component exists, a series of questions already shapes its future. Who is allowed to decide when something changes? Under what conditions can a new element be introduced? Who carries responsibility for maintenance when attention shifts elsewhere? How does the system adapt without destabilizing the work built on top of it?
Organizations that address these questions early do not eliminate disagreement, they eliminate confusion. Decisions may still be contested, but the path through which they are made is stable. Without this foundation, even the most refined UI kit becomes a liability. It promises coherence while quietly producing fragmentation.
Time provides a second, equally unforgiving lens. Many design systems perform well at launch. Fewer survive their first migration. Longevity is not a matter of aesthetic restraint or technical sophistication. It is a measure of whether a system was designed to change. Rewrites happen. Frameworks fall out of favor. Teams dissolve and re-form. Leadership shifts. These are not edge cases, they are the conditions under which software exists.
A system that cannot endure these transitions without excessive cost is not infrastructure, it’s decoration. Longevity, in this sense, does not emerge from perfection. It emerges from adaptability that has been designed deliberately rather than improvised under pressure. This is why treating a design system as a project is so often disappointing. Projects end. Systems do not.
A design system that matters is not something a team completes and moves past. It is a practice, maintained through routines, conversations, and small acts of care. It exists for the product, but also for the people who build it, and for those who will inherit it later, when the original context has been forgotten. Seen this way, the value of a design system is not that it reduces complexity. It is that it makes complexity survivable.
A Practical Way Forward
Implementing a design system does not require a pause in delivery, nor does it demand an act of organizational heroism. What it requires is sequencing work intentionally rather than reactively.
The process begins with naming reality. Not the system an organization hopes it has, but the one it actually lives inside. What exists today, across design files, codebases, documentation, and habits, is the starting point, whether it is acknowledged or not.
From there, purpose must be clarified. Not in the abstract, and not for some distant future, but in relation to the present moment. What problem is the system meant to solve now? Speed, consistency, resilience, each implies a different structure. A system without a clear purpose quickly becomes ceremonial.
Ownership follows. Ambiguity at this stage is costly. When responsibility is diffuse, maintenance becomes optional, and optional work is the first to disappear under pressure. Clear ownership does not guarantee success, but its absence almost guarantees decay.
Growth, when it comes, should be structural rather than ornamental. A small number of well-maintained primitives outperforms a large, brittle library. Expansion without care multiplies surface area without increasing stability.
Equally important is the documentation of decisions and versioning. Components age quickly. Context lasts longer. Knowing why something was built a certain way allows future teams to change it without undoing the logic that held it together.
Finally, the system must assume change as a constant. Migration, scaling, and turnover are not interruptions to normal work. They are normal work. Designing for them early is not pessimism, it is realism.
Tooling and automation have a role to play here. They can reduce friction, enforce consistency, and remove manual effort. But they cannot substitute for structure. Tools should serve the system, not define it.
This belief, shaped through years of working with teams navigating these challenges, is what led us to build PayForDone, not as another design system tool, but as infrastructure aimed at making systems the default rather than the exception.
The Quiet Advantage
Design systems are often justified in the language of efficiency or consistency. These benefits are real, but they are not the most important ones.
The deeper advantage is coherence. Teams that invest early in structure do not become slower. They become calmer. Decisions require less negotiation. Changes carry less risk. Knowledge travels further and lasts longer.
Calm, in this sense, is not the absence of urgency, it is the presence of stability. And stability allows teams to make better decisions, over longer periods, under greater pressure, with less noise.
Good teams build products. Great teams build the systems that allow products, and the people behind them, to endure.
References:
“Design Systems” by Alla Kholmatova
“Atomic Design” by Brad Frost
“Design Systems Are About Relationships” by Nathan Curtis (EightShapes Essays)
Salesforce Lightning Design System
IBM Carbon Design System
“Maturing Design Systems”, Smashing Magazine
2021 Design Systems Survey, Sparkbox
Design Systems Adoption & Governance Insights, Design Systems Collective
“Understanding and Supporting the Design Systems Practice” (2022), Yassine Lamine & Jinghui Cheng, arXiv
DORA 2025: State of AI-Assisted Software Development, Google Cloud (DevOps Research & Assessment)
GitLab Global DevSecOps Report 2024, GitLab
“Design System Adoption Metrics Over the Past 5 Years”, UX Collective
https://www.linkedin.com/posts/vitalyfriedman_ux-designsystems-activity-7400812813994180608-Nqnq?utm_source=share&utm_medium=member_desktop&rcm=ACoAABwuQuQB_1iLcAFW7qedLAqkhbZdADD8wls
