Everyone plans for how difficult it is to build a design system that scales. Almost nobody plans for how hard it is to get people to use one.
Two Starting Points, One Solution
Almost every organization we work with starts from one of two places.
The first is a system that has stalled. It was funded and staffed. The components shipped, the documentation went up, and then product teams kept building one-off solutions anyway. The system turned into an expense with no return and a source of frustration for everyone who hoped it would be more.
The second is an organization with a system that hasn’t “officially” started yet. There’s some interest, a rough sense of scope, and usually a designer or an engineer who has been building a system for a while without anyone in leadership knowing. They want to get it right the first time.
These sound like opposites, but they’re really asking the same question: How can we ensure this system will be used?
In our experience, the answer comes down to three factors every time:
The system must fit the organization.
The system must fit the products it has to serve.
The team must be equipped to sustain the system.
Tackling those three factors is the critical work, and it’s what we do. Sparkbox creates design systems that get used. We work with large organizations to build the system and the team to sustain it.
Delivered Is Hard. Used Is Harder.
Designing a component library that holds up across a large product portfolio is difficult, technically demanding work. Getting the token architecture right. Resolving accessibility properly instead of nominally. Making decisions that won’t have to be unwound in eighteen months. Writing documentation that someone will actually read and that AI can leverage. Most organizations that try this never finish, but those who do have built something with the potential to add real value.
Delivered is an achievement, but it’s not enough.
A technically excellent system that doesn’t align with its organization, products, and team will sit unused while the company that built it wonders what went wrong.
A system that fits these three things perfectly but is poorly built will get launched, and then resented. It will never be able to provide the value that has been promised to the organization.
Both of these mistakes cost twice: once to build the system nobody used, and again to build the one that has to replace it. And then there is the loss of trust. Trust is built little by little, but can be lost in a moment. Each time a system fails makes it harder to trust that the next time will be different.
So when we say a system has to get used, we’re setting the bar to demand both technical excellence AND a good fit. That’s when it gets used, and that’s when it succeeds.
Thinking systematically about how digital experiences get created and maintained is the best way to bring value, consistency, and efficiency to your products.
There Is No Good Design System in the Abstract
There is only a system that fits this organization, these products, and this team. That’s why our work starts and ends with those three factors.
The Organization
Before we begin, we need to know how the company actually works. How do decisions get made, and by whom? Who is sponsoring the system, and how is their success defined? Where does the funding come from, and how long does it last? How do teams communicate?
We need to understand the organization’s structure, funding model, communication, and culture.
All of this changes our work in concrete ways. An organization where one VP can mandate adoption needs a different system (and a very different rollout!) than a federated one where a dozen product teams have their own roadmaps. The first can afford to be opinionated early. The second has to earn its way in, little by little, with governance that makes contributing genuinely easy rather than theoretically possible. The components might end up looking similar, but the engagement is completely different.
There is no one set way to roll out these changes, only ones that fit the organization. How much documentation is the right amount depends on how this organization learns. How strict the contribution model should be depends on how much review capacity actually exists. How fast to move depends on whether the sponsor has twelve months of political cover or four.
The System and the Products
Most organizations have at least the seeds (or sometimes the remnants) of a design system. Grassroots efforts in disparate corners of the company. A sanctioned system that was funded and staffed but never took off. Patterns inside a single product team that could have become a system but never spread.
We start with what’s there. We look at the tooling across design and engineering, the taxonomy and information architecture (or the absence of one), and the technology and design decisions that have already been made. A design system exists to serve product teams, not the other way around, so we need to understand which products will consume it, how they’re built, what constraints they carry, and which of them have deadlines that make adoption harder than the efficiency it brings. All of that helps determine whether the system gets used.
Sometimes the right answer is a small, well-built system that covers the basics everyone actually uses. Sometimes it’s a migration path that lets a team adopt in pieces instead of all at once. Sometimes the most valuable thing we can do is fix the documentation so everything after it gets easier. Understanding how the system aligns with the products it serves is a critical part of whether it succeeds.
The Team
A design system is only as durable as the team behind it, and the design system team is a moving target. The people you need today probably aren’t the people you need two years from now, as the system matures and the skills it demands shift.
Do the people responsible for the system have the authority to make decisions about it? Responsibility without authority is the most common arrangement, and can be the most damaging. How big is the design system team, and how big does it need to be, now and in the future? What skills are there, and which ones are missing? How ready are the contributors on the product teams, and how comfortable is everyone with the tools, including the AI tools?
A design system built to be supported by a team of six doesn’t help a two-person team. It buries them. Most systems don’t come with unlimited team members, just like they don’t come with unlimited funding, so we build for the team that will realistically own the system. That constraint ensures the work is not just great, but appropriate. Systems built to be maintained by their actual owners end up simpler, better documented, and more durable than systems that try to do too much.
Never the Same System Twice
We’ve never built the same system twice. We bring strong opinions, proven practices, and years of pattern recognition into every engagement, but each system we build is unique because each one has to fit an organization, a set of products, and a team that exists nowhere else.
The value we create for our clients is always different based on their needs and unique circumstances. That has been at the heart of Sparkbox since the beginning. It’s what brought me and my co-founders together over 17 years ago, and it’s the same belief that shapes every system we build today. Thinking systematically about how digital experiences get created and maintained is the best way to bring value, consistency, and efficiency to your products.
