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.
But what won't likely be transferred is the institutional knowledge and design decisions you've made. Saving that from the old design system is one of the most important things to be efficient with your time.
To explain this, let's consider the date picker.
Saving what design decisions were made previously matters most
Which of the potential Date Picker formats does your organization use?
MM/DD/YYYY (i.e., January 15th, 2024)
DD/MM/YYYY (i.e. 15 January, 2024)
MM/DD/YY (i.e. 01/15/24)
DD/MM/YY (i.e. 15/01/24)
etc.
These are all potentially correct but can cause chaos if done poorly. For example, having one page be Month First and another be Day First can lead to several usability issues.
You've probably had a meeting to standardize the format across all your pages. Writing down that decision and putting it on your internal wiki is one of the most important things you must do. Otherwise, you'll have to repeat a bunch of old conversations.
Preserving every design decision you've made and making these visible is one of the most critical things when a new design system, because you cannot edit the other design system's documentation.
For example, if you use Material.io as your design system, Google can provide much general guidance. However, you cannot edit Google's wiki to include your context, so knowledge must live somewhere.
Having a repository of design knowledge specific to your project is critical. To do that, you can create an internal wiki with a template to understand any design decisions made with specific components easily.
Create a template for each component with your documentation
One of the easiest things to do to ensure that we save design knowledge is to follow a template for each design component.
These templates should be designed for future designers, as Engineers will likely be able to get specifications from the new design system wiki.
Here's what you might want to include as a template for a drop-down menu:
Use Case: What are your design recommendations for using a drop-down menu? What are best practices, and what are they used for?
Alternative options: Why might you use a drop-down compared to other design options? For example, we could use a radio button for two options but use drop-downs for three or more.
Design Decisions: What design decisions were made around this particular component? For example, should users be able to add new options to the drop-down menu by typing things in (i.e., autocomplete)?
Quick Do's and Don'ts: What are some recommended guidelines or best practices for these components?
Hyperlinks to the new Design system component page
You might think this stuff should be standard in many design systems, but that's only sometimes the case. Some 'design systems' are created with the Engineer in mind, which means they talk a lot about coding but not use cases.
We're not trying to save the visual formatting; we're trying to save our design knowledge on the component. Once we've assembled this, then we can create an internal wiki.
Create an easily accessible internal wiki for future use
To ensure this knowledge is kept from being created and shelved, you must figure out a visible place people know to check for future reference.
Remember that this should be considered more of a reference than anything else: it's unlikely that this page will be updated except to include additional design decisions you may make.
As a result, these templates should be short and quickly read over when using a design component (from the new design system) in the future. Ideally, someone would have the design system wiki open on one tab and this 'reference guide' open on another.
While this sounds like a fair chunk of work, it can save you a lot of time in the future. It helps you avoid one critical issue when switching design systems: rehashing all your design decisions in a bunch of duplicate meetings.
Archiving your design system saves you time and effort
It sucks to shelve a design system.
It seems like all your work is going to waste, and it's very likely that you won't be able to return to it in the future. As a result, many of the visual components that you might have spent months on feel like wasted work.
However, the knowledge and decisions you've made about it are essential to preserve because they can save you time in the future.
Having months of second-guessing design patterns and snap decisions on design decisions you made years ago will only lead to bad decisions and inconsistencies.
So, if you've ever needed to archive a lot of your existing work because you can no longer maintain an internal design system, consider archiving the knowledge rather than the design component.
Doing so will ensure that you will still benefit from all the design decisions you've made in the past, even if you're no longer using the design components. Doing that, especially with the reduced UX team, can pay off in spades.
My Maven course on Data-Informed Design is now live! Learn more about using data to communicate more effectively with your team.
Kai Wong is a Senior Product Designer and Creator of the Data and Design newsletter. His book, Data-Informed UX Design, provides 21 small changes you can make to your design process to leverage the power of data and design.