Last Wednesday I spoke at a Zeroheight design systems webinar with Josh Clark and Michael Haggerty-Villa.
At the end of the session, we were asked to share our most important piece of design system advice, and Josh’s answer stood out to me:
“Always prioritise quality over speed. Don’t inject crap into the arteries of your system, because you won’t be able to get it out.”
This resonated with me because it’s an issue I often encounter amongst design system teams I talk to and work with.
“That design system we didn’t know we wanted? We need it yesterday”
It usually takes several months (sometimes years) to build a business case for a design system and secure investment for a full time team.
However, almost as soon as that’s been achieved, something curious happens.
Historically-overlooked multiplication of effort—which those pitching the system have spent months hammering home to stakeholders—is suddenly seen as an intolerable problem which needs fixing urgently.
Product teams who were, until now, happily creating their UI without a system, are suddenly completely blocked by its absence.
“We need a design system and we need it yesterday” quickly becomes the organisation’s new mantra.
The result? That newly-hired design system team finds themselves suddenly crushed under the pressure and urgency of delivering something the organisation only just realised it wanted.
“Just hurry up and release some components - we can always iterate!” becomes the insistent cry of stakeholders from across the organisation.
Whoever’s heading up the design system team may suddenly find themselves in back-to-back meetings, explaining why the system isn’t ready yet and making wild guesstimates about when it might be.
The “Ship now, fix later” fallacy
In this environment, it’s perfectly understandable for a design system to bow to demand and start churning out subpar components in the hope it earns them some breathing room.
I’ve been a decision-maker on such a team more than once, and I’ll admit that’s what I did.
Under such enormous pressure, it’s easy to fantasise about future opportunities to go back and fix things. “Let’s just make things consistent, and then we can make them good”, goes the design system team’s new strategy.
But once they start scaling their system’s tools, content and supporting processes, the demand that’s already drowning them is only going to increase.
For a system to be successful, they’d do better to hold their ground.
Quality over speed saves time overall
We must remember that our design systems, when introduced, are not replacing nothing. They are replacing inefficiently-created, but often good-quality solutions: Solutions that have been designed by product teams in context and with thoughtful attention to their users’ needs.
Speed for the sake of speed means nothing. If our design systems don’t ultimately lead to better quality experiences, we’re doing it wrong.
When we rush to release one-size-fits-all components, without doing the work to understand different contexts before curating and consolidating solutions, we sacrifice quality at the hands of speed.
We undermine teams’ trust in the system from day one by providing brittle and poorly-researched solutions.
We disappoint stakeholders who see teams choosing to continue working in silos over using an inadequate system.
The irony? In the long run, this will slow us down. We end up having to undo the work we’ve done to fix the problems we’ve created.
Ultimately, when we prioritise speed over quality, we end up with neither.
What to do about it
To avoid this calamity, I offer four suggestions, depending on your context.
- If you’re in the process of pitching a design system, exercise caution when emphasising the consequences and urgency of multiplied effort. Manage expectations and set realistic timelines against your KPIs.
- If you’re a senior stakeholder who’s just commissioned a design system team, give them trust, time and space. Support them in pushing back on demand if they need to—you will get better results in the long run.
- If you’re in the new design system team and are facing the situation I’ve described, resist the demand to rush out components as best you can. I don’t say this lightly. I know it’s hard, sometimes impossible—do what you can. Rushing your system will only create debt, and that breathing room you’re compromising for will probably never come.
- If you already did rush out your components, slow down, go back and do it right. As the old Chinese proverb goes: the best time to build your system right was from the start. The second best time is now. (Or something like that).
Thank you to Josh Clark for inspiring this article and articulating this challenge so well.