Evolving a design system without blocking products

When multiple product teams each build a variation of a similar UI pattern, we gain clear evidence to act: promote that recurring pattern into a shared primitive like EmptyState. That is how our design systems evolve healthily.

The challenge is what happens next. One team may be in the middle of a critical release, another is heads-down on new roadmap work, and a third has no plans to touch that surface this quarter. The new primitive still needs to land cleanly without demanding that every team stop what they are doing to migrate.

As CSS architecture established, recurring patterns belong in shared infrastructure. But our delivery rule is simple: introduce the new primitive, and leave running screens alone.

Why backward compatibility matters

A new primitive is an addition. Existing markup and older patterns should continue to work, leaving current views untouched.

We should ship new primitives in minor releases that preserve backward compatibility. Breaking changes can wait as rare exceptions—reserved for security vulnerabilities, critical accessibility failures, or tokens whose semantic meaning cannot be maintained. We may want a cleaner API or more elegant prop names, but aesthetic polish alone doesn’t justify breaking product builds.

Let products pull change

Forced migrations across an organization turn a helpful design system into an organizational tax.

Adoption works best when we let teams pull change:

• Innovators adopt first: Teams that built the initial bespoke patterns are usually eager to delete custom code in favor of the official component.
• Teams upgrade when touching the view: Teams can adopt the new primitive opportunistically during planned roadmap work on that screen, rather than in an artificial chore sprint.
• Deprecation signals direction, not emergency: We can document the preferred path, mark the older approach as deprecated, and provide a generous horizon so teams can transition naturally.

A shared primitive proves its value when product teams pull it in because it saves work—not because an upgrade was mandated.