Design systems, style guides, pattern libraries. What the hell is the difference?
It's a nice quote. I am not sure about cache invalidation (well, but they are!) but Phil is 100% right about naming things. In all the teams I collaborated with in the past, it was an issue. Our developers discussed naming functions and variables all the time. I am sure that they even loved it!
Hundreds of names for the same thing
And this got more complicated when we came with style guides. Or maybe component libraries. Or pattern libraries. Did you hear about design systems? It’s the big thing for 2017. Are they the same? Is there a difference? Why don’t we call it simply documentation?
Actually, let me tell you a secret. It doesn’t matter what you call it. It can be all — pattern library, design system or style guide. You only need to ensure that your whole team speaks the same language. If they call it a style guide, you should too. It will help when you need to communicate what you are working on, or when you will be working on it. Consistency in terminology saves a lot of time and misunderstandings.
It didn't help much, right?
This is probably not the answer you were looking for. Sometimes, you need to explain differences to your boss or colleagues and it’s always better to have the answer prepared in advance. If it helps you, feel free to use this:
Style guide is a set of rules which defines the basics. You can find colors here, typography, brand, icons, etc. You can even find a grid here. This is the most abstract part of UI.
Component library is storage for your components — articles, headers, galleries and many more. Each component is categorized, well-documented and responsive. Components aren't dependent on each other, but you are able to merge them together.
And finally, there is a design system which connects these two parts together. The design system defines the principles relating to the way in which components should work together. It defines how you can combine it all together. It also defines how layout should work, and it can define so many more.
I am aware that this visualization may not be correct for your case, but this simple structure helped me a lot when I was explaining a structure of our design system. The most important thing is to create structure which your team understand and respect.
But as I said before — simply pick the name you like the most and call it that. Now, it’s fancy to use the term “Design System”. It sounds complete, sophisticated and… well, systematic. Then just define all the parts you need and create a structure which serves you. It is also great if a whole team cooperate on this task.
Last but not least
A design system (or whatever you choose to call it) should help your team deliver the end product. We should never forget this.
There is another very common question. “Should it contain code snippets?” The answer to this question is quite simple. It depends on the use cases of your design system. (You defined use cases, right?) If one use case is the one that a developer needs to find a code snippet, it should be there. With all the information that could help the developer with their work. If your design system is mostly for visual designers, there may be no need for code snippets.
This is after all just a tool for everyday work. It’s a form of product documentation which should contain everything that helps with delivering the outcome. So when a team expands, new members should easily understand how the product works. The whole team should also understand why things are the way they are. It encourages them to respect the rules.
And remember — if it isn’t documented, it doesn’t exist.
Did you like the article? Don’t be afraid and press the heart icon here on Medium. You’ll make me happy :-)
Also, you can follow me on Twitter for more news about design systems.
