Design & UX

Design Systems Are Products Now. Treat Yours Like One.

Salesforce publishes Lightning. IBM publishes Carbon. Shopify publishes Polaris. Google’s Material has been public long enough to have version history worth studying, and the roster of organizations maintaining public, versioned, staffed design systems now reads like a market index. A design system without an owner is a screenshot. It looks like the real thing right up until someone needs it to work.

When we championed the pattern-library idea in 2013, the argument was speed and consistency for a single site’s components. What has happened since is a graduation we want to mark formally, because the vocabulary shift carries the entire lesson. The industry stopped saying ‘pattern library,’ an artifact, and started saying ‘design system,’ an operation.

The public examples now make both the thriving pattern and the failure modes readable secondhand, which is the cheapest way to learn anything. For the multi-site institutions we serve, the graduation is not industry news to admire. The universities with two hundred sites. The health systems with service-line sprawl. The enterprises with brand portfolios. It is the answer to the redesign math that dominates their decade. So: the operating lessons, the layer that pays first, and the business case, in that order.

The operating lessons from systems that thrive

Study the public systems and their write-ups and the pattern separates cleanly from its failure modes.

The thriving systems are products. They have owners, roadmaps, versions, and users. Someone is accountable for the system as their actual job, not a side duty rotating among busy designers. It ships releases with change logs. It treats the teams that build with it as customers whose adoption must be earned.

The failure mode has a shape every reader has seen. The style-guide project, delivered as a PDF or a static site in the redesign’s final sprint. Current for one quarter. Then drifting into the special kind of falsehood that documentation becomes when nobody owns it.

The one-time style guide PDF is where consistency goes to die, and it dies of the same cause every unowned artifact dies of. Governance was scoped as a deliverable instead of an operation. The exact argument we have made about editorial calendars, and about security inventories.

Second lesson, subtler. Adoption is earned, not mandated. The systems teams actually use are the ones that make the right thing the easy thing. Components that work. Documentation that answers real questions. Tooling integrated into the workflow. The mandated systems get worked around, and the workarounds become the new inconsistency.

Third: the workflow spine matters, and it has matured. Figma’s shared libraries and Storybook’s living component docs have turned upkeep from a heroic manual practice into a plausible operating one. That is probably the biggest reason the practice crossed from aspiration to standard use in the last two years.

The token layer, which pays first and everywhere

If the full system-as-product operation is more than your organization can staff this year, the investment with the steepest return curve is the foundation layer. Design tokens. The practice of expressing every foundational decision as named, versioned values that code and design tools consume from one source. Colors, type scale, spacing units. Radii and elevation.

The token layer is where consistency actually lives. Most visual drift across a site is unmanaged values. The eleven grays. The nine blues. The spacing picked per project.

And it delivers outsized returns even in modest form, because it converts brand governance from review-and-correct, a person catching drift after it ships, into supply. The values teams reach for are the right ones, because they are the only ones on the shelf.

For the multi-site organizations, tokens are also the practical answer to the brand-refresh problem that otherwise costs a coordinated season. Values updated at the source flow to every consuming property on their next build. Readers of our CMS coverage will recognize the argument. It is structured content’s argument, and Core Components’ argument from last year’s enterprise coverage, at a different layer. Decisions made once, named, and shared beat decisions remade per project. Always.

The business case, in redesign math

  • The per-property math. A governed system turns each new site from a from-scratch design project into an assembly problem. The school site, the department site, the campaign property built from the same components at a fraction of bespoke cost and timeline. Accessibility and performance budgets inherited rather than re-fought, per the WCAG-at-the-template-layer rule we set.

  • The maintenance arithmetic. Fixes and improvements propagate. The accessibility fix, the performance tune-up, the brand adjustment shipped once to the component reaches every property. That site-scale return is what makes the stewardship staffing pay for itself, against the alternative of two hundred sites fixed two hundred times.

  • The proposal-scope implication, disclosed. Our own proposals now scope the system and its stewardship alongside the launch. The ownership, the cadence, the contribution model. Shipping components without an operating model is shipping the failure mode. Clients should hold every agency to the same scope, ours included.

  • The decision framing for 2018 budgets. The question is no longer whether to invest in a system. It is whether your organization can afford to keep re-deciding every design question on every project, forever. Priced honestly, across a site, it cannot. The sites that internalize this first bank the compounding.

How the 2013 argument grew up

A last note for continuity, because this post graduates a five-year-old argument. The 2013 piece made the case in a single site’s terms. Build the components once, use them everywhere, and pocket the consistency.

What five years added is the organizational half the industry had to learn by doing. Components without ownership drift. Libraries without users decay. The difference between a system and a document is that a system is alive, which means staffed.

The public exemplars proved it at scale. The tooling made it operable at institutional budgets. And the redesign math makes it urgent for exactly the multi-site organizations we serve.

The pattern library grew up into a product discipline, which is our favorite genre of maturation. The good idea, surviving contact with organizations, by becoming an operation. Fund the owner. Version the tokens. Earn the adoption. Let the two-hundredth site cost what the twentieth should have.

The compounding has already started at the institutions that moved. The style-guide PDFs, meanwhile, are exactly as current as the day they were exported, which is the epitaph the category earned.