Design Systems, Oversimplified: The Why (4 of 5)
This is a 5-part series to explain the who, what, when, where, and why about design systems in its most simplest form. Once you understand the nuts and bolts of a design system, you’ll appreciate its deeper nuances more and might even want to build your own.
The Oversimplified Why
So far, we’ve simplified the who (designers and developers) and the what (standards). The why is baked into the original definition established in the first post: to ship to market faster. Let’s add a little more flesh to this “why” below:
The purpose of a design system is to improve the workflow between designers and developers so they can build a well-branded product that launches (ships to market) quickly.
Late launches are costly. It means a company is most likely paying their product dev team (the designers and developers) more to release and distribute their physical or digital product to the market they’re competing in. With a set of unifying standards, designers and developers have a singular language with which to build that product more efficiently. Onboarding times are sped up. Redundant or misused components in a UI Library are removed. New products can be built and shipped at lightning speed. And all of the products will be aligned with the company’s brand identity, which creates consistency and interaction familiarity with the end-user. So, when should you use a design system? I’m glad you asked. Check out the last post in this series for the answer.
