How long should a design system take?

A month? Five sprints? A quarter? A year… or years?! “It depends!” of course! But maybe your colleagues and stakeholders have a calendar pulled up and are looking for concrete answers for how long your design system will take. 

I know what it’s like to feel trapped into answering, and I’ve foolishly committed to some unrealistic deadlines. So, based on lessons learned from my own experiences and from working with other design teams through zeroheight, we’ll unpack what “it depends” really means. We’ll create a more tangible picture of what that means so you can better understand what a realistic timeline looks like for your design system.

Contributing factors to a design system timeline

Before estimating the time it would take to create a design system, we need to determine what contributes to that timeline. (Spoiler alert: some things aren’t that obvious.)

Basic factors

Some of the more apparent things include:

• Creating the UI library for the design tool
• Coding the UI libraries for the developer tools
• Writing the documentation to support how to use the design system

Most seasoned teams can accurately guess how long some of these tasks will take since it’s very similar to what designers, developers, and writers do daily.

Natural scope expansion

However, what if the design system’s scope includes multiple products, more than one theme, additional brands, and numerous devices like Web, Android, iOS, and TV? This can easily extend the timeline for the design system—by a lot!

Adding more people

On top of that, stakeholders can add pressure to get the design system done “sooner than later.” So, some of your stakeholders (and even you) might consider negotiating for more people to help. Sure, to some extent, the more help, the easier it can be, but that’s not always the case with design systems. When creating design systems, you hit a level of diminishing returns at some point. I’ve had ample people to help on past teams, and we still hit a wall.

What really affects a design system’s timeline

The wall that teams typically hit, regardless of their size, is the decision-making wall. Countless design and dev decisions must be made, especially when aiming to create something universally usable at your company. 

When building a design system, you’re not only deciding what components go in it. If you’re a designer, you’re thinking, “Does the component have a border? How thick is the border? What color is it? Does the border disappear or change color on hover?” And if you’re a developer, you’re thinking about how to implement this, how to make it accessible, and what potential risks there are with your different options. There are so many questions to be answered when vetting a component.

Decision fatigue is very real with design systems. Especially when you’re starting, your team might have to make numerous decisions in quick succession until the team finds its stride. To make things worse, the more people you have, the harder deciding becomes. I love this illustration from Kevin Hoffman’s book Meeting Design, which shows how chaotic an agreement can be as more people participate. With three people, you only need three points of agreement. With 7, there are 21 points of agreement, and with 12, there are 66 points of agreement!

If you’re a team of 7 and you have to decide 5 things about a button component, that means 105 points of agreement! Yikes!!

Even if you’re a design system team of one or two and the design system is your only focus, there’s still decision fatigue. It can take a while to learn all the products at the org, what’s included in their UI, and how things are implemented—all in addition to deciding what would be best for the design system.

A design system is never done

You might hear someone say, “A design system is never done,” which I agree with, but it’s not something your manager wants to hear when they’re reviewing a timeline. In the broadest sense, a design system is never done. We’ll always be iterating on components, adding new patterns, etc.

But more realistically, other factors can easily throw wrenches into your plans and extend the timeline. Some of these include (and are definitely not limited to):

• Design tool transitions—Sketch to Figma
• Codebase transitions—Angular to React
• Accessibility requirements—”We’ve been sued; everything needs to be accessible!”
• Mergers or acquisitions—”We’ve been acquired; align our products with the flagship company!”
• Company reorgs—”Now include these five products in your design system!”
• Brand refreshes or redesigns—”We’re keeping up with new trends!”

In a previous role, the design system never seemed to reach a point of completion. Just as we survived one hurdle, we hit another. It’s not all bad; some were by choice (e.g., when we wanted to use Figma and zeroheight). However, because the design system is global infrastructure, factors within and out of your control will extend the timeline.

Design systems are anchors of stability

Earlier this year, I hosted a webinar with Geri Reid and PJ Onori about design system trends with people and teams. PJ mentioned that design systems are meant to provide stability. I never thought of it that way, but it resonated so strongly with me. You’ll hear me say design systems are infrastructure, so we shouldn’t rush them. Would you want to rush the electricians wiring your house? Probably not. 

So, with design systems, you’re aiming to create and demonstrate stability, which means the timeline will be slower. Consider how old Material Design is (It’s 10!) and how it’s slowly evolved; see—stability.

So, really, how long should your design system take?

There’s a lot to consider and I didn’t provide any semblance of a timeline. However, now that we know what contributes to a design system’s timeframe, how a design system is never done, and how we should try to provide stability, we have some tools to work with.

Set expectations

First, start setting expectations that design systems are never done and that they are anchors of stability. Not everyone may be as familiar with design systems and what’s realistic, so getting on the same page is helpful. Even if they might be familiar with design systems from their previous experiences, setting expectations specifically for this design system and org is always beneficial. 

Think in milestones

Next, instead of thinking about the holistic completion of your design system, think about milestones. Milestones are specific points of progress that take you to the end goal (figuratively speaking, the “completion” of your design system). They’re much smaller, more tangible, and easier to scope out realistically. All the factors, like multiple endpoints and all the wrenches mentioned above, can be milestones or even broken down into smaller milestones.

For example, rather than supporting code libraries for Web, Android, and iOS simultaneously, you can decide to work on Web first, then Android, then iOS. If you’re transitioning tools, maybe you’re pausing on creating new components so you can create the existing components in the new tool.

Use roadmaps for planning

It’s compelling to get everything done all at once, but it doesn’t have to be done this way. To help with planning, consider creating a design system roadmap. Your colleagues and stakeholders will understand this kind of thinking, which can help set priorities and build empathy.

Aim for stability

Setting expectations and creating a roadmap with milestones foundationally builds some stability for your design system. However, there are additional ways to create stability.

Critically think about solutions through the lens of stability. For example, adding more people to hurry and finish things is probably not a great idea. Also, avoid taking shortcuts or trimming timelines. There are often more questions to answer with a design system component than with designing a flow, so the more time (within reason) you can have, the better.

Check the team’s level of decision fatigue. You definitely don’t want to burn your team out, so pay attention to the warning signs.

Evolve past scrappiness. It’s common for design systems to start pretty scrappy and grassroots, but if this is the tone set for the team for every redesign, tool change, or company re-org, it’s not sustainable. Start having those conversations with your stakeholders on evolving past it.

Reach out to the community

While you may feel like you’re the only one experiencing these challenges, you’re definitely not! We have plenty of resources around design systems in general, webinars and events that address common issues, and a Slack community who can provide advice and guidance on their past experiences.