Dan
Donald
Design Systems Consultant
Dan is a Design System Consultant, drawing on his experience at zeroheight and Auto Trader in the UK, looking after the design system and helping to improve the consumer experience there. He worked at McCann and the BBC, at web agencies, and as a freelancer. From making his first site in ‘97 to now, he’s always passionate about using the web to improve things for people and often awkwardly straddles the worlds of development and design to try and help solve problems. He publishes articles, talks at many events, and co-organizes UpFront Conf. Outside of work, there’s noise to be made as These Dead Machines.
Can you walk me through the current state of the design system you're involved with?
I’m currently working with Bupa in the UK on their design system as a Product Owner. They’d started this iteration of their design system off the back of a native app migration project, which felt like a great opportunity to get some solid foundations in place. Before I came on board, they’d done some great work with their design partners at Frog to do some research and set them up for success.
We’ve been working on consolidating various component libraries and so exploring headless components and more advanced token structures to enable that migration to something more simple but more powerful.
What was the journey like getting to this point?
From my point of view, it was interesting coming in after the initial phase of work while the app migration project was in flight and setting a future direction for it. There had been a previous version of a design system, which meant the team was pretty much on board with the concept. There’s been a mix of finding bits of work that have happened organically across the business to bring into the docs, expand, and improve the components, but also a lot of education and awareness more broadly across disciplines.
Everyone has been supportive and engaged with the whole project, which makes everything else possible. With the headless design system and token work, we’re getting to an exciting space and looking at migration to the outcome of that work and taking people on the journey.
What tools do you use to build and maintain your design system?
We use zeroheight for the docs (they’d already selected this before I joined, so no bias from me!). So far, it’s just syncing with Figma, but we’re exploring what code we might be able to pull in from across the business. There’s certainly loads more to explore!
Figma
Zeroheight
How do you balance the need for consistency with the desire for creative freedom among your designers?
I’m a believer that design systems should empower designers and developers. Both disciplines are problem solvers, so I’d encourage them to solve user and business problems in the right way for their users and use as much of the design system as makes sense.
Being slavish to a system implies there’s no experimentation or pushing things forward, so there has to be a balance between that and adherence to the guidance and artifacts from the design system. That balance will differ between organizations and products but needs to be called out.
How do you stay true to your vision for the design system, even when faced with external pressures or trends (criticism or pushback against your design system)?
Having a vision is important for a design system to rally people around a direction or strategy. Being too robust with it fails to recognise realities around this work - we need to create something that empowers others and solves some of the problems the organisation has. This means we need a degree of pragmatism to understand that value can mean many things to many people, so being dogmatic about ‘best practice’ can be really unhelpful. Having a ‘perfect’ system is not the goal here, and that can be a massive distraction!
How does your team collaborate on the design system? How do you ensure that your design system evolves with the changing needs of your users and stakeholders?
The key for me is feedback loops. Broadcasting about what’s happening, changes made, and education are all important, but equally so is ensuring you really listen. Give people different opportunities to input or critique. Show you’ve listened and when there are outcomes based on feedback, highlight where it came from. When discussing your design system, try to embed concepts; it’s never finished, it should evolve over time, and we’ll always learn and want to improve.
Are you tracking your design system? If you had to choose one metric to measure the success of your design system, what would it be and why?
I’ve yet to see something that feels satisfying for metrics or tracking of a design system (though a big shout to Luro in that space). The success of the design system is often the success of the people who consume or use it in their work.
If you think about one of those common benefits of a DS making teams more efficient: unless you already have benchmark data about how every team works, hard numbers to back up a notion of efficiency are pretty dodgy. Having more qual data here often feels better than micromanaging.
Considering consistency, people would often cite another big benefit: how could that be measured? “Yeah, this graph shows that we’re now 191% more consistent” doesn’t sit right with me. It’s also a harder issue to get buy-in with as that can be seen as designers being fussy (not the case!).
You can track the usage of components, and there are many good reasons for that, but not necessarily core metrics to define success. It’s useful to work out well-used components and those that aren’t used at all (which should be a prompt for a conversation around deprecation). Perhaps you could work out which teams are using which components. I’m unconvinced, as a broad metric, how much value that has. It greatly depends on what each team is working on and what constraints whether numbers around that tell us a useful story.
If you could go back and change one decision you made in your design system journey, what would it be and why? How would that affect your design system journey?
Oooh good question! I’m not sure of one that stands out. All our successes and failures get us to where we are. Sometimes, it might’ve been nicer for the penny to drop about a particular topic a little earlier!
Do you use any kind of automation or AI tools?
At the moment, no more than the triggering of builds on pipelines. There’s bound to be a space for AI-related tools, but I’d still urge people to solve their problems in ways that make sense for them. You might have little documentation or what you consider to be incomplete tokens or components but built on your needs over generating a bunch of things you might not need.
I think automation feels more interesting to me as it can improve manual tasks and workflows to better make use of the human elements in the processes. These feel more under our control than an AI-ish tool that would generate stuff based on general context or language over something that actively helps you.
Where do you see design systems heading in the next few years?
More splintered, to be honest. There will always be people coming to it for the first time, and as it’s grown in complexity, it seems like quite a beast already. On the other end of the spectrum, there’s a bunch of stuff around automation that could be very cool. Bringing design and development closer is an interesting space - anything to reduce or eliminate handover.
What's one thing you wish more people understood about design systems?
Haha, I could rant for a long time about this! Right now that it’s that all of this is a people problem. I’ve seen too many people jump straight into the tools without understanding their context; who is going to use this and take them on the journey. Aspects like adoption are tough if you don’t take people with you from the very beginning.
I’d also remind people that with all the great systems you can learn from that are amazing, are great for ideas but focus on solving your problems in a way that’s right for you. With many of these systems from huge companies, you don’t see behind the scenes. What they’ve made solves their problems in a way that’s right for them…and that may well be different from yours.
In your opinion, what are the most overrated and underrated aspects of design systems?
Overrated:
Assuming there is a perfect naming system. There are so many ways of naming tokens or components; just choose something and get people used to change. Systems should evolve, and we learn what works and doesn’t. Getting people used to change and learning to manage and roll out change can often negate the worry about naming. Do what feels right today and change when it feels like the right thing to do. Design systems should never be seen as immutable!
Underrated:
Taking time to ‘do your homework’ before diving into the tools. Learn as much as you can about the organisation, needs of your users, workflows, and how releases work before jumping into creating artifacts. You might be the first person to get this view, so it's a great thing to document and use as part of onboarding or explaining the design system.
If you could have a coffee chat with any person from the design (system) space, who would it be and why?
You know, I don’t think it’d be any one person. I got so much from my last role, listening to people’s design system journeys; I enjoy hearing them from everyone, in any role at any level of seniority. Why not you, Romina?
Coffee with Romina?
What's one piece of advice that you would like people to remember from this interview?
Solve your problems. Take your time to do your research and remember, like many things, it’s really a people problem; without putting work into that side, no amount of work on components will magically fix this!
What's your favorite thing to do when you are not in design systems?
Making music! Can’t beat jamming out some ideas, making some noise, or playing live. Being at gigs and feeling music shaking your bones is like nothing else.
