We stand with Ukraine and our team members from Ukraine.

The Community Of Over 578,000

Home ›› Customer Experience ›› Scaling Your Design System

Scaling Your Design System

by Tony Walt
Share this post on


Scaling a design system

When scaling a design system, it’s necessary to consider the goals of your system, architect it for scaling, and strategically determine when and how you want to grow. Read the guide for your system scaling.

Growing Pains

You convinced your leadership to build a design system and you’ve got many of the basics in place, including: principles, voice and tone guidelines, design assets, and a code library. Now you’re looking for opportunities to grow. The world is your oyster, and the system has so much potential. The directions you can take are limitless.

Except there really is a finite amount your system can grow, and the directions are in fact prescriptive to how your system will grow, and what it can do. Everything you add to your system will increase its carrying cost, and your company will have a limit to the time and resources that can be committed to the effort. Therefore, it’s important to think about what direction in which you take the system to get the most value from it.

I’ve observed many systems (including our own) go through growing pains, and I encourage you to think strategically about that growth to avoid feeling the same strain.

Many articles about measuring the value of a design system suggest using the number of times a component appears in production to demonstrate the value of the system, and teams race to grow and provide those numbers. I’d caution teams from focusing too heavily on this metric, unless it supports a more comprehensive strategy.

Systems that grow too large too fast risk becoming unsustainable. Their resources get spread too thin, overwhelmed by unplanned work, and they can neither advance the system nor support existing consumers. This erodes trust and could eventually destroy the system.

Work Smarter, Not Harder

Scaling your design system. Work smarter, not Harder.

Rather than haphazardly racing for scale, you should instead plan what kind of system you want to build and determine how to best get there in a sustainable way. This includes answering questions like the following:

What needs will the system fill? How large should it become?
How fast should it grow?
How flexible should it be?
What kind of shape should it take?

The answers to these questions will impact what kind of system you make, and the trajectory you take to get there. They will also change over time as your system matures, so revisit them often. Each question probably deserves its own in-depth article, but for now I’ll focus on how they impact your ability to support the system, as I see that as being an often overlooked consideration.

As your system grows, so will the support load you must provide to run it. This support load will displace planned work, and could eventually become the dominant form of work in the system. That’s an acceptable outcome if it’s something you’ve planned for and your team can sustain it. As our system has matured, we’ve moved in this direction by shifting into a more involved consultative role with our consumers.

Flexibility of Your System

When scaling a design system, it's important to take into account the flexibility of your system.

The flexibility of your system will reside somewhere on a spectrum of opinionated to loose. On the strongly opinionated end, the system specifications are strongly enforced and deviation isn’t allowed. On the extremely loose end, the system serves as a starting point and users can make adjustments as they see fit. Different aspects of your system may also reside at different points on the spectrum.

How flexible you make the system will depend on the value you’re trying to get from it. Do you want all of your products to look and feel exactly alike, or do you prefer a cohesive design in which products feel similar but have room for some differentiation? Your decisions here will impact how wide you scale the system and will drive different types of support. The tighter the scope of your products, the more likely you’ll favor a stronger opinion.

Strongly Opinionated

The more opinionated your system is, the more consistent all of your products will be. The quality of your products will match that of your system; so hopefully you’ve

invested to build a strong and mature system. Users will inherit your best-practice decisions and be free to focus on other challenges unique to their application. Support should also be very straightforward, as everything is built on the same foundation.

The scope of your system will be limited to families of products in which it makes sense to adhere to your guardrails. As you approach the boundaries of that scope, you may find that designers feel restricted by the system, and some deviation may be warranted due to unique product or brand requirements. Users would need to request for you to adjust the system, and your team could become a bottleneck.

If your team becomes a blocker for feature teams, they will find their own workaround, and these unknown hacks will make future system migrations much harder. Your team may find itself policing usage of the system, and that could lead to both resentment from consumers and more unplanned work for your team.

Loosely Opinionated

The looser your system is the wider it can grow, the more situations it’ll apply to, and the better it’ll be able to evolve by ingesting favorable deviations from your users. Those users will enjoy the benefit of a fast start from the system while also having the freedom to adjust it to their custom needs. You won’t field as much support centered around adjusting the system to custom use cases.

However, if your system doesn’t have any strong opinions, you risk a significant amount of deviation among your consumers, and cohesion could completely break down as a result. You’ll need to clearly document where the system is strict and where it’s flexible. You’ll also need to be extremely clear about what your team is willing to support, or you’ll find yourself on the hook for every deviation from the system that went awry. The further those deviations are, the harder it will be for you to support them and the harder system migrations will become.

