When you think about design systems, what comes to mind? Components? Tokens? A perfectly structured Figma library? Sure, those are part of it. But according to Dan Donald, that’s just the surface. The real challenge? People, processes, and company culture.

Dan has been working in this space for years — not because he set out to build design systems, but because he saw a communication gap between design and engineering and wanted to fix it. What started as a way to share CSS more efficiently evolved into a career dedicated to bridging silos, aligning teams, and making design systems actually work.

In this conversation, Dan talks about why selling a design system the wrong way can backfire, why operationalising design is still a huge challenge, and how AI might (eventually) change the game. Oh, and he’s also writing a book — because tackling one big design systems problem at a time clearly isn’t enough.

Let’s get into it.

1. Setting the Stage

Question:

You’ve been involved in design systems for quite a while, from hands-on work to thought leadership. How did you first get into this space, and what keeps you passionate about it?

Answer:

It felt quite organic. It didn’t start off being about design systems but a situation (that I’m sure many have come across before) where there was a gap between design and engineering, miscommunication and misunderstanding…so we just explored how we might share ‘stuff’ better. It was about bringing groups of people together and at that point the tangible outcome was sharing some basic CSS derived from a more streamlined set of design guidelines.

I think I stay passionate about it because it’s almost a microcosm of everything around making digital products. Because the artefacts are a relatively small part of design systems in reality, there’s a lot of big challenges that often need to be overcome for those things to become useful. As that’s all really about people, structures and culture, it’s different every time and fascinating.

2. Beyond the Components

Question:

Many discussions around design systems focus on the tangible artifacts — components, tokens, Figma libraries. But the real challenges often lie elsewhere. In your experience, what’s the biggest overlooked challenge teams face when adopting or scaling a design system?

Answer:

It’s not a bad thing to roll up your sleeves and start with what you know… so Figma or code and try and create something useful. The problems tend to exist outside of that and so skipping doing your homework can lead to similar challenges for people around adoption, etc. Design systems are mostly a people and process problem and for many of us that started in a role to design or write code, all of that can feel unfamiliar or daunting.

3. Strategies for Success

Question:

You’ve worked with a range of organisations, from startups to large enterprises. Have you noticed any recurring patterns in what makes a design system thrive (or struggle)?

Answer:

One that I’ve found useful is that people struggle when trying to sell-in a design system. They’ll do a great job of creating decks describing how it’d make things more consistent, scalable and all of that but it can often fall flat. I tend to say, as a way in for them, why aren’t you consistent? Why isn’t the work scalable? Flipping these proposed benefits on their head can get into the conversations about the problems that your organisation currently experiences and that’s where the root of the design system needs to be planted — by being pitched at least in part as a solution to actual pain points.

Question:

What strategies do you think teams should focus on to ensure their design system delivers long-term value?

Answer:

So, I’d say that ‘value’ means many things to many people, so what do the people that matter in your org consider to be valuable? Is it financial, is it about speed, is it about consistency of the application for brand? There’s be multiple answers to these questions but that gives you some sense of how this initiative might be viewed, so you can try to put it more in their terms.

4. Bridging the Gaps

Question:

Design systems sit at the intersection of design, development, and business. Where do you see the biggest disconnects between these groups, and how can teams bridge them?

Answer:

Fundamentally they’re all problem solving disciplines and so being respectful of what each party (and others around content, testing/QA, etc) can bring to the table gets better results. It also stops the top-down mentality that can leave many feeling disempowered or disconnected from the work. A business problem can have many responses. A design doesn’t work if it’s not feasible for engineers…and so on. We’re all connected.

5. Evolution of Design Systems

Question:

Design systems have matured significantly over the past decade. What trends or shifts do you see shaping the next evolution of design systems?

Answer:

I think we’re still struggling with the basics to be honest. People are doing great work on the craft side of things (ie, in a design tool or writing great components in code) but operationalising it remains a challenge for many organisations out there, so my hope and assumption would be that we’d lean more towards DesignOps and understand how that can be part of the equation.

Question:

With AI creeping into design tools and workflows, how do you see that impacting design systems in the future?

Answer:

At the moment, it’s kind of an interesting toy. You can get it to spit out some generic, possibly accurate documentation or do some visual stuff but that’s natural while we’re all working out what these emergent tools are capable of. I don’t think we’re there yet. I think in future, an AI that is actually intelligent over the LLMs and image generation tools we have today could be really interesting. From being part of ideation to validating a feature proposal for market fit to understanding what exists within a design system and getting basic layouts put together quickly — our roles might shift more towards what machines can’t do — generate new ideas and find unusual or innovative solutions. Until then (or they tale over the world), they can have their uses but not seen anything really compelling for design systems just yet.

6. The Personal Take

Question:

What’s a piece of advice you wish you could go back and give yourself when you first started working in design systems?

Answer:

This is going to be a very long journey! You’re going to feel out of your depth a lot, but that’s OK, because you end up growing a lot through it, so keep going and lean into it. Also, nothing is ever perfect or finished, so cut yourself some slack.

Question:

Any underrated or unconventional advice you’d give to teams building design systems today?

Answer:

Most of the time, you don’t need to talk about design systems — talk with peers in different roles with empathy and listen to their experiences of trying to get stuff done in their part of the org — then go on the design systems journey together, solving real problems.

7. On Your Book

Question:

You’re currently deep into writing a book on design systems, focusing on everything beyond the artifacts we create in Figma. Can you share a bit about what inspired you to write it and what readers can expect from it?

Answer:

I think it’s that there’s so much really great content out there around the craft of creating components to design tokens that this seemed like a real gap and not one with easy answers. My hope is that it helps people to consider their problems, their context and the shape that their design system might need to be. There’s a bunch of strategies and tools people can try out that can give them a toolkit to try and navigate this unfamiliar territory. Just need to get to the end of writing it first!