Help Center

Design System Roadmaps – How to create one

Michelle Chin

Your design system is gaining momentum; teams see the value and ask, “What’s next?” You have some ideas for the immediate next step or two, but maybe you’re unsure what’s beyond those tactical items. Or perhaps you know what should happen next but need a way to articulate it. In either scenario, we recommend creating a design system roadmap!

This article will walk you through where a roadmap lives in the broader strategy, how to create one, and how it differs from other typical product roadmaps.

Roadmap basics

A roadmap is a high-level plan that documents short and long-term goals. These goals align with the larger strategy. (If you don’t have an overall design system strategy, check out our guide on creating one.)

Typically, teams segment roadmaps by quarter or another large timespan determined by your company. The current and following quarters are usually more detailed because teams better understand what needs to be done next. The further ahead the quarters are, the broader and “fuzzy” the goals are. As you get closer to those quarters, they can crystalize or alternatively change depending on team, organization, or company needs.

The benefit of a roadmap is to get a sense of the design system’s direction. It demonstrates its longevity and establishes additional credibility.

The unique part of design system roadmaps

Earlier, we mentioned that design system roadmaps differ from typical product roadmaps. Regular product roadmaps are often independent of other products. For example, the Google Maps team can work independently of the Google Docs team.

When it comes to design systems, they’re kind of like products, but they’re more like infrastructure. And just like any infrastructure, they serve multiple endpoints. In this case, design systems help multiple teams – products, devices, engineering teams, design teams, content, and more.

So, your roadmap should consider the following:

1. How does the design system play into these endpoints?
2. How do those endpoints align with the design system’s goals?

Striking a balance – negotiating with teams

Considering the design system goals and the endpoints it supports, you must strike a balance. The design system roadmap shouldn’t dictate what the endpoints will do. (It won’t succeed; you’ll make enemies and never get adoption.) Nor is an opportunity for other product teams or orgs tell the design system team what should happen next. Design systems are entities in their own right and will have needs and goals like any other entity.

Because of this unique position, the design system roadmap should be a negotiation between the design system team and the teams it currently or will serve. It’s worth talking to other product leads about their roadmaps and goals. From this, you can see how they might help you achieve your goals (e.g., adopting the design system into their product) or how you can partner and align (e.g., refactoring their codebase in two quarters, so they’ll happily adopt the design system).

As you negotiate with teams, consider what’s realistic because teams and products are complicated. As much as you want them to adopt 100% of the design system in one quarter, it might not be possible. Maybe you negotiate for any new or updated feature they work on, they use the design system. And by the end of four quarters, they slowly chip away at refactoring older screens to use the new design system.

Throughout your negotiation, try to balance meeting other teams’ needs and still advocating for the design system’s best interest.

Creating a design system roadmap

With that context in mind, let’s talk about creating the actual roadmap.

Who should create the roadmap?

Typically, the design system lead or manager should draft the roadmap. It’s not to say they should work alone. We encourage roadmap creators to consider feedback from everyone. While it’s tempting to open up the planning to a broader team, consider if it’s the appropriate approach for your team. Will it help you reach a solid roadmap or will it make things chaotic and decision-making difficult?

For newer design systems

Even if your design system is in its infancy, starting a roadmap is never too early. You don’t necessarily need a comprehensive design system strategy at this point; you’re just trying to get the design system into a better spot.

When your design system is new, consider where it needs to be over the next 2-3 quarters (6-9 months). Think of each quarter as a significant step in the evolution of your design system.

Some ideas to consider include:

• Completeness – the current quarter could be completing the design and engineering UI kits, the next could be documenting the design system, and the quarter after could include adding patterns, etc.
• The breadth of products or themes – phases could involve adding support for additional codebases, products, brands, or themes.
• Adoption of the system – this is similar to addressing the breadth, but it could differ depending on your organization’s structure. Phases can include spanning adoption across X% of teams each quarter.

For established design systems

If your design system and team are more established, it’s probably a good time to create a design system strategy. A strategy identifies initiatives around providing value to the company, product org, and your product’s users. Check out our guide on how to create a design system strategy.

