Help Center

Managing Design System Work

Michelle Chin

We get a lot of questions about best practices for managing design system work, especially if you’re running a little scrappy or don’t have a centralized team. While it’s similar to managing design work for a product, it’s pretty different and can be much more complicated.

We’ll cover everything you need to consider when managing design system work, point out where design system work is trickier, and how to navigate those scenarios.

What does design system work include?

When designing a product workflow, a button is just another UI element. However, in a design system, a button isn’t just a button. Many details go into determining what’s in a button component, for example:

• What does it look like when it’s loading?
• Is there an error state?
• If there’s a long label, how does the button respond?

And that’s just thinking about the design aspect of the component. When adding a component or pattern to a design system, there are many “steps” to consider. (Note: for the sake of simplicity, we’ll use “component” to mean both components and patterns.) These include:

• Design the component (explore ideas, narrow to a few options, solve for a breadth scenarios)
• Review and approve the component design
• Create the component in the design tool
• Test the component in the design tool
• Create the component in the relevant code libraries
• Test the component in the code libraries
• Write usage guidelines for the component
• Create or update documentation for the component
• Communicate the update or change to design system consumers

There’s extra effort involved in each of these steps compared to typical product work. Designers must think more holistically about how design decisions affect the UX of products across the portfolio. This includes accounting for several scenarios, exploring options for them, and ensuring the solutions complement the system. Coding components that several products consume becomes challenging because developers must ensure the component doesn’t introduce a change that inadvertently breaks any product. This isn’t to say you’ll always have problems with design system work. Instead, there’s more attention needed compared to typical design work.

We recommend breaking down the work into these steps for a few reasons:

• It accounts for ALL the work needed in a way that’s specific, more accurate, and harder to forget. (For example, if we just said “create a button,” it’s easy to forget that we need to document the usage guidelines, too.)
• It’s easier to delegate the work. While some designers might do several of these steps, it won’t always be the case. More technical design tools, like Figma, require specialized skills and mindsets for creating these components. This doesn’t interest every designer. There might be best practices that the team follows to ensure consistency and a good user experience for the other designers.
• The focused tasks allow for more flexibility with existing workloads. This is especially helpful for teams that can only “fit in” design system work. It’s easier to assess if a specific task (e.g., creating usage guidelines) fits within a given sprint (or time) along with other product work. Fitting in design system work can often take longer than if there was a dedicated team to handle the work. But breaking down tasks might allow teams to do more if they can delegate to more people. For example, if one person only has time to create the component and can’t get to the usage guidelines until weeks later, you may find someone else to start writing the usage guidelines.
• You can story point the work to get a sense of the effort. When tasks are specific, it is easier to estimate how much effort or time it’ll take someone to complete them. This is helpful when weighing the work against other product work and ensuring the person has enough capacity to complete their work. And if you’re curious, it’s possible to story point design work.

Tracking design system work

Tracking work tasks

Tracking design work is more straightforward. The easiest option is to use the project tracking tool the organization already uses. This reduces any learning curve and allows you to fit design system work into other planning sprints, boards, etc.

Regardless of which tool you use, you want to ensure you, your team, and others have a way to

• See what individuals are working on (both design system work and other product work)
• View design system work holistically (to monitor progress, see the status, identify who’s working on it, etc.)
• Add design system work to a team or individual’s sprint (or workload for a given time).

Additionally, tracking the work in existing tools provides more visibility into the design system and the effort it takes.

For previous design systems I worked on, our organization used Jira. We created our own project in Jira and created kanban and sprint boards for the design system work. We leveraged labels to build dashboards and used links to connect design system work as dependencies for other product deliverables. (We’ll touch more on dependencies later.) If you’re unfamiliar with your tracking tool, check in with a Technical Program Manager, Scrum Master, or other tool admin, and they can help figure out some potential solutions to meet your needs.

Tracking overall design system progress

Because there are many moving pieces in the design system, it’s also essential to track the overall progress of each component. This is helpful for design system makers and informative for design system consumers. Not doing this can make it difficult for makers and consumers to see progress at a holistic level. When people feel unclear about the design system, it can affect adoption and maintenance.

Many teams create a chart in their documentation that lists the component, design status, and implementation status across any codebases they support. Additionally, teams maintain a changelog that people can skim to see if there are any recent updates.

Decathlon’s design system documentation tracks their component statuses.

Tracking decisions

People often need to pay more attention to tracking the decisions made on the design system. The team makes several decisions when defining a component and implementing it. These decisions can be obscure or odd workarounds for technical limitations or other reasons. Taking note of these decisions is hugely important because no one will remember all of them, especially three months later. One way to consider documenting these decisions is through “Design System Decision Records.”

We recommend tracking decisions in the most effortless format for you and your team. We used our meeting notes for teams I worked with to jot down our decisions and why. As long as your method allows people to find information quickly, that’s all that matters. (At one point, we tried to keep separate note pages for each component, but that got unwieldy to maintain during our meetings. It was too much context-switching!)

Getting the work done

Prioritizing components

If you’re just starting the design system or updating a lot of it, you might need to prioritize which ones to do first. You can run a workshop to help identify which ones to prioritize. Keep an eye out for needs from the actual product teams. Aim for things that will lead to impact and success early on for the products and the design system. This helps build momentum.

