A design system can be technically immaculate and organizationally useless. The token architecture is tidy. The components are documented. The library has a release cadence. Yet a product team still rebuilds a button, another invents its own interaction pattern, and a third waits for the central team to approve a decision nobody quite owns. The artefacts are healthy. The working relationship is not.
That gap sits at the centre of Laura Martínez’s thinking. The founder of Patternhaus has spent more than fifteen years in technology, including work on design systems across large product organisations. Her argument is not that components, tokens or documentation are unimportant. It is that they cannot rescue a system that fails to help people work together.
In detailed written responses to DesignWhine, Martínez explores the business case for design systems, why adoption is a misleading measure of success, how governance should distribute decisions rather than hoard them, and what happens when AI begins to enforce the rules an organisation has never properly examined. Her perspective arrives at a useful moment: the 2026 Design Systems Report, surveying 147 practitioners, found adoption and awareness remained the field’s leading challenges for a fifth consecutive year.
A Business Case Nobody Can Screenshot
Design systems are usually introduced to leadership as a story about efficiency. Reuse reduces duplicate effort. Components make interfaces consistent. Tokens make change easier. All true, and all surprisingly easy to confine to the design team’s budget line. Martínez wants the business to recognise the larger consequences, including onboarding, accessibility exposure, collaboration and the cost of repeatedly solving the same problems.
Asked what companies most often misunderstand about the job of a design system, she started by rejecting the idea that its purpose is to make designers’ lives more convenient.
“The most common misconception about Design Systems is that they primarily solve Designer problems.
In reality, their impact is far-reaching, fundamentally transforming several critical areas for organizations. For instance, operationally, Design Systems drive down costs by optimizing software development workflows, accelerating innovation and time-to-market through faster cycles.
They reduce ramp-up time for new hires, who start solving problems fast rather than looking for a Button example across all repositories and libraries. Design Systems also help reduce risk, particularly regarding legal exposure related to accessibility (A11y) compliance. This could result in fines of up to 4% of the organization’s annual revenue in Europe. With several countries in the world having similar legislatures.
Furthermore, and more relevant today than before, they cultivate a positive culture that promotes the cross-disciplinary collaboration necessary for breakthrough tech-forward innovation, which, in turn, has the potential to boost talent retention. It is estimated that replacing a senior tech employee costs 1.5x their salary, accounting for recruiting fees, onboarding, lost business knowledge, and overall productivity.
The ROI of Design Systems is substantial, yet this powerful, business-critical value remains widely unrecognized by many leaders in the tech industry—I want to change that.”
This is more than a pitch for additional resources. It changes the unit of value. The outcome is not how many components were shipped this quarter, but whether product teams make fewer avoidable decisions, can move with less friction and produce better experiences. It is the distinction we explore in why a UI kit is not a design system: a beautiful asset library is only a beginning.
“The most common misconception about Design Systems is that they primarily solve Designer problems.”
Martínez’s broader point is worth keeping separate from the particular financial estimates she references. An organisation should prove its own costs and gains rather than repeat an industry-wide ROI promise as if it were universal. The strongest design system business case is the one tied to an actual product launch, a real support burden or a measurable barrier to delivery.
The Adoption Number Can Lie
There is a seductive dashboard for design systems: percentage of products using the library, components installed, documentation opened. These numbers tell a team whether assets are being touched. They do not always tell it whether those assets help people solve problems. A component can be widely adopted because there is no approved alternative, while everyone quietly works around its limitations.
Martínez points to the moment that discrepancy becomes visible. People start hacking the components they are meant to trust, or cannot explain how the token system is supposed to work. The system looks complete from its makers’ perspective but costly from the perspective of the people expected to use it.
“Adoption is a common metric for Design System success, but enforcement rarely helps achieve it. A system might appear healthy, possessing a standard set of core components and a robust, scalable token system. However, if users frequently resort to hacking components to meet their specific needs, or if they are generally unaware of how to use the tokens, the System is far from healthy. This signals high friction in adoption.
In my experience, a good Design System is adopted organically because the alternatives are less appealing; meaning, it effectively meets user needs. Education, marketing, and great customer service—all of which DS teams are responsible for—are also huge factors.
The earliest way to determine if a System can deliver on its promises is to treat it like any other product, always keeping two things in mind: user needs and business goals.
I frequently encourage Design System practitioners to actively engage with internal customers for input. This means scheduling calls to ask specific questions, conducting User Testing with a scripted task to observe system interaction, and taking detailed notes. Use User Experience Research (UXR) techniques to understand their pain points, enabling informed decision-making on how to address them.
I also advise them to get nosy and proactive about significant goals discussed in leadership meetings, and to identify how the System can accelerate their delivery. For example, tackling a rebrand, a new checkout flow, or a product launch. By quickly building a prototype using the System, they can effectively showcase its impact.”
The revealing part of her answer is not a call for better policing. It is her insistence on user research and product thinking inside the design system team. Speak to the designers and engineers doing the work. Observe the task, not only the usage logs. Find out why the workaround exists. Show how the system can accelerate a live business initiative instead of asking everyone to admire the component catalogue.
The survey evidence fits that diagnosis. In zeroheight’s 2026 findings, only 7% of respondents reported their system was fully adopted across all teams, while 38% described moderate adoption and 22% minimal adoption. Those figures are self-reported, not a universal census, but they expose the distance between having infrastructure and getting sustained value from it.
Governance Should Free People, Not Police Them
When a design system reaches scale, the obvious response to inconsistency is more rules. A contribution model is written, a board is appointed, and exceptions are routed to an increasingly busy group of maintainers. The organisation calls this governance. Product teams often experience it as another queue.
Martínez is unusually candid about her own earlier preference for perfecting the tooling. At scale, she argues, governance matters most, but not as an elaborate permission structure. The better model is shared decision-making: clear principles that let people resolve routine friction themselves, with agreed boundaries for the decisions that genuinely need escalation.
“Like many Design System practitioners, I’ve been guilty of focusing too much on the tooling, getting the libraries, repositories, and documents just right. While a favorable team mindset is often achieved if the System addresses their pain points (and a little marketing helps!), Governance becomes absolutely vital at scale, even if its necessity isn’t obvious right away. The sooner you tackle this, the better.
In tech, Governance usually means policies, practices, standards, and guardrails. For Design Systems, this often gets simplified down to one artifact: the Contribution Model. However, I prefer to think of Governance as a set of clear decision-making frameworks. These frameworks empower users to resolve their own friction points with the System while operating within defined boundaries. Boundaries set not to limit creativity, but to ensure safety and alignment. Think of them as operating and service principles.
These principles don’t just unblock System users; they also make the System’s health less dependent on the core builders. Their backlog won’t be constantly bloated with feature or bug requests. They won’t have dozens of service tickets to attend to, freeing them up to dedicate time to evolving the DS.
By putting these principles into action (and reviewing them regularly), both the builders and users of the Design System can respond more quickly to business needs and scale up in a much less painful way.”
“Governance becomes absolutely vital at scale, even if its necessity isn’t obvious right away.”
This is the paradox of mature design system governance. The most effective rules may be the ones that reduce how often a team must ask the central maintainers for permission. They make judgement distributable. Instead of turning every unusual product requirement into a ticket, they help engineers and designers understand when to reuse, when to extend and when to challenge the system.
It also explains why familiar design system failure modes cannot be corrected merely by rebuilding the library. An organisation that does not agree on ownership, exceptions or decision rights will reproduce the same confusion in whatever tool it adopts next.
AI Makes the Rules Harder to Ignore
AI introduces an uncomfortable twist. A human designer working around a vague component guideline might create one inconsistent screen. An agent operating within a flawed system can generate dozens of them before anyone has identified the common mistake. Faster production can turn unresolved governance into an automated production line.
Martínez sees design systems becoming more important, not less, as AI moves into design and development. Models need business context, reusable patterns, guardrails and an understanding of whose needs the interface is intended to serve. A design system that contains only presentational assets offers a poor account of why those assets exist.
“Design Systems, fundamentally, exist to boost the efficiency of product development cycles. A robust DS is essential for improving the output quality in AI-driven workflows by embedding the necessary business and end-customer context for LLMs. This shifts Design Systems from optional projects to critical infrastructure within technology organizations.
A significant challenge is the creation of guardrails to keep human interests central to digital interaction. Design Systems must define and evolve UI patterns that remain highly usable for humans, while also consciously catering to AI as a new type of ‘user.’
Ultimately, Design Systems should act as the interpreter, translating complex intelligent capabilities into digital experiences that meet fundamental human needs. The goal is to craft interactions that are intuitive and trustworthy, ensuring technology empowers the user rather than controls them.”
The practical challenge is already visible in the work of making a design system AI-ready. Machines may read tokens and components, but cannot reliably infer an organisation’s unwritten priorities or a user’s needs from a visual library alone. Rules must be explicit, current and connected to production.
As design agents begin changing systems themselves, governance becomes more than a question of what components an assistant is allowed to use. It becomes a question of who can author the constraints the assistant is asked to obey, who checks the output and how a team can correct a bad rule before it propagates.
Human Judgment Must Remain in the System
There is a temptation to describe the future of generative interfaces as a victory for individualisation. Every user gets a different view, assembled in the moment by software that apparently understands their needs. But if every screen can be generated, which decisions should remain fixed? How much variation is acceptable? Who gets to decide what a trustworthy interaction means?
Martínez’s final answer moves beyond velocity to the human purpose of the system. AI may help designers and developers work faster, but that makes the quality of their underlying standards more consequential. Someone must still define the boundaries within which an automated interface can behave.
“Design Systems are poised to be critical in balancing the adoption of AI within digital delivery. They offer the technical foundation for using AI to boost efficiency, inherently amplifying the rules and practices they contain (similar to how they currently help improve accessibility).
It is critical that DS teams establish guardrails to ensure that amplified information is correct and that the resulting digital interactions remain human-centered. Simultaneously, DS teams must explore how they can leverage AI to improve their own efficiency and better serve internal users with accelerated workflows.
We are getting closer to Generative UI each day. The promise is that AI will be able to create highly personalized digital experiences on the fly. In this future, a Design System’s role will be to set human-determined (or at least human-reviewed) guardrails. These guardrails will ensure that, despite the high level of personalization, the resulting experiences remain human-centric and can adapt as necessary.”
“a Design System’s role will be to set human-determined (or at least human-reviewed) guardrails.”
The important phrase here is human-determined. A generative interface cannot replace the responsibility to decide what should remain understandable, accessible, coherent and safe. Nor does a fully documented component catalogue guarantee those qualities. They are choices that teams have to make, test and revisit together.
Martínez has made a related case in her writing about design systems as products for people. The point is not to reject automation. It is to remember that the system exists to support human collaboration, while AI can only be as useful as the intentions, constraints and feedback loops the organisation makes legible to it.
The Real Product Is Shared Judgment
Design systems are often sold as a way of removing decisions. Build a component once, distribute it, stop debating the button. There is real value in that ambition. But the harder work is deciding which questions can be standardised and which ones require someone to think.
Martínez’s answers suggest a more demanding test of maturity: can teams act independently without drifting apart? Can the people using the system explain its choices, challenge them and adapt them to a genuine need? Can AI speed up delivery without turning an old organisational misunderstanding into hundreds of polished mistakes?
A mature design system does not make judgment disappear. It makes judgment shareable. The component library is the visible artefact. The real infrastructure is the agreement between people about how to make a good decision, even when the people who wrote the original rules are no longer in the room.
Has your team ever had a well-documented design system that people still worked around? Was the real issue the components, governance, or a lack of trust?