Why Every Design System Needs a Steward

Although the role may appear authoritative, its function is stewardship, not control.

A design-system steward:

• Promotes consistent adoption; when teams are moving rapidly or do not have visibility of the resources already in place, they might end up with ad-hoc solutions, but the steward assists them in identifying and making use of the existing components and patterns.

• Incorporates valuable contributions; when a team creates a necessary component or pattern, the steward makes sure that it is assessed, improved, and included in the larger system so that everyone can benefit.

• Meets opposing requirements. Since different teams usually have conflicting needs, the steward arranges productive discussions, guides the teams toward realistic compromises, and makes the final decision when consensus is not possible.

It is tempting to think that teams that are capable and have good intentions will automatically arrive at the correct design choices. Although they usually try, good intentions alone are not enough to ensure consistency when dealing with a complex product.

Not everyone has an overview of the entire system. Those who are responsible for constructing and keeping a design system understand how the system's various components and patterns function throughout the organization. Different teams usually know a great deal about their part of the product. To assess decisions that affect the overall user experience, a dedicated steward is needed to provide a broader perspective.

Small deviations tend to increase rapidly. At one e-commerce company, we had a standard product carousel which was working well—until the product managers started asking for minor changes. One wanted larger product names, another required a different price format, and a third wanted customers to be able to purchase directly from the carousel cards.

As time went on, a single carousel developed into a number of different versions, each having its own way of behaving and its own implementation logic. The engineers found it difficult to keep them all working, and the customers experienced inconsistent interactions—sometimes even on the same page. What had once been a familiar pattern had become a source of cognitive load and visual clutter. The original carousel had broken down into many weaker versions.

Teams focus on achieving local results. The team in charge of the checkout process has objectives that differ from those of the team dealing with product discovery or account settings. Each team will naturally support changes that enhance its own metrics. If no one is responsible for ensuring the overall user experience, the product will end up as a collection of conflicting designs—especially in the case of basic interactions such as search, navigation, and forms.

Designers require support from the organization. If a stakeholder asks for a change that enhances one feature but reduces overall consistency, designers should not be required to justify the system on a personal basis. Instead, well-established principles, combined with active stewardship, should shift the discussion from "I disagree" to "Here is the standard, together with an explanation of why it exists and what would be needed in order to change it."

True stewardship doesn't mean enforcing rules from a distance or opposing all change; it means guiding the system's evolution with consistency, sound judgment, and a clear understanding of the organization's needs.

Get executive backing. The design-system team needs the power to challenge or turn down changes that damage the overall user experience. Without senior-level support, standards will become optional whenever they are inconvenient. Executives should understand that consistency is a product feature and not a barrier to innovation.

Build a strong partnership with the engineering team, since engineers can be some of the most valuable advocates for the design system. If the system is well maintained, it will improve the product while reducing the effort needed to build and support many versions of the same component. This in turn enables both designers and engineers to concentrate on important product challenges rather than having to continually implement small visual changes.

Arrange frequent design reviews since you can't manage work that you can't see. Hold regular meetings with product teams to learn what they are developing and why they need certain changes. These meetings should be collaborative rather than critical: they should provide an opportunity to identify current solutions, discover real gaps, and together improve the system.

Conduct the review at the right time. If the review happens too early, the team won't have enough detail to assess the situation. If it is delayed too long, the team may have already put in a great deal of time and effort. The best time is after the initial design exploration, when the solution is specific enough to evaluate but still flexible enough to change before implementation.

Set up a clear contribution process. Give teams a straightforward and obvious method for suggesting components, asking for changes, or reporting missing patterns. People will fail to use the process if it is confusing or onerous. Easy access to a short submission form, well-documented requirements, reliable decision timelines, and regular office hours can all help to make it easier for people to take part.

You should be both responsive and practical. If you turn down every request, teams will have to work around the system; if you approve every exception, the system will lose value. Effective stewardship requires striking a balance between consistency and legitimate product needs.

A good rule of thumb is that if a change could be of benefit to three or more teams, it should be included in the design system, but if it serves only one particular use case, it might be better treated as an exception. When the right approach isn't clear, test the solution with one team, assess the results, and then decide whether to make it a shared standard.

The idea of taking responsibility for a design system is frequently thought of as amounting to saying no. In fact, its true aim is to enable teams to say yes to the appropriate solutions at the right time—without compromising the coherence of the overall product.

We had the opportunity to work with a design-system team whose components were constantly disregarded in favor of custom solutions. The issue wasn't a shortage of standards; it was rather too much rigidity. The team had developed a system they valued highly and therefore opposed almost any suggestion for change to protect its integrity.

Their concerns were understandable, but they had the wrong priorities. A system that is perfect but which teams cannot use is of little use, while one that is less perfect but which meets the real needs of the product is much more effective.

We implemented faster review cycles, clearer criteria for approving changes, and a more open way to contribute. As teams saw the system could keep up with their needs, trust increased, and adoption rose considerably.

We also encountered the other extreme: a system so loosely controlled that teams could create almost anything, as long as they used the approved colors and typography. This degree of freedom caused fragmentation, since designers kept recreating basic components rather than reusing existing solutions, and the user experience ended up almost as inconsistent and inefficient as if there were no system at all.

The aim is to strike a balance: a good design system must be structured enough to ensure consistency, but flexible enough to meet real requirements. Stewardship keeps the system between those extremes by protecting its integrity while ensuring it stays useful, trusted, and widely adopted.

It takes a great deal of investment to develop design systems, not just in creating them but also in maintaining them, documenting them, and promoting them throughout the organization. Without active stewardship, that investment can slowly be undermined by a multitude of small exceptions, and eventually teams will design and build on their own again.

Stewardship does not mean exercising strict control; it means deciding when to preserve consistency and when the system should change. It enables teams to handle conflicting requirements, offer useful solutions, and make decisions that benefit users, not just internal convenience.

A design system should have its own steward. Once you give that person the authority, tools, and organizational support, the system can deliver its promise: a more coherent product, more efficient teams, and a consistently better user experience.

Dworkz is a UI/UX design and development firm in San Francisco that works with data-driven B2B SaaS companies. If your team is moving fast but your brand still feels inconsistent, let’s work together to make it more cohesive.