As a system changes, adopters will want to take advantage of what’s new.
“Let’s update the old Card with a new, shiny Card,” they say. Or, dangerously, “Let’s put this newer Button in the page with all those older ones.”
Trouble arises when change is poorly communicated or its impacts ill-defined. Developers compare a proposed design to system code, identify what needs swapped or added, and carefully install or upgrade what’s needed. They are also usually mindful of breaking change in dependencies.
Are designers as sensitive to changes when working in a tool like Sketch? Not as much. They replace this with that. A new Button goes here, unaware that older buttons are used elsewhere in that or other pages. Designers flow updates swiftly, indicating neither the component’s version nor annotating an upgrade compared to what’s coded today. Friction ensues:
“I add a new system feature to my design. Yet the developer says we can’t use it.”– Designer on a product team
“The designer sprays style and component upgrades across a new feature, completely unaware of the upgrade costs it triggers across our whole app.”– Developer on the same product team
Designers want the latest. Developers balance tradeoffs of new quality with scale and maintenance. Systems should clean up that conversation.
Identifying how to version is simple (use SemVer!). However, identifying what’s versioned — by library or by component—is more challenging. Versioning communicates how things change from launch through deprecation and end-of-life. This article takes us through that cycle of change across system outputs: code, tokens, design assets, and doc.
Every discussion about versioning design system outputs begins and ends with the industry standard Semantic Versioning (SemVer).
SemVer versions in a MAJOR.MINOR.PATCH format, incrementing each as a:
MAJOR version for incompatible API changes (that is, something "breaks"),MINOR version for adding features that are backwards-compatible, andPATCH version for backwards-compatible bug fixes.Daniel O’Connor, Atlassian’s AtlasKit, and Morningstar’s Design System offer helpful deeper examples describing SemVer’s application to system features.
Long an industry standard in versioning code, versioning is increasingly relevant in design tools too. Many system teams apply SemVer to Sketch symbol libraries in software tools like Abstract and Invision DSM. You can learn the methodology at http://www.semver.org.
Takeaway: Strongly encourage designers to learn SemVer. Not only will it help them communicate with engineers more effectively, but it is increasingly meaningful in designer-to-designer collaboration too. It changes lives!