Over the past few years, there’s been a significant shift in the way I think about the work of creating design systems.
Previously, I saw the task of establishing design systems as the act of making something new. And this is still how most organisations I consult with tend to approach the work.
Nowadays, I think of the work more as the practice of changing existing cultures, processes and tools to cultivate design systems that better support our needs and goals.
Why design systems work is more about changing than making
When we think about the work of creating a design system, we tend to foresee it happening at a point on a linear journey.
We hire our design system team and plan our work around what our version 1 design system will entail. We work on that until it’s released, and we go from having no design system, to having one.
And approaching the work with this mindset means that we often dismiss all those other processes, practices and resources that existed before version 1 as “not a design system”.
But what if we looked at things differently? What if we considered that before we’d even begun the official work, we already had a design system?
And that system might consist of:
- designers creating prototypes in local Sketch libraries
- a siloed design-to-dev handover process
- developers working in localised, fragmented, frontend code libraries
- lots of inconsistencies in our user experience
A design system like this might not be very effective. It might not help us work efficiently at scale, and our products might not be very consistent, and the quality might not be good.
But thinking of it as a design system doesn’t make any of that less true.
What it does do, however, is help us to avoid one of the most common missteps I see teams making - and that I myself have made - which is that we inadvertently create 2 design systems: The new “official” one, and the existing “unofficial” one.
Existing systems can undermine our efforts if we don’t engage with them
The thing about unofficial existing systems that emerge organically in our organisations, is that they tend to have strong roots.
So when we simply lay a new shiny design system on top, those roots have a habit of growing back through.
It’s why teams often cling to their existing product-specific components, rather than moving to centralised design system ones.
It’s why people continue to reference local pattern libraries, rather than visit a design system documentation website.
It’s why designers and developers continue to work in silos despite touchpoints, artefacts and processes designed to get them to collaborate.
So I think it’s really important that we don’t dismiss our existing design systems, but instead engage with them.
We need to recognise their validity, and bring them on the journey with us as we work to cultivate a design system that better serves our intentions.
Our job is not to set up new systems, but to bring intention to existing ones
So what if we thought about design systems not just as the bits we’d actively created, but as the practices and processes that allow us to design and deliver our experiences?
Looked at through this lens, our job is not to craft something entirely new, but rather to bring intention to those practices, to create a design system that better supports our goals.
For this to work, we have to take the time to understand our contextual purpose. What are the biggest problems our design system needs to solve? Where is it supporting those needs today, and what can we change to close the gap between our current design systems and our intentions?
This is a departure from the way we typically approach the work of establishing design systems, but one that I think offers a lot of opportunity.
Embracing the practice of bringing intention frees us up from the pressure to deliver system artefacts, and allows us to make incremental steps towards the place we want to get to.
In this world, every small movement counts as a success.