Recently, Amy Hupe asked this question on Twitter:
Who’s got a really clear and concise explanation of what design systems are, that would make sense to someone who’s never come across one before?
We had a good discussion and I thought I’d preserve the results here.
An explanation of what design systems are
We are the design co-ordination service.
We organise and test the basic things of our websites, like buttons and logos, and we help colleagues to build websites using those basics. This means that when anyone uses our websites, the basics work properly and in the same way. And we do that for other things too like apps and paper letters.
We call the collection of basic things, and the rules for using them, our ‘design system’.
This explanation is a mixture of my original suggestion, drawn from a previous discussion on Twitter after a presentation by Tim Paul (@timpaul) and follow-up comments from Sridhar (@uxgravy) and Sarah Federman (@sarah_federman). It’s aimed at people who are not familiar with any of our typical terminology.
A design system can be a process or a product
Sarah Federman reminded us of her excellent article Distilling how we think about design systems where she links to several different articles about design systems, and also explains two other views of them:
- as a combination of a product – the things in the design system – and the process of creating and maintaining those things.
- as a product that has a matching but separate process.
She and I both lean towards thinking of the design system as a product.
A design system needs a design system team
I’ve worked on a lot of design systems, and things that were not called design systems at the time but would be now. I’ve also, sadly, noticed that many design system efforts have foundered because the idea ‘a design system is a product’ has been confused with ‘a design system is something that you build once and forget’.
A digital product isn’t a monument that you build and then forget about. Its value comes from the community that you create around it, and the way in which the design system team works with that community to keep the design system up to date and useful. The initial build effort is only a small proportion of the work. So I decided to include another thing here that I find myself saying often:
Building the design system in the first place is 1% of the work. Creating the community that uses it and keeping it up to date is the other 99% of the work.
Comments are welcome
If you’d like to comment on this definition and discussion, please feel welcome. My contact details.