System quality doesn't predict whether a team uses it
If you've ever spent even the smallest amount of time with me, you wouldn't be surprised that I'm always the person on our team advocating for some design system, not because every initiative or product needs a meticulously documented component library, and definitely not because I want the team constantly tending to the library like it's our perfect rock garden. It's because good system design can change a lot more than the interface or the experience. And I've seen it happen enough times now to trust the pattern.
I've seen the other side, too. There were times when we built systems that were thorough, thoughtfully planned, and documented down to the last detail—but people just didn't use them. At the same time, some of our smaller or mid-sized systems caught on quickly and changed the way our teams worked together. The real difference wasn't the quality of the library itself, but how people in the organization perceived it.
This is the whole thing: design systems don't scale products. Individuals do. People do. Teams do, which means that sometimes the system we're building, the system that we're shepherding into existence, isn't just a component library; it's a vehicle to create organizational change.
The obvious win isn't always the thing we shipped
One of our most successful systems started the way most do, alongside a project engagement with a digital experience to design and requirements to solve. We built the system underneath at the same time, which ultimately changed what our teams could do next. It's the familiar pattern that agencies see frequently: the train is already moving, but we still need a few more cars, and oh maybe a different engine as well. Instead of creating static designs and hoping they'd stay the same, we jumped between Figma and the CMS, using patterns we already knew worked. This let us try out different ideas and patterns, test things early, and move the right things into production without having to start from scratch each time. Since what we designed lined up exactly with what we built, turning an idea into something real became much faster.
But something else happened that hit a bit differently. Teams across the org were building for many surfaces—web, print, social, email—and historically each team had been making decisions in its own lane, disconnected from the others. The system gave them a shared language, not identical outputs, not a mandate that everything looks exactly the same across applications, but a common foundation that could flex or shift so that each team could build in ways appropriate to their artifacts.
We made the thing we were there to make. But the empowered outcome was a new way for the org to make a lot of things without us. That's a very different definition of what success can mean. And I kinda love it.
A more complex library doesn't guarantee a bigger impact
When adoption stalls out, our instinct is to treat it as a design problem. Maybe the documentation needs work. Maybe it needs to be easier to find things; perhaps the tooling is wrong, or maybe the team doesn't know how to contribute meaningfully. These are reasonable hypotheses. We've tried versions of all of them. But there's a point past which adding another tool, integration, or workflow no longer solves the underlying problem, because the problem was never the system itself. You can't design a way around an org or culture that doesn't want to work that way, and that's not a criticism of the organization. Sometimes the way a team wants to interact with the system just isn't how the broader org operates. Sometimes the tools people actually reach for are just different. Sometimes another source of truth creates more friction than it removes. At that point, the job isn't to keep selling everyone on your preferred version of the system—it's to listen and ultimately build something that does encourage adoption.
Tool agnosticism is part of systems thinking
Where a system lives matters less than whether people are actually using it. I love Figma. And Figma can be the right answer. So can code, or documentation that sits close to engineering. This especially makes a ton of sense as designers move more toward engineering, which means that engineers also need to move a bit more toward design. AI is opening up entirely different ways for us to query and interact with a design system without requiring everyone to work inside the same interface. The tool isn't the system—and that distinction matters especially for design teams, because we naturally build in the environments we work in. We see friction or frustration when no one wants to visit us there. In thinking about adoption, we have to understand where the rest of the organization is coming from, too. The real challenge is finding a model that gives different teams access to the same underlying decisions without creating five sources of truth that the team has to keep synchronized forever.
Adoption oftentimes sits with leadership
Organizations take their cues from leadership. Teams notice what their leaders use, prioritize, ask for, and reward, and they notice what leaders are willing to make part of how work actually gets done. An outside team can build an exceptional system, make the case for it, and meet the people where they work, but we can't manufacture commitment that has to come from inside the organization.
This is true across the board with the orgs we work with—ourselves included. The ask is never: show up with The Correct Way to Do Design Systems™ and convince everyone to do it our way. It's to understand how the organization actually operates, build something useful inside that reality, advocate for the practices we believe improve the work, and give people the tools and ability to carry it forward themselves. Sometimes that sticks immediately; sometimes it takes longer than we think. Either way, it teaches us something about how to show up better the next time.
The system handles the repeatable. People handle the ideas.
This is ultimately why I will always be such an advocate for design systems. Teams shouldn't have to spend their best thinking on solving the same problems or manually updating a color across countless surfaces. A good system takes care of the decisions we've already made, so people can spend more time on the ones we haven't. And when something proves useful enough to repeat, it's the people who decide whether it belongs in the system. That's the loop. Not components for the sake of components. Not documentation for the sake of documentation. Not governance for the sake of controlling every little thing. It's creating that living, ever-evolving agreement about how we make things together.
It's the people, dammit.
This might be the biggest recurring theme in my career journey, and a set of client interviews made it impossible to ignore. A while back, a colleague and I sat down with a cross-section of our clients and asked plainly why they'd chosen to work with us—or kept choosing to work with us, engagement after engagement. We thought we'd get answers about process, craft, and the deliverables themselves. Instead, many conversations landed in the same place: it was the people. They wanted to be in the room with our specific set of humans. They wanted to solve these hard problems together.
That answer has hung out in my brain ever since because it applies just as much to systems design as to the relationship itself. A system is infrastructure—a piece of the org's broader design. It's real, and it matters. I will continue to be its biggest fan and advocate. But infrastructure doesn't decide to use itself, extend itself thoughtfully, or fight for itself when a deadline makes it tempting to make short-term decisions. People do that. Systems don't survive because they're well-documented. They survive because a group of people decided they were worth maintaining, together.
The most meaningful measures of our systems don't live in Figma, in the .md file, or in a repo. They live in whether people actually use the thing. So instead of focusing on components, here's what I actually think about:
- Can teams experiment without waiting weeks for an idea to become real?
- Can designers and engineers work from the same underlying principles?
- Can different parts of the org create for different audiences while still speaking the same brand and product language?
- Do people know where to go when the existing system doesn't solve the problem?
- Can the org maintain and evolve the system after the people who built it are no longer attached to it?
These questions tell me a lot more than any component or token could. A design system isn't just infrastructure—it's organizational design in the broadest sense: how a group of people decides to build together, and keeps deciding it.
If you're thinking through whether your organization is ready for a design system, or why one you already have isn't getting used, we'd welcome the conversation.