Building a design system is a complex task that requires effort and energy to make it operational. After you finish building it, you need to start the more complicated task of maintaining it.
Every small change in the design system, once implemented in the product, requires testing and detailed work to ensure that nothing negatively affects the product.
Imagine changing the color of the text and then realizing that in some places of the product, you weren’t aware that the contrast between the text and the backgrounds isn’t accessible.
In this article, you’ll learn the crucial points you must consider to make maintaining the design system easier and avoid mistakes.
Many people think that when you finish the design system it’s ready for life, but it’s not like that. A design system is a product you need to maintain as you would maintain any other digital product.
To illustrate, let’s take a simple case of an error in the design system — the dropdown component doesn’t open if the list inside is too long.
This case is the same as with any product; you’ll need to open a ticket and ask the developers to fix it, and then the QA team will review it.
Another possibility is that you need to improve the dropdown component. For example, you want it to have a search option.
Then, in the same way, you’ll need to talk to the design system team and ask them for improvement. Because of all this, consider that the design system is a live product and not just a static component in your system:
To keep the design system live and usable, do the same as you would with the products you sell to the clients. Talk with the users of the design system.
Because it’s an internal product, people only sometimes discuss their issues with the design system team. They take the product as is. This can also be the case because of political issues inside the companies, especially in big enterprise companies with more complex bureaucracy.
Your task is to encourage people to talk with you and the design system team so the team can understand how to improve the product. You can ask for feedback in a general email or survey, but often, direct messages to the users or one-on-one interviews will be more effective.
I remember that designers didn’t use some of the components in the Figma UI kit because they didn’t understand how to use them. Also, I found that we had some contrast issues in some components that I did not know about.
So, talking with the design system’s users (designers, developers, and product managers) will provide many insights that will help you improve the system.
An additional technique is adding an analytics tool to the design system and seeing how often users use the system’s components. This will help you understand which parts of the system to prioritize.
Figma has an analytical system in the Figma libraries where you can see how the designers use the components from the UI kit in their designs.
I always say that the product is your source of truth, but looking at the Figma libraries’ analytics can also give you a good overall view of the design system’s usage:
It is essential to market the design system inside the company to maintain and improve it.
There’s two reasons for that:
After launching the design system, the company often wants to avoid investing more money because managers think it is static.
It’s not a product that directly makes the company money, and from there, cutting resources is easy.
Because of that, regularly communicating the design system’s value is essential. It helps get people to use it and it will be easier to get the budget when they see its value.
It’s even more important in enterprises with many employees since people join and leave the company frequently and if no one takes the time to explain the design system, people may use it less and less.
Here are some ideas on how to market it:
All these activities will ensure that the company’s people know and use the design system so they can understand its value.
Like every project, prioritization is critical to put the focus on the important topics.
Prioritizing design system tasks can range from fixing bugs in the Figma UI kit and components in the code to adding new elements.
Apart from that, sometimes, a new regulation enters the market and requires changes to the design system before anything else. That can be critical in large companies because it’ll affect many places in the product.
Because the design system is not the company’s main product, it has limited resources. Therefore, take advantage of all your resources to determine what is most important to consider in the system.
You can use prioritization tools, and you can also build a roadmap to prioritize what’s important:
The people who manage the design system must respond and solve issues such as managing bugs, adding new components, updating the Figma UI kit when managing the design system version control and removing components from the design system.
If no one is officially assigned to these tasks, the questions will remain unanswered, making the design system outdated and insufficient.
Working for a large company with more resources will make it easier to know who maintains the design system because everyone will see that they have a team that does so.
However, it’s typical for senior employees in a small organization to work on both their project and the design system. Making it official who handles the system is essential to ensure all employees know who to contact with design system issues.
You have to build guidelines for how the team should communicate to you whenever a team member finds a bug or needs to improve the design system, like adding a new component.
When you don’t have clear guidelines for organizing and prioritizing the information, people will communicate with you differently and through different channels. Some will use Slack, some will use email, some will use Jira, and some will use Confluence.
For example, if the team wants to communicate bugs in the design system, they should build a clear format for adding all the information about the bug.
It can be something like:
Then, you can prioritize and evaluate if it will be an immediate fix or if this bug can wait for the next iterations.
Another option is to ask the team to open direct tickets in Jira.
Only some people like to give all DS users permission to write Jira tickets because it can be a mess. But you’ll save time if you trust your people, tell them how to write the ticket, and build a process with them. For example, they ask you, you give permission, and then they open the ticket so you won’t have to copy it from another place.
In a large enterprise organization with many designers, you can ask the design team managers to speak with you before opening the ticket. That way, you only need to deal with some of the designers in the company:
All the changes you add to the design system must be documented to ensure continuous improvement by providing a clear historical record of updates and decisions.
For each question you have on the design system, you’ll have this document that explains the changes so all the people, including you and the company’s new hires, can know about the changes and the design system history.
This is especially important in big companies where people don’t always have direct contact with the design system team.
When I maintained a design system, the developers who worked with me and I paid a lot of attention to writing the changes well because we didn’t remember anything one week after we made the changes. The documentation helped us review the design systems’ history to find information.
Although the Figma UI kit is only part of the design system, it’s critical for designers because it’s one of their main tools when working with the design system.
You have two points when you work on the Figma UI kit.
The first thing to consider is whether the Figma UI kit needs new components, improvements in existing components, or fixing bugs.
The second and most critical point is when Figma launches significant improvements that change how you work with the UI kit. For example, when they launched the movement from styles to variables.
I like to adapt to changes, but you must do it carefully and not rush to make each change. For example, when moving from styles to variables, you need to make sure you make the transition well and speak with the developers to determine if it can also affect the code.
It would help if you took the time before making the changes. Read people’s opinions and watch YouTube videos to understand the pros and cons, and then make them.
Since changing the UI library takes a long time, I won’t adapt it if it doesn’t create more value for the design system or the users:
Before every change in the design system, run a QA session to test it. Because the design system is used in every part of the product, every small bug can have a big impact.
To ensure the release goes smoothly and is high-quality, meet with the QA team, explain the needs, and build a test process.
I will also involve designers from the team to conduct the tests in addition to the testing done by the QA team.
By involving designers from the team, you can ensure they’re watching the changes and determining if any issues need to be resolved in advance.
In this article, you looked at design system maintenance and how it can affect the usage and quality of the design system.
First, it’s important to consider your design system as a product rather than a static component that we use.
You need to fix bugs and make changes and improvements because the product needs them and because of things that aren’t dependent on you, such as new regulations.
You need to communicate the information about the design system to the people in the company and always show its value so people will understand its importance and continue to support the project in the company. Because the design system is an internal project, marketing is important to gain continuous support.
LogRocket's Galileo AI watches sessions and understands user feedback for you, automating the most time-intensive parts of your job and giving you more time to focus on great design.
See how design choices, interactions, and issues affect your users — get a demo of LogRocket today.
UX testing is not limited to layouts, copy, and visual design. Full-stack and server-side experiments help teams evaluate how backend logic, APIs, algorithms, and product flows affect the overall user experience.
In A/B, A/B/n, or multivariate testing scenarios, using p-value with traditional null-hypothesis-based statistical analysis is so common, and most designers […]
Traditional A/B testing splits traffic evenly, but multi-armed bandits dynamically send more users to the better-performing version. Here’s how the method works, where it helps, and when UX teams should use it over classic A/B testing.
AI agent simulations promise faster, lower-risk UX testing by replacing real users with AI-simulated personas. Here’s how the method works, where it falls short, and when designers should rely on simulated users versus real user testing.
Learn more →
