Design system myths — 1. Source of truth
Concept vs Reality
‘The Design system is the source of truth’
Oh really?
Is it the Sun?
Are you God? What is this, a new religion?
Does this mean that it is all set in stone?
What? I don’t like rules, they mess with my creative flow!
I cannot compete with it, I must surrender and obey!
When I started working with design systems I heard this very often, ‘a design system is the source of truth’. I read it in books and articles, a very powerful and bold statement that stuck in my head and it made me sound knowledgeable when I did presentations, talked to stakeholders and managing directors about the DS benefits, trying to get their support on the project. But it didn’t help to clearly communicate to others what a design system is or does, the concept was too broad and too vague at the same time, it was confusing and left the door open to infinite interpretations which then turned into chaos when trying to deliver products.
‘It is the source of truth, yet it should evolve, one can improve it and change it if need be’
Oh now we are talking, let’s break the rules!
Oh so you mean it’s alive, like a tree?
So if we can change it, what’s the point of calling it the source of truth or having it in the first place?
How dare you change the source of truth? You must obey!
My creative flow is coming back but I cannot design because I’m still confused…
What? I’m confused! What is it then?
From experience, I’ve learned that a design system is simply a ‘system’ which can be basic if one is just starting or very complex if it is more established. This system is made of a set of basic rules, which may include some but not all of the following: company principles/goals, brand guidelines (typography, colour palette, grids, etc.), a toolkit of components or building blocks, a collection of design patterns, UX personas, target audience, research, brand assets, code snippets, etc.
The whole purpose of the system is to establish the basics to get a project started, then progress smoothly and finally finish successfully. This way designers and developers do not have to worry about what a primary button colour should be, or discuss for hours if not days about grids, instead they can focus on solving the real problems in the project by designing appropriate user experience with beautiful user interfaces, get developers experimenting with technology and more importantly, getting something delivered.
A design system is a project that needs building and then maintenance alongside the projects for which it is a delivery tool, so it requires constant revision, improvements and changes. It should not be a rigid system that allows no changes, it should be like an ‘open source’ project within the company, democratically managed and open to all for comment and suggestion.
Clear communication is key when it comes to working with a design system. My advice, avoid using concepts that are too broad or open to interpretation. Define what a design system means/is together with the team, simplify definitions and use familiar terminology, speak about what the system is in realistic terms and define limits, remember you have to use it on a daily basis, it is not just a presentation.
I hope that sharing little bits of experience will provide some advice to those stuck in similar situations or simply want to learn about the subject. Please leave a comment below and share with me your experiences working with design systems, that way we can all learn, support each other and hopefully find solutions to the many bumps in the road.
See my other article on Design systems:
8 things I learnt building a design system. Tips for creating and successfully implementing a design system.
Thanks for reading, I hope this was helpful.
You can find me on:
