Ben Callahan has spent the better part of a decade studying why some design systems thrive and others stall. The researcher and Sparkbox consultant joined the Smashing Podcast to talk through what he's found: a four-stage maturity model, the funding conversation that never really ends, and the organizational culture work that now occupies most of his attention.
From computer science to design system research
Callahan studied computer science and started out frustrated by corporate work that lacked a vision he could get behind. He left to spend roughly a year exploring animation and audio, then launched a video and audio production business. A client website turned into the thing every other customer wanted; he bought out his partner, ran a local web studio in Ohio, and merged it with others doing similar creative and technical work. That combination became Sparkbox, now about 14 years old.
His transition away from daily front-end work pushed him toward research. The appeal of design systems, he says, is that they create unity inside teams, and that has kept him pointed in this direction since clients began asking for systems about six or seven years ago. For the past five years Sparkbox has run an open industry survey, which gives him an excuse to interview people doing interesting work in the space and to look for cohesion across their accounts.
Four stages, and the hard one in the middle
Roughly two years ago, ahead of the 2021 survey release, Callahan sat with those interviews and saw patterns. The result was a deliberately practical, non-theoretical model of four stages most programs move through:
- Stage one — building version one, meaning everything up to the point where subscribers inside the organization can use something.
- Stage two — driving adoption, which almost always becomes the focus next.
- Stage three — surviving the teenage years, a period where usage grows, people attempt things you never anticipated, and the team must decide whether it is truly running a product with real support.
- Stage four — evolving a healthy product, where the system team takes on leadership inside the design organization and acts proactively: ready with a spike when a product team asks about a new framework, rather than reacting after the fact.
Most organizations Callahan encounters sit somewhere between stages two and three — and many are on their second, third, fourth or fifth attempt at the whole endeavor. The bottleneck is structural: moving past stage two requires growing the team, adding product support capacity, and bringing in somewhat different skill sets. Because the system becomes fundamental to all interface work once it takes root, subscribers need to feel the team is there for them. That costs people, and it is where things stall. Few organizations have reached the more mature stage; they exist, but they are rare.
Selling it once doesn't work
The business case for a design system is not settled, in Callahan's view. He has talked with plenty of leadership teams weighing heavy investment, and he treats the decision as genuinely open: a single product, a small team, and startup mode is a case where a full design system likely isn't worth the money, even though some shared patterns and components usually are.
Once the decision is made, leadership buy-in has to arrive at some point. Studying what he calls origin stories — how involved and supportive leadership is early on — he found systems that started with no leadership involvement at all and became successful anyway. It is a maturity transition. His method for earning that support is the same as for any product: interview the people whose backing you need, learn their goals, and shape the system's framing so it solves their problems.
Two truths help in those early conversations. First, value only appears over a long horizon, so saying that plainly upfront is useful. Second, the pitch is never finished. Callahan's model names three continuous activities — education (making the case, casting the vision, explaining why, what and how), engagement (getting people involved in the work rather than broadcasting at them), and evolution (improving the system over time). Skip any of the three and progress through the stages stops.
What the survey data says about staffing
This was the fifth year of the survey. Callahan expected respondents to name the same items as both challenges and priorities on two matched lists — his team argued otherwise, and the data proved them right.
Staffing stood out most. It registers as a major challenge but rarely as a priority, which Callahan reads as an authority problem: the design system team can name its challenges objectively but may not control how money is spent or what gets prioritized. If an organization trusts a team to run the program, he argues, it should trust that team to set its own priorities. This connects directly to the stage two-to-three wall, where the volume of work grows sharply and only leadership can authorize more people.
Engagement, common language, and the stability checklist
Asked how you know a system is on track, Callahan is candid that it's hard — early promises become the claims you're later expected to prove. But patterns show up in the survey's self-reported success data. Better engagement almost always correlates with people feeling the system is successful; you cannot build in isolation from the people who need the thing.
Education matters too, and this year he went back to basics on definitions. In several consulting engagements with large companies that had run systems for years, the teams inside didn't agree on what a system even is, why it matters, or how it should be done — eight years in. Internal alignment on a definition, whatever it is, is what counts. To help, Sparkbox laid out an "anatomy of a design system" that gives teams shared language.
“I think being intentional and thinking through the actual process that you're going to follow and being clear about what it is and how to follow it is the way that we're able to set these different disciplines up for success.”
Even healthy programs hit instability. A new director or VP who wasn't part of the journey can force the team to justify itself again, and market shifts or a rebrand can shake things loose. Having metrics ready to show rather than tell helps. Callahan's team identified three stabilizing forces worth building during the good seasons: authority (visible leadership support), value (continuously monitoring whether the system is genuinely useful, so it stays the easiest way to work), and tradition — earned over time, until "this is how we build interfaces here" becomes an anchor amid change.
Culture is the layer underneath
Callahan's newest research looks at organizational culture. Any group of people who meet consistently forms a culture, so large organizations contain a central culture plus countless subcultures — the team you work with daily, the lunchtime knitting group on Zoom, the science fiction book club. A design system team is one such subculture, and it doesn't get to choose the surrounding one.
He borrows the competing values framework, developed in the early 1990s, which plots two spectrums to yield four general culture types. Almost every design system team he interviews lands on the internally oriented side: collaborative ("everyone come help build something we all use") or controlling (the system enforces consistent output and you don't stray). The other two types are externally oriented — competitive, driven by the market, and entrepreneurial, or creative, aimed at disruption. Some of these cultures pair well; others don't. The practical work is curating the design system team's own culture so it functions inside the larger organization's. Callahan plans a book covering the anatomy of a system, how systems mature, and culture's effect on system teams, with a draft targeted for this year.
Starting an engagement
At Sparkbox, the opening phase is called onboarding, and it leans into the fact that you know the least at the start. The work is iterative, and much of it is relationship building: asking to meet many people, even those the team won't work with daily, to learn what they deal with, how they get through their tasks, and what they want. A short internal survey and three to five interviews per discipline are typical. Callahan deliberately reaches beyond designers and developers to QA, product owners, and UX researchers — a pet peeve of his is how narrowly design system benefits get framed. Modeling this for clients demonstrates that design system work depends on truly understanding subscribers.
On the handoff question, he sits firmly in the iterative camp and talks with his team about empathy — not for end users, but for the other disciplines alongside them. Every line of code touches the visual layer and the end experience; all decisions interlock. Building those relationships is how the work improves, and it's part of why design systems appeal to him: they put everyone on one team aimed at serving the customer.
Tools, trust and the sync problem
Tools will not save us, Callahan argues, despite heavy innovation in the market — though that innovation is needed and tools should of course be used. In Sparkbox's anatomy model, each layer of a system has three parts: assets (files, React components, Figma designs), documentation (an insightful explanation of what a component or token is and why it is the way it is), and process. Intentional, explicit process is what sets different disciplines up to succeed.
A frequent failure mode illustrates the point: a designer and developer work from different versions of the same component, so the final output doesn't match the design. The cost is rework, and it destroys trust in the system. Two remedies — define a process that keeps artifacts in sync, and provide transparency about the current state of each piece. With transparency, a developer who knows something isn't in sync can choose to wait or to help create the synchronization, rather than expecting perfection and being burned by it. The balance is process plus whatever the tooling automates, and manual process where it doesn't.
Impact over logos, and what's next
Callahan's dream project isn't about brand size. Big-name work is fun for family conversations, but what drives him is impact: helping organizations build unity on their teams, and writing a book that helps people make better daily decisions. He also enjoys teaching and expects to find a way to give back in that form eventually. Beyond work, he's goofing around with code alongside his son, who is at a camp learning to build VR games — his computer science background gets put to use — and tinkering with new coffee equipment. Ask for parting words, and he points to the second draft of the design tokens spec, where feedback is needed from anyone working in that space.
