So how do we build a design system where the opposite is true? How do we make adding inconsistencies to a design system feel unproductive? Well, I think it’s important to note that designers and engineers introduce inconsistencies to a system not because of the code quality necessarily but due to a flurry of other reasons: poor documentation in a style guide, the naming structure of our components, the inability to quickly scan for what they need.
And considering we were only two designers doing this work (mostly as a side project) we knew we couldn’t sit down and explain The Guide to everyone that joined the company. So another goal of ours was to ensure that designers and engineers could explore what the system was capable of without having to ask questions all the time. The Guide should ultimately feel like a playground where you can quickly take LEGO blocks and build whatever you want from it. But that took a while to figure out, too. After months of work I found that a style guide is less helpful when it orders people to do something.