Your core design system value is for your business to decide

Consistency

The one thing that sets apart design systems from UI kits is their systemic documentation. "If this, then that" is a core principle.

This is done with consistency in mind: systems are great at making things look and work the same, even in distributed teams. So design systems come with recipes, rules and governance to keep things aligned.

This is a key aspect of design system mentality. Design systems are restrictive but they take some freedom away because that's the cost of consistency: the more choices there are, the more likely inconsistencies will appear.

Time-to-market

But systems are also built for speed, in a specific way. They're organised around libraries of trusty components, ready to be assembled to build new screens at minimal cost. Yes, it comes with maintenance overhead. But compared with a blank slate every time a new UI needs to ship, building with the pre-made components accelerates time-to-market.

They do not make everything faster and this is crucial. Building for the design system is slower than building outside of it. Because it is the source of trusted, fool-proof components, it requires absolutely spotless implementation.

Critical infrastructure is not a place for rushed solutions and quick hacks. Infrastructure should be stable, durable, and well engineered. A design system establishes this reliability in its approach to experience, in the craft of its design and development, in the standards it always observes, and even in the practice and rituals followed by the team that builds it.

Josh Clark @ Big Medium

Building in the system is slower, but building with the system is faster, more stable and durable.

Scalability

One other core strength of systems are their ability to scale. They centralise UI patterns to one source of truth. Updating your branding? Change your design tokens' values. Updating the visual style of your forms? Change your design system-mandated inputs. Updating the system propagates the changes everywhere.

That scalability relies on two key points. Adoption of course: none of the system's powerful scaling ability matters if it's only partially used or heavily overridden. Architecture is the other: a well thought-out architecture will allow for changes to be made in one place, and propagate everywhere. A poor architecture will require changes to be made in many places, increasing the risk of inconsistencies.

This value also shines when it comes to accessibility. If your system scales, then accessibility scales with it. Think of colour contrasts getting fixed all at once, or focus states being added to all interactive elements in one go.

Doing it all at once

To some extent, a healthy design system will try to achieve all three (and probably more) of those principles. But they can also be at odds with each other.

Consistency can slow things down: you will try to maintain it by finding out ways to limit options, rationalising everything, documenting every single edge case. This takes time, which is a rare resource. A quick time-to-market on a new component is, in turn, likely to cause inconsistencies, with rushed implementations, lack of documentation, and a tendency to cut corners.

How do we handle that? What matters the most then?

Business rules the design system

What matters the most to the system is what matters the most to the business. The moneeeeey. It will often be time-to-market, because product needs to move fast and you do not want to be in its way. But it will also be scalability, because easily making widespread changes matters enormously at critical times. And it will be consistency because it's a demonstrable criteria of quality in any product.

But it rarely will be all of these at the same time and at the same level. For every design system task, sort out the hierarchy for those needs. Let business define the core value of the moment, and act accordingly.

The key is building your architecture with that in mind. Time-to-market is the top priority for a new component but it still raises a lot of questions? Let buffer or satellite libraries handle it, keeping your core system clean. You've planned layers:

Establish a layered UI ecosystem – A successful UI ecosystem is like a delicious layer cake, with the design system as the base, individual apps at the top, and a few potential (optional) layers in between. With a layered ecosystem in place, the design system isn't the arbiter of all UI so crap can live at another layer in the stack.

Don't put crap in the design system - Brad Frost

What if consistency is critical because you're setting up a transversal experience across multiple features? Time for your semantic tokens to shine, your governance process to kick-in, your documentation to come out. Scalability is paramount now you are legally obligated to be accessible? Perfect! Your components follow an atomic pattern that lets you handle any product-wide update from a few core elements.

The design system that survives is the one that adapts, and that means being flexible with its own values. Yes it will sometimes hurt to see a component go to a satellite library because there's no time to do it well. Yes it will sting to implement one more exception to a component that already has more options than your local pizzeria-burgers-and-oyster-bar restaurant. But a concession isn't crap. A concession can be "the job", it can be the difference between building what the team needs to be able to rely on, or what the team stops trusting because it can't provide what they need to do their business.

In short: your core value as a maintainer is your adaptability to business needs. The system's core value is what the business needs it to be.