Somewhere In-Between

Hopefully you can see that neither extreme of the spectrum is desirable, and you’ll want different parts of your system residing on different parts of the continuum.

We started with a very strict system focused on a small family of applications, and in that setting, a more consistent experience was preferred.

As our consumer base has grown, we’ve needed to accommodate different brand identities and application types. Our system has remained strongly opinionated about some aspects, like component behavior and accessibility, but we allow for intentional and systematic deviations in some aspects of design.

We accomplished this through brand- and application-level token overrides that we can programmatically track and analyze. This way, we can see how design decisions vary over time and across our consumers. This also shows us where we should evolve the system based on that data.

Shaping Your System

While scaling a design system, its shaping should be taken into account.

There are two primary ways in which your system can grow. It can get wider by adding more consumers or deeper by adding more to the system. Both methods add value in different ways, but they also come with unique challenges. These growth strategies are not mutually exclusive, and how you prioritize them will shift over time.

Wide Systems

A system scales wider by increasing the number of consumers and products using it. This leads to more cohesive experiences across more applications, at least at a higher level. A system like this also tends to benefit more from efficiencies of scale and a broader scope of usage.

As a system gets wider, the larger consumer base leads to more support issues due to its increased size and scope. More people have to learn the same materials to apply and use the system. More context leads to components being used in a variety of potentially unforeseen ways. It also becomes less obvious which support issues should have priority, because they are being surfaced from many different sources.

Deep Systems

A system scales deeper by adding to the elements contained within it. This includes things like additional components, patterns, tools, and libraries. Usage of the system becomes stickier and more comprehensive due to how much it offers.

As a system gets deeper, it becomes more complex, both in its composition and the support it requires. Issues can be harder to identify and fix due to the increased number of elements, their connection points, and more complex integrations.

Every time an element is added to the system, you must support that individual element, as well as every connection point between that element and every other element it interacts with in the system. This introduces exponential growth of possible points of failure.

Planning for Support

Scaling Your Design System. Planning for Support

Regardless of how you grow it, your system will require more support as it scales, and you’ll approach the limits of your resources. You’ll need to balance unplanned support and planned work to get the most efficient use out of your team.

A few methods to achieve this include focusing on self-service support, determining how to prioritize your support load, and tracking your unplanned work. I’ll cover these briefly here and address each of them in more detail in my next article.


Enabling self-service support allows you to scale your support offering by providing resources and channels that let consumers support themselves and each other. The effects of which are especially evident the wider your system gets.

A few things our system has done to promote self-service include: documentation, community messaging channels, and a support hub.


As your system gets large enough, there will be times in which you have more support load than you have staff to address it. This can be further complicated by a wide system in which issues come from multiple sources.

At these times, a priority queue system is useful. This allows you to quickly ingest and prioritize issues while minimizing the impact on planned work. I think of a queue system similar to the process of patients entering a hospital emergency room, albeit I know some people have strong opinions about the effectiveness of that process.

In a priority queue items can come from multiple places, but they must be enqueued through a single function. During the enqueue, the item is given a priority weight through a standard set of rules. Work on the queue is then processed from front to back. Finally, once complete the work is tracked for future optimizations to the system or process.


By measuring your support issues and surfacing them in a dashboard, you can determine where and how you need to advance the system. You can begin to predict when there may be surges in unplanned work and how big they may be. You can also use the data to refine your system’s growth strategy. This may include adding resources to the team, and deciding where they’d make the most impact.


Your team may start small and need to prove its worth, but be careful about pursuing growth too broadly and quickly. That growth will come with an additional support load, and you may find your limited resources overwhelmed.

It’s better to consider the goals of your system, architect it for scaling, and strategically determine when and how you want to grow. Those answers will change as your system matures, so revisit your strategy on a regular basis.

When I began managing our system, it was already quite deep, but its architecture prevented it from scaling gracefully. There were limits to how wide the system could grow, and unplanned work displaced meaningful planned work in the areas the system needed it most. Much of this was due to the decentralized nature in which our system evolved, as well as metrics driving strategy instead of the inverse.

We stopped pursuing system growth, cut back on some of that depth, aligned on strategies that addressed our scaling issues, and went to work fixing our architecture. We knew that growth would continue to occur, but hopefully at a manageable pace that would allow us to focus on the necessary planned work.

