Member-only story
How to archive your design system effectively
Why preserving design decisions, not visual components, matters most
"So we've made the decision to switch to another design system." The VP of Design said, sparking a wave of discussions.
It had been a long time coming. We'd lost the resources necessary to update and support the system, going from a dozen designers to just three.
However, years of knowledge and user research were about to be lost. Our design system had tons of notes, best practice research, and all sorts of documentation built up around it. How could we avoid scrapping all of that?
After working through the process over weeks, here's what I've learned.
Design systems are living things, which means sometimes they die
Maintaining a design system is a lot of work. In addition to designing features and other projects, maintaining everything around the design components, typography, grid layout, and more takes a lot of additional effort.
At the same time, there are several accessible and well-maintained design systems out there, so it's not unlikely that you may be asked to switch an internal design system to something that currently exists.
When that happens, it can become a race to save what you can of the old system before everything moves over. However, when that happens, you must prioritize saving documentation over everything.
It sounds ironic. Many might assume you'd try to save something visual about the design system, but that doesn't work for several reasons.
The first is consistency. If one toggle looks like your old design system and another like the new one, the design will not be consistent across all pages.
Furthermore, saving the visual aspects means maintaining these 'legacy' components in the future. Certain pages will require developers to refer to old system documentation, while others require them to look elsewhere.
Lastly, if you're genuinely phasing out the design system, your old design component will eventually be replaced.
