Benefits of design system and how to build it
In my last article “How to get a head start on design system”, I talked about how to start building a simple style guide when you lack resources. Today I’ll share more knowledge about the process of building a design system for complex products (such as SaaS web applications). And I’ll share some helpful resources in the end as well.
Why did we start
Back in early 2014, when I just joined Bypass, because our products were very complicated, there were tons of inconsistency across the board. There were different buttons, different inputs, different layouts of the same element, and different interactions for the same flows. We wasted a lot of time debating design details, just because there were no solid rules for our product. These inconsistencies also brought bad experience to our users: they caused confusion and made it harder to understand and learn the system.
On the development side, because of the variety in code library, it was hard to find the “correct code”. Sometimes developers just wrote new codes instead of reusing the old ones, which led to even more inconsistency. It was a vicious circle, and with our team growing over time, communication and product delivery got harder.
Problems we had
1.50 shades of grey: Since our products were very complex, it was always hard to keep consistency. There were many UI inconsistencies across the system, including different colors, fonts, font sizes, etc.
2.Lack of rules: When our designers were building a new feature, it was easy for us to get bogged down with the details. Even simple questions like “Which component should I use?” and “Should I guide users to a new page, or use a pop-up dialog instead?” became very time-consuming to decide on.
3. Poor quality of delivery: Because of the lack of design rules, it was very hard for different teams to communicate with each other. I used to put lots of “red lines” with detailed descriptions on my design, to provide as many details as possible to the developers. But it was not an efficient way to hand off, and sometimes developers did not follow all the details I put on my design.
Imagine that your team launched a new project and people were celebrating, but you noticed a bunch of design bugs. You must be as happy as everyone else was, no?
4.Inconsistent code library: Because there was no rule, developers sometimes just grabbed what they found in the code base and implemented it in new projects. Some other times, they came up with completely new components with a different style, and this further complicated the code library.
5. User confusion: Our users needed a logic path to study the product and build a mental model about it. However, the inconsistencies we had made them confused and frustrated when they could not get their expected feedback.