Once complete, our system grew broadly at an astounding rate; yet surprisingly, our unplanned workload is significantly smaller than before. That said, I expect it to grow as our new consumers further migrate onto the system.

There will be a natural limit to the size of your system and team. Take that into account as you make decisions, and implement strategies that will maximize your resources.

Our system is still growing—and we can accommodate that growth because we’ve asked the right questions and taken the right actions to pursue that growth strategically.

post authorTony Walt

Tony Walt, I’m a craftsman, working at the intersection of design and technology. I aspire to create meaningful experiences that are beautiful from the interface to the code that powers them. I lead value-driven teams that are passionate about their work and each other. I encourage alternate perspectives and iterations in pursuit of a stronger solution. My experience includes working in 3D, motion design, photography, design systems, software development, speech recognition, and eye-tracking interfaces. I currently lead the team building an accessible multi-platform design system serving all of Spectrum’s products.

Ideas In Brief
  • It’s important to think about what direction in which you take the system in order to get the most value from it.
  • Tony Walt, Senior Director leading Spectrum’s Design System, shares his perspective on scaling a design system:
    • Work smarter, nor harder — plan what kind of system you want to build and determine how to best get there in a sustainable way.
    • Flexibility of The System — look at a spectrum of flexibility from opinionated to loose.
    • Shaping Your System — there are two primary ways in which your system can grow, it can get wider by adding more consumers or deeper by adding more to the system.
    • Planning for Support — focus on self-service support, determine how to prioritize your support load, and track your unplanned work.
  • It’s necessary to consider the goals of your system, architect it for scaling, and strategically determine when and how you want to grow.

Related Articles

The overview of current challenges and opportunities design faces and how BBC team can help designers out to enhance digital experience and understanding of the world.

The Evolution of Experience Design
  • Dan Ramadan, Creative Director for UX Architecture & Content Design at BBC, tells about the current challenges and opportunities design faces by describing 3 stages of ‘the web’:
    • Challenges of the past (document retrieval)
    • Challenges of the present (control and contribution)
    • Challenges of the future (pervasive and ubiquitous)
  • Technology is as capable of solving problems as it is of creating them.
  • The team at BBC can explore how digital experience can enhance our understanding of the world, develop empathy for others, instill pride and commitment to the importance of the individual and the inherent value of shared values and cooperative society.
Share:The Evolution of Experience Design
5 min read

As organizations grow in their conversational maturity, there’s an increasing demand for conversation designers. Explore 7 skills to learn for conversation designers in 2022.


7 new skills to learn for conversation designers in 2022
  • Conversational design requires far more than having got all your convo design courses nailed, completed all the challenges on VUI-challenge and finished re-reading Pearl, Evanhoe & Deibel and Cohen, Giangola & Balogh for the umptieth time.
  • There is a number of new skills that can up your career as a conversation designer:
    • NLU
    • Entities
    • Entities on steroids: ontologies and graphs
    • Building conversational teams
    • Open source movement
    • Mastering conversational AI platforms
  • It’s time for conversation designers to develop t-shaped profile: specialize in one or two particular conversation design skills and systems , and mastering skills that allow us to connect with people from neighbouring disciplines.
Share:7 new skills to learn for conversation designers in 2022
7 min read
7 new skills to learn for conversation designers in 2022

There are different ways participatory design can influence young people with cognitive disability. Read reflections on co-design methodology and ways it can help.

Reflections: Co-Designing with Young People with Cognitive Disability
  • In this article, Jax Wechsler, Principal Designer at Sticky Design Studio, shares:
    • Facts about Young People with a cognitive disability that may be useful when working with this group
    • Discussion and reflections about her methodological choices
  • Things to know about Young People with cognitive disabilities:
    • Ability levels can be very nuanced, every Young Person is different
    • Life Tasting not Life Wasting!
    • The level of advocacy of parents impacts experiences and opportunities for Young People with Cognitive Disabilities
    • Social inclusion and relationships are keys to wellbeing
  • Reflections on Co-Design Methodology:
    • Recruitment is hard!
    • Using referrals and ‘snowball sampling’
    • It’s important to build rapport
    • Understanding ability and research design
    • Cultural probes/diary studies are gold
    • Parents mediating participation
    • Flexibility is key
    • Value in participation
Share:Reflections: Co-Designing with Young People with Cognitive Disability
10 min read
Reflections : Co-Designing with Young People with Cognitive Disability

This website uses cookies to ensure you get the best experience on our website. Check our privacy policy and