After you’ve crafted your design system strategy, you can use the roadmap as a tool to articulate how the team will work toward those initiatives over time. The roadmap essentially breaks down the strategy into more tactical phases. As you examine each strategic initiative, consider breaking things into quarter-long phases.

It sounds simple enough, but it can get complicated. Here are some things to consider:

• Some phases of a strategic initiative won’t take an entire quarter. For example, migrating from one tool to another might only take a month for a small team. It’s OK that it doesn’t span a quarter. It’s better to provide a realistic timeframe than to span things out by a quarter (or you’ll never get anything done!). On the other hand, try to avoid underestimating time by putting too many initiatives into a quarter. We get the excitement, but we’re big fans of underpromising and overdelivering.
  
• Some phases will take more than one quarter. For example, you’re at a large enterprise company with so many product teams that company-wide adoption will easily take three quarters. If that’s the case, you can note that in your roadmap, but try to break it into smaller, quarter-long phases. So maybe products in Business Unit A will adopt the design system in the first quarter, Business Unit B in the second quarter, and so on.
  
• Some initiatives might rely heavily on other teams. For example, your design system team includes web developers and they’re not familiar with coding mobile apps. So while the work typically takes a quarter, it will take longer. Instead, the design system team must rely on the mobile engineers to create components. And the mobile engineers have regular feature work to complete, so they can commit only some of their time to the design system.

Getting feedback on your roadmap

After creating a draft of your design system roadmap, consider getting feedback. Similar to how we recommend getting input from leaders, peers, and your team, get feedback from different perspectives.

You can start by getting feedback from other peers who have some familiarity with creating roadmaps. Feel free to share your draft roadmap with your design system team from there. They might have additional feedback or questions about the timing or order of phases. It’s an excellent opportunity to share your thought process on the evolution of the design system. Equally, it’s a good measure of feasibility – they might express concerns about the timing of things or the scope of the work.

Lastly, check in with your manager to get feedback. They will usually be more critical and challenge your thought process to vet your roadmap. (Hopefully, they constructively provide this feedback.) They might ask why something takes too long or why you’ve organized things in a particular order, etc. Usually, they’re challenging you because it’s a way to help you grow. Additionally, they do this because, in the overall picture of things, they’re also held accountable for the design system by their leaders.

Your manager might also provide feedback from their broader perspective. They’ll know of other efforts in the organization and can share insight on how that might affect your roadmap. They’ll help you connect the dots so you can improve your roadmap.

Documenting and presenting your roadmap

Documenting and presenting your roadmap is the easiest part of the process. Your documentation doesn’t have to be anything complicated. Here are a few options we recommend:

1. Documenting the roadmap in your zeroheight styleguide – use headings for each quarter and a bullet list of what the team aims to accomplish each quarter.
2. Using presentation software – typically, teams present roadmaps using slide decks. There might even be an existing company template. We’re big advocates of using something the broader org is familiar with so they can easily navigate the content with clarity.
3. Outlining it in a whiteboard tool – you can document it in Miro or Figjam for a more visual presentation.

Depending on what’s in your roadmap, we strongly recommend keeping it high-level. It’s compelling to want to list all the components the team will work on, but that level of detail is more about project management than roadmap planning. Not to mention, this will create more work to maintain and update in two places. Rather than list specific components, you can generalize (e.g., form components, motion guidelines, color tokens, etc.).

Here are some examples of documented roadmaps, which you’ll notice aren’t that fancy (and we’re fans of that!).

• Nordhealth’s Design System
• U.S. Web Design System
• Gov.UK’s Design System
• Adeo’s Design System
• Newskit – News UK’s Design System

Give creating a design system roadmap a go!

If you’ve reached the end of the article, you’re ready to create a roadmap. Hopefully, it wasn’t as intimidating as you thought! A roadmap is just a high-level plan of what will happen over the next few quarters. You’ll be more accountable for the upcoming quarters and less for the future ones. Knowing how unpredictable tech can be, chances the ideas you have for 3-4 quarters out will likely change, and that’s OK! Being agile and iterative means adapting as you get closer to crossing that bridge.

Let us know if you have any questions or used this article to help create your design system roadmap! We’d love to see your creation, especially if it’s a simple and underwhelming text page. Reach out to us on Twitter/X @zeroheight or via our Slack community, zheroes.