Help Center

Starting, restarting, or refreshing your design system without burning out

It’s a new year, a new quarter, or whenever you’re reading this, you’re at a point where your team is officially going to start, restart, or refresh your design system. While exciting, the challenge can be exhausting. When this happens, momentum can drop, and people get bored or, even worse – burn out. This can make your efforts futile, require another restart, and put your product further behind. 

Let’s look at some approaches to achieving your design system dreams without burning out. We’ll cover some scenarios we’ve encountered personally or with our customers. 

If you’re starting a design system

It’s great you’re starting a design system! We even bet you’re thinking, “Yes, finally!” The idea of bringing efficiency to the team’s day-to-day workflow feels magical. But where do you start? There’s much to do – UI libraries, code libraries, guidelines, principles, processes, and more. It can feel overwhelming to figure out what should happen first. Here’s what we’ve seen works well for teams.

1. Start with creating components in the tools your team uses

The UI kits and libraries are the foundations of any design system, so prioritize them first. As you get the libraries established, people can start using them.

2. Determine how the team will make decisions.

This dabbles into governance, but it’s the minimum needed to start. Consider who needs to provide feedback, who gets to make the final decisions, and who needs to be informed. We all assume a democratic process is fair, but it might not be appropriate for your team. Sometimes a higher-up stakeholder gets the final say. We’ve seen many teams do well with a consensus-building approach. Whichever you choose, ensure it’s written somewhere (like on a team charter) and understood by everyone.

3. Create a backlog for everything, use a kanban board, and question the impact of things.

Backlogs help preserve sanity because you can list all the tasks. Items no longer have to swim around in your head! And trust me—you’ll have so many decisions to make that you’ll want as much out of your head as possible! You can start to prioritize your backlog, too.

While many things seem important to a design system, determine if you need them now. Design system principles are important, but do you need them now? Probably not. They can wait until you reach other milestones first. A good question to ask yourself is, “Is this blocking people from accomplishing their work?” If the answer is yes, it probably provides a high impact and should be prioritized sooner. Vetting and prioritizing help everyone understand that not everything is of equal, high priority; instead, there’s an order to things.

You and your team can use the backlog as a negotiating tool. Let’s say a stakeholder wants to add a new aspect to the design system. You can work with them to determine where it should fall on the priority list and what becomes a lower priority or doesn’t get done in this round.

A kanban board is an easy way to keep track of the progress. The team (and stakeholders) benefit from this level of visibility because it can help keep everyone focused and less overwhelmed.

4. Celebrate wins!

As your team progresses with the design system, celebrate whenever you can. This can be as simple as announcing Slack when someone makes a new component, and people can reply with reactions and gifs. If you have more significant milestones, consider celebrating those with a team outing, activity, or raffle. Celebrating keeps the momentum going and makes the team feel valued.

5. Keep things simple and go with the flow

As much as a governance process is needed, it’s not something you must rush into. Instead, see what processes naturally form or require some level of procedure. See how things go and adjust along the way. It can be easy to over-architect a process when it’s not needed, or there’s too much to a process that it becomes difficult for people to follow. Save yourself and your team the headache! As the team creates components, start documenting things lightly in zeroheight. Focus on the content, not so much the grammar, voice/tone, etc. People want to know how to use components as their priority. As you document, you’ll get a sense of what’s helpful for your team and what might not be. Later, you can quickly edit things for consistency, grammar, etc.

 

If you’re restarting a design system: 

Design systems are no strangers to restarts. Sometimes one approach doesn’t work, and things need to restart. We also see restarts when design system leadership changes hands or organizations do some re-shuffling. Restarting doesn’t mean starting from the beginning. Here are some tips to help you navigate a restart while maintaining sanity.

1. Evaluate what worked well and what didn’t

Conduct a retro with the team to get feedback on what worked. Things that worked well can carry over to this next iteration. This helps reduce change aversion in a space that might change a lot. For something that didn’t work well, consider avoiding or fixing them so things are better this time. Teammates can build momentum when they see improvements that make life easier.

2. Audit what exists and prioritize from there

The goal for a restart is to work smarter, not harder. Evaluate what components, processes, and documentation exist and see what you can reuse. For example, you could reuse an existing UI kit if you only need to make tweaks. For the things that need to change, estimate the effort and urgency and work from there.

3. Inform people along the way

Change aversion is natural, even if people know change is necessary. As you plan the restart, figure out how you’ll communicate changes to stakeholders, the immediate design system team, and the broader groups that consume the design system. People will have many questions, so it could help to keep an FAQ in your documentation or host office hours. When you inform people, adopting is much easier, and you could be less likely to have another restart.

4. Don’t tackle everything at once

Like starting a design system, work on the items with the highest need or most significant impact. Set realistic expectations and work at a pace that’s comfortable for the team and stakeholders. You want to avoid a crash and burn, which will only lead to sloppy work and yet another restart.

 

If you’re refreshing your design system: 

Refreshes go beyond your basic design system maintenance. Refreshes can include branding changes (new year, new color), adding dark mode, migrating to a new tool, etc. You’re not entirely overhauling your design system, just changing part of it or adding something new. Some refreshes are more extensive than others, which might make you feel like you’re doing a complete overhaul.

1. Evaluate what parts of the design system the refresh affects.

If you’re migrating to a new tool, it could mean that the actual UX and design of the component aren’t changing. Or if you’re migrating from another tool to zeroheight, the usage guidelines aren’t changing. This can help you determine the actual scope of the work. Be transparent with the team and stakeholders about what’s affected by the refresh, so no one assumes incorrectly. As your team is working on things, it can be tempting to make additional changes. Consider how the team should handle changes – if a minor tweak is OK and if more significant changes should go into the backlog. This will help prevent scope creep.

2. Identify who’s affected by the refresh and start collaborating with them.

More extensive refreshes will have far-reaching effects. If your brand colors change, they’ll need to appear in the products. This means coordinating with designers and developers to make things happen. Start identifying who you’ll need to coordinate with. Determine if your organization can stagger the changes or if you need to make them in one go. If changes have to be made all at once, it requires more collaboration and can be more stressful. The earlier you collaborate, the better because stuff will always creep up.

3. Provide training on anything new

We often focus on the refresh for these efforts, but that’s just part of the project. If we switch the UI libraries to a new tool or codebase, people will need training on how to use it. Make sure they get the training they need – it could be as simple as a roadshow, mini-workshops, or watching a few tutorials on YouTube. Depending on the change, training can happen as others work on the refresh. Give people a grace period to adjust to the difference if you can. 

 

Leverage our guides

As you start, restart, or refresh, check out our design system guides on the Learning Hub. We have lots of information on organizing your documentation, organizing your files, increasing adoption, and much more! They can give you a head start or an easier time than starting from scratch.

 

You can do it!

These efforts aren’t easy, but by using some of these approaches, you can set yourself in the right direction and avoid burning out. Best of luck, and contact us if you have any questions! Our Design Advocates are happy to help answer questions via zheroes, our Slack community.