Deprecating in design systems: When it’s time to say goodbye
Dan Donald
Everything has a shelf life, a time when something has served its purpose and it’s no longer needed. While we talk a lot about how to start a design system, it’s not often talked about what to do when values or whole components meet the end of the road.
In software, the term ‘deprecation’ has long been used to draw attention to an aspect that will soon be removed so that developers or even the end users will know that feature won’t be around much longer.
That term hasn’t often made its way over to our design process, but as the likes of Figma are bringing across concepts like branching from more technical tools, maybe it’s time to consider what happens at the ‘end of life’ for aspects of our design system.
There are a number of challenges we might come across, whether a design token is no longer needed, a small atomic component, or a larger section of layout as there are all differences in the amount of work and risk involved in change. In order to make a change and then delete the original value or component as smoothly as possible, what is the sequence of the work needed? Are there any dependencies? Are we able to estimate how long it might take? Are there risks in now doing the work? Are there risks associated with making this change?
When might we need to deprecate?
There can be a lot of reasons why a token or a component may no longer be needed. Maybe your color palette has been rationalized and so some colors can be removed. Over time, we can learn a lot about how our components are used out in the wild and so we might find a better way to solve a problem that a component currently solves. Maybe a tech change is needed or a change to branding.
As a system matures, thinking about deprecation and so deletion in a safe and smooth way becomes really important; while keeping consistency between design and development. If not, we have elements in our system that are redundant and both clutter up the space and could potentially still be used. It’s the process of cleaning up after ourselves as things evolve that helps the integrity of the system as a whole.
It’s sometimes hard to let go when we’ve put a lot of work into something too! We might feel a component is a great piece of work or be justifiably proud of some engineering effort…but the system isn’t about us, in whatever form your organization and team structure takes, it’s about ensuring the direct users of the system can create great experiences for the end users. Things can and should change over time to keep the system and the output relevant for problems needing to be solved for internal and external users today.
What does this process look like?
At some point, we want to let people know a component is no longer to be used and that another should take its place. If a component is out there in the wild, so used in our designs and live code, we don’t want to just delete it as that could leave us with a hole in our work and no trace of where the now removed component once lived.
Ideally, we want to aim for a smooth transition between these two components so that we have continuity and ensure there’s little friction with a change like this as it spans from a design change through documentation to code…or vice-versa.
In some way, we need to flag to our colleagues along our workflow that this ‘thing’ will soon be removed and in that way, deprecation and deletion are as much about how we communicate about change within and from our design system as it is a practical exercise. This relates to why governance is often such a key part of a design system – having some structures or processes in place to manage these kinds of challenges. You may be able to shout out in Slack/email, etc, and let people know but there comes a time when this component shouldn’t be in the library, as inevitably it could be used. Deleting it from the library may cause older designs to break as the reference to the component will be broken. Taking a look at our workflows early on and considering changes like this can be really beneficial.
When evaluating components for deprecation, consider:
- Have a plan for communication. Part of the workflow audit process you could do is working out roles and responsibilities for changes like this, which should include who needs to know about changes from designer to product mangers, front and back-end developers to testers/QAs so that everyone know what to expect ahead of time
- Think about how you could get some basic analytics of the usage of a token or component and if it’s possible to find out where it’s consumed. This visibility isn’t always easy to come by but can help with processes like this.
Deprecating a design token
Let’s look at what current options we have as well as explore some potential issues in the future. When we know we would like to replace a token with another, not just change its value, we need to somehow flag that this token is now in a deprecated state.
Though they’ve been around for a few years now, there’s still so much to come from them, least of all, portability between design tools and code. Today, the Figma Tokens plugin does a great job of that to help us on our way but a lot of what we need to consider can be used in existing libraries or palettes in every design tool. While they may not be tokens in a literal sense, this forms part of a workflow that enables the sharing of values that may be coded as design tokens at some point.
Part of the issue we have is that tokens as they stand focus very much on storing a value and may have a description with them, so in larger scale or more mature systems we’re missing some information that could be helpful from the date a token was added to when it was deprecated.
That means that in the short term, we kind of need to hack around a bit to find a way of communicating this kind of change. We could:
- Gauge the impact of the change and have confidence that changing the relationships between this token and others that might refer to it (alias tokens) and through a solid workflow make this change and skip the need to flag deprecation and keep it as a workflow.
- How many references do we have to this token?
- Should every relationship map to the same new value or do we need to make a number of different relationships between values in its place?
- Are there any other tokens used as one of its values that would now be orphaned and so could also be deprecated/deleted?
- Use the description field with a large note at the beginning like ‘[DEPRECATED]’. On its own, that’s likely to be quite ineffective. There’s no guarantee that this field would always be visible from your design tool through to your coded output
- On the build side of our token and its output, we could build in tooling or visibility to look for this text marker and suggest to developers that a change is needed…or optionally break a build.
In our design tools where we may not be able to use tokens directly, we need to understand the handover process from our palette/component/symbols to code. A workflow audit should help make that clearer for everyone involved. There’s the risk or human error or tech mishaps in any handover process or manual intervention, which become more pronounced in larger systems, so clear communication is really important. Using the ‘[DEPRECATED]’ string of text on a color value is still appropriate when using the tool, but knowing where to go to find out more, in your documentation is key.
If you’re a Figma Tokens user, you can amend your description field so that on hover or edit you could see its deprecated state but as this is a generic field, there wouldn’t be any greater visibility given to it.
Deprecating a Component
If you’re a Figma user, there are some great articles or blog posts written around this already, so it’s worth reading Steve Dennis’s piece, this from Owen Anderson in 2019, or this from Luka Nekcevic that incorporates a great reference to using Figma analytics. But let’s dive into some scenarios and questions you can ask yourselves regardless of the tool you use.
When we talk about components, it’s a generic term that encapsulates many potential levels of complexity. Using some kind of strategy to break this down, such as Atomic Design, a component could be something as small as a button or as complex as a page section, itself built of many smaller components.
When we are faced with needing to replace an existing solution with a new one, we should consider:
- Is it used directly in full templates/layouts?
- Is it used by more complex components?
- Is this change the same for every use case or do we need to provide different replacements in certain places?
- Does it contain other components that may no longer be needed and so as a later task, look at deprecating or removing them?
Our workflow should enable us to see across design files and code, to gauge the volume of usage and what a given component is consumed but this isn’t always easy. Our tooling doesn’t yet give us everything we need out of the box but that ability across specialisms to gauge use and composition through analytics is an interesting space.
It’s really about communication
While there are some cues we can improvise across our tool-chain, most of this process is down to us as the team or collective around a design system working together to discuss and facilitate change. While early on in the life of your design system, it’s more around contribution models and governance, deprecation and how we clean-up as we go that become a part of the continued evolution of your system. It should be treated with similar focus to your contribution model over time so these deprecations can be done in sync across the parts of the system and the communication model ensures that your users are clear on the state of a token or component and what to do when this happens.