Establish an ongoing maintenance strategy

A comprehensive maintenance plan curbs product debt. With design systems, “every paper cut is felt1,” and each change potentially impacts the ability to refactor. As a public good, a utility of sorts, the community using the design system should reflect the shared goal and shared success use brings to an organization.

Maintenance is a healthy part of creating a design system that’s built to last. Rotate the tires, change the oil, swap out for winter tires, get new headlights…the works. The team maintaining the design system needs to be regimented and fearless about making the necessary changes for its long-term health.

DON’T: Push updates out automatically by treating the design system as a shared and centrally located service that other applications call upon. While this tactic reinforces conversations about consistency, the option risks introducing breaking changes every time the design system updates.

DO: Release design systems with each new version. Every version should feature a list of changes, including any broken changes, changes to elements, sizing, layouts, or discontinuing components. Once receiving word of an update to the system, each team adapts the change and integrates the update to the respective roadmap. Reporting then surfaces the number of products on each version, and focuses support when necessary (e.g., if various users of the system fall significantly behind).

Design tokens are one approach to shared styles across locations while not pushing breaking changes when updates are made. Championed originally by the team at Salesforce, this approach abstracts away variables like font sizes and colors. Throughout the coding effort, variables are used in place of specific values. These variables then live in a single repository that can be updated. When changes are made such as changing a font or the size or color of an object, these updates are applied to the tokens rather than repeatedly across every instance of the design system. This tactic reduces the overhead on engineering teams by eliminating the flow of small change requests through the backlog.