Tips for Maintaining Your Design Systems

It takes a lot of time to set up a design system. You have to come up with a set of guiding principles, establish the foundational elements of your digital product, and design its UI patterns (among other things).

You invest the time in creating one because you know it’s worth it—scalability, consistency in design, improved team collaboration, better product outcomes. Design systems are definitely worth their while.

Just remember:

The goal of a design system isn’t just to guide initial product development. Sure, it makes things go smoothly, but that’s not the only reason you should have one. It’s a useful resource to help you in managing and maintaining your app (or website) going forward.

Because of this, you’ll need to maintain, update and evolve your design system just as you do your product.

Updating and Maintaining Your Design System

Your products will change. You’ll add pages, swap out components, rewrite content, repair the UX, or redesign the entire thing. Whatever changes you make to it, though, they generally won’t just affect one isolated element.

In order to make sweeping changes to your product (or family of products) and keep tabs on the latest and greatest guidelines, components and design patterns, your design system needs to be updated as well. Regular maintenance of it will allow you to do that.

Here are some things you can do to maintain it:

1. Give It Life

Ideally, this is something you do when you first create the design system. However, if you have an existing one that currently resides in PDF format, distributed across various platforms, or access is gated off, that needs to change.

While you don’t have to make your design system publicly available the way, say, Google does with Material Design, it should be a live system that your team (and client) can view and use.

There’s a really useful tool called Frontify that allows you to convert your design system into a live resource.

With this platform, you can create a dedicated portal for your brand, its product(s), as well as its design system.

Everything you’d document and store within your design system can be uploaded to or created here, including:

• Brand guidelines
• Style guide
• Digital asset manager (e.g. photos, videos, fonts, etc.)
• UI patterns
• Code snippets and components

Here’s an example of what the style guide part of the design system looks like:

Other things you should know about this platform:

• Collaboration and communication are built in so the responsibility to maintain the design system doesn’t fall to just one person
• You can manage your design system–related processes (or regular design processes) from here with a built-in workflow tool
• The platform integrates with Sketch, which makes implementing changes to your live UI pattern library much easier
• You can view the changelog to see what was updated, by whom, and when
• Analytics allow you to track activity within your design system to ensure your team actually uses it

What might have been a lot of work previously has become rather easy to do thanks to this design system maintenance platform. And because you have total control over everything within it, you won’t have to worry about the design system going unused, projects getting held up because people don’t know where to find it, or unmonitored changes being introduced to it.

2. Perform Regular Audits of Your Design System

Once your team gets used to incorporating the design system into their workflow, it’s inevitable that someone will discover that something is outdated, no longer used, or that needs to be added. So long as they feel empowered to do so, they can take an active role in keeping the design system up-to-date when they encounter these scenarios.

Having a user-agnostic maintenance tool will hugely help with this.

But should it only be up to your designers, developers, UXers, product managers, or even writers to maintain things? Definitely not.

There should be an audit process in place—and a person or team responsible for managing it—so you can take a proactive approach to maintenance as well.

I’d recommend scheduling design system audits at about the same frequency as you perform audits of your product. Better yet, do them at the same time. Set aside a half to a full day (depending on the size of your product and design system) and make sure everything is accounted for. That way, you don’t have to play catch-up with your design system. The two always remain in sync.

Before you do your first audit, put together a checklist of the items you need to review. You can reuse it each time you do an audit.

Here’s an example of how you might organize yours:

Guidelines

• Brand
• Design
• Usability
• Accessibility
• Responsive

Styles

• Colors
• Dark/light mode
• Type
• Icons
• Images
• Animation
• Alerts/push (design)
• Alerts/push (sounds)

Layout

• Navigation
• Breadcrumbs
• Sidebars
• Hyperlinks

UI Components

• Buttons
• Forms
• Alerts
• Header
• Footer
• Sticky elements
• Tables

Code
Pages
Tools

You can provide as few or as many details or questions as you want. Just make sure that no stone is left unturned by the time the review is complete.

Once you’re happy with your audit checklist, give it to the design system manager (or your project manager) and have them add it to your task management software. You’ll want this process templatized and digitized so it can easily be scheduled in advance and pulled up the second you’re ready to get started.

3. Develop a Change Request Process

Whether design system changes are detected during the audit process or just while managing your product from day to day, you need to control the flow of these changes.

Because this is a living resource that your team depends on, you can’t afford hastily-made decisions or changes to be implemented without going through the proper chain of command. So, the first thing to do is to establish the owner of the change request process.

Ideally, there will be one person or a small team who owns the design system. It might be a lead designer on the project who knows the client, the app and the goals inside and out. Or it might be a small team composed of representatives from each contributing department.

Regardless, you’ll want one person in charge of the change request process. They’ll be the one moving each reported change through the chain of command.

• If the design system is managed by one person, that responsibility will fall to them
• If the design system is managed by a committee, hand the responsibility to your project manager and have them set up a separate workflow for change requests

They’ll also be responsible for determining the priority of each submitted change, ensuring that the most urgent of requests is implemented as soon as possible. You don’t want your team working with an outdated design system if you can help it.

To make sure this process goes off without a hitch, add a change management software to your set of tools (if you don’t already have one). A ticketing system works just as well. So long as you have the ability to customize the workflow, set priorities and collaborate with other stakeholders, the choice of software is yours.

For instance, here’s how you might set it up with Jira:

Regardless of which tool you use, you want your process to follow a similar trajectory:

1. Place new requests into an open queue.

2. Change manager reviews the request to make sure the request is 100% clear and all information (as well as supporting evidence) is provided.

3. They pass the request over to the reviewer and decision-maker for this specific kind of change.

4. The decision-maker reviews the request and determines how narrow or broad of an impact the change will have on the design system, the product, and current work. They set a priority accordingly.

5. The change is implemented by the design system owner and reviewed by the decision-maker. (Note: This only accounts for changes to the design system. If the change impacts the live product, then another change request should be initiated for that specific workflow.)

6. The design system update is communicated to the team.

7. The change request is archived for future reference.

This isn’t as extensive a change management process as the one you’d use for a live app. However, that doesn’t mean you can forego it. If the integrity of your design system is compromised in any way, it can have far-reaching effects on your work.

Wrap-Up

I know, I know… There’s already so much you have to do in order to build apps and websites for your clients. Why should you have to treat your design system like another project?

But look at it this way: You never know what might happen a month, six months or six years down the road with this project. You may lose three of your designers and gain five new ones. Your client might decide to rebrand the app for a different audience. You could discover new ways to improve your conversion rates through ongoing A/B testing.

Your design system keeps a live record of your app. If it’s not properly maintained, these undocumented changes could bog down your team with reworks that could’ve been avoided, unhappy clients and team dissatisfaction.