Negotiating the work

Negotiation is probably the most tricky aspect of getting the design system work done when you don’t have a centralized team. Often, feature work will take priority over design system work. Even though design system work is foundational, it doesn’t have the immediate customer impact that a new feature would. Often, a cultural mindset shift needs to happen, but that requires a lot of buy-in, support, and change management. However, there are certainly ways you can still get design system work done – it just takes some negotiating, expectation setting, and patience.

Here are some common scenarios and best practices:

Add the design system work as part of the product work. For example, the team is working on a new chatbot feature and needs a set of chatbot buttons. These buttons would be great to add to the design system because other products will have chatbots later. As the team is designing and coding the chatbot buttons, they can spend a little time designing the component for the design system, adding it to any libraries, and writing documentation for it. Because they have to design and code it anyway, the extra work to put it into the design system might feel minimal and feasible. However, it might not be entirely possible to finish all the steps of getting it into the design system (i.e., the designer can create the component, but the dev team can’t get to testing the component). This is why it’s essential to break down the steps of each component so that you can add any unfinished steps to the backlog.

Design and developer teams need the component NOW to meet their deadline! We hear about this often—getting a component in the system is urgent, but adding that component to the design system takes too long. While not ideal, sometimes it’s better to let the product team make their own component instead of waiting for it to appear in the design system. Especially if it’s a new component or pattern, it might be better to see how well it works “in the wild” before committing it to the design system for everyone to use. In teams I’ve worked with, we wouldn’t add a component to the design system until it was in a product for six months.

Before settling on this option, discussing other possibilities with the product manager, devs, and designers is worth discussing. Some questions you can ask include:

• Could the team contribute to adding the component to the design system in the future? (And when?)
• When could the team refactor the code when the component does get added to the design system?
• How much effort would refactoring take? Is it worth creating the component?

While the outcome might not be ideal for the design system, it’s important that everyone’s on the same page and understands the expectations going forward. This is where being patient helps. The design system might not get completed immediately, but it will be someday.

There’s a backlog of components needed, but no one can fit it in with their existing work. If the above scenarios don’t go your way, components can pile up in the backlog. There are a few ways you can try handling this.

Allocate capacity for design system makers in their sprint. Sometimes this simply means adding a placeholder ticket into their sprint for design system work. As design system work comes in, ideally, there’s some capacity to pick up the work. (This is why breaking up the work into smaller, specific tasks is helpful.) If the maker has no design system work, they can continue their usual product work.

Hire a contractor. If the backlog is causing significant pain points in productivity for teams that consume the design system (not to mention the mountains of tech debt piling up), consider hiring a designer, developer, or writing contractor for a few months. Having someone solely focus on production work can make things much smoother. Your design system makers can focus on making decisions, and the contractor can concentrate on implementation.

Create a rotation system for contributors. In this approach, a designer, developer, or content writer sits out of their usual team for a sprint. Instead, they focus on updating the design system for that sprint. Sitting out of typical sprint rituals can be a nice change of pace for them. When considering this option, consider how often this rotation would happen, how people would get chosen for the cycle, etc. Some managers might be less OK with this than others; losing a teammate for a sprint can feel jarring for some.

Host a design system day (or week). Depending on your department or company size, hosting a day or week to focus on design system work might be an option. For this, design system makers would only work on design system work to get the design system updated. If your organization runs an Agile framework like SAFe, this might be an activity for the Innovation and Planning iteration. However, avoid using this approach as part of/in place of a hackathon. Teams want to use hackathons for innovation, being scrappy, and having fun, so preserving that spirit is essential. (Also, if this is your first time hearing about SAFe, don’t consider implementing it. I can save that for another article, or you can listen to me talk more about its pitfalls here.)

There are many different approaches to getting the actual work done. Try to find something that works in a way that feels natural to the team and can contribute to the success of the design system. While negotiating things might mean compromise for the design system or product teams, ensure everyone is on the same page with expectations. For example, if the team can only work on the design system once a quarter, there will be times when it will be outdated, or it’ll take longer to get it to a complete state.

Noting pain points

As you negotiate and track the work, jot down any pain points you, the design system makers, and the product teams face. This can help you build a case in requesting more resources. (It also helps to refer to your design system as “infrastructure” rather than a “product.”) This is especially important if you don’t have a centralized team. Scrappy or federated teams often struggle, and they can accomplish only so much without proper resources to scale. For more insight on evolving past being scrappy, I wrote an article on managing a scrappy, federated team.

Communicating the progress

If you’ve made it this far managing design system work, you have one last and hopefully easy step! The final step is letting people know of any updates, so they can start using them. The tracking chart and changelog are two great places, to begin with, but it often requires people to seek out that information, which they might not do. We recommend being a little more “shouty” about it, so posting in a Slack channel, mentioning updates in any team or department-wide meetings, etc. We have some additional ideas if you’re looking for several more ways to increase adoption.

DesignOps for Design Systems

This is one of many articles we’ll be writing about when it comes to leveraging DesignOps for design systems. If you have questions about how your design system can be managed better through DesignOps, feel free to contact us.