On Thursday, I read a brilliant blog post about Barnardo’s design system.
There’s lots to say about this work, but for now I want to focus on this paragraph:
“Designers and developers want to focus their time on solving the problems unique to their product, instead of spending time reinventing the wheel on things like how navigation should work or what a button should look like.”
I was surprised but happy to see this statement used in place of the common alternative, which says that “Design systems solve the easy problems, so teams can focus on fixing the hard ones”.
Let me explain.
Design systems fix the common problems, not the easy ones
Design systems exist to stop teams doubling up their efforts fixing common, recurring problems, like how to write an error message or create a call to action on a page.
By providing tried and tested solutions to these problems, supported with usage guidelines and code, they can reduce duplication of effort and create consistency across one or more products.
But ask almost anyone who has worked on or contributed to a design system and they’ll tell you there’s nothing easy about it.
Making something that meets the needs of hundreds, maybe thousands of users, accommodates organisational requirements and limitations, and is versatile enough to be reused, is really very hard indeed.
Hard work is your best selling point, don't understate it
I don’t have evidence for this, but I strongly suspect that one reason we describe design system problems as “easy” is because we think it’ll help drive adoption.
By reducing the development of user interface elements and interactions to an “easy problem”, we think we’ll somehow put people off wanting to do it themselves and convince them to adopt the design system instead.
After all, who on earth would want to waste their time doing something as menial as designing a button when they could be focusing on so many more important, interesting, difficult problems?
It’s a nice narrative, but it doesn’t hold up. It’s too reductive and it undermines the hard work of design system teams and contributors.
Not just that, but it's precisely the kind of hard work that goes into laying the foundations that makes people want to use a design system.
It’s far better to sell it on its strengths, and with an honest portrayal of all the hard work that’s gone into it.
Design system problems are everyone's problems
By saying “Design systems solve the easy problems, so teams can focus on fixing the hard ones”, it suggests that design system problems are solely the responsibility of a design system team.
But contribution and participation from the wider community is integral to a system’s success. A good design system needs to fairly represent the people it serves.
That means sharing responsibility for creating, maintaining and evolving the components and patterns provided.
Put simply, you'll only end up with a design system that works for the whole community, if the whole community helps to build it.
A design system is not just a set of patterns
Providing common design solutions is just one of the hard problems that design system teams have to contend with.
You need to support teams who adopt the system. Unless your system was built at exactly the same time as all of your organisation, you’ll likely need to help teams embed it into existing products and services. Not just once but continuously.
It’s not enough to just publish a component or a pattern and leave it there to rot. You have to enable people to feedback on its performance, and use that feedback to evolve it iteratively over time.
As I touched on above, you need to get people to contribute their own work and research. Again, not just once but constantly and continuously.
To say this is challenging is an understatement. We’ve been developing the contribution model for the GOV.UK Design System for the best part of 2 years, and we’re not done yet. Not even close.
As my colleague Nick Colley put it:
“It's easy to build something that no one can use or input into. It's hard to build something that's useful for many teams and can be contributed to.”
We are not competing for hard problems
Working on a design system is hard. Working on a product or service team is hard, too. There are more than enough hard problems to go around and the difficulty of one doesn’t diminish the difficulty of another.
The job of a product or service team is to deliver helpful, considerate and positive solutions to help meet its users needs.
The job of a design system is to provide a start point for the common problems–a set of reusable solutions validated through robust research, and continually iterated upon with help from the community.
It's only by sharing the load of our problems, both the easy and the hard ones, that we'll stand a chance of solving them.
Acknowledgements
Thank you very much to Ignacia Orellana for your invaluable input in helping me make sense of these thoughts.