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
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
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
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
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.
Self-Service
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.
Prioritization
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.
Tracking
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.
Conclusion
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.
