Pros and cons of the design system

If I had a few seconds to explain to you what a Design System is, I would start with the following definition: 

A design system is built on a visual style, documentation, and code snippets. You can copy and paste elements (components) from a library and quickly build a new project. 

To sum up: design tools, fragments of code, and descriptions of UI elements that are implemented in a Design System make products adopt more efficiently and cohesively. 

What’s good about design systems? 

Saves time and money for design, dev, and product teams 

With functional component and pattern libraries, your team can take UI assets and code snippets and run with them, knowing they will work. These assets and components are fast and clean to implement since special care is taken to build things the right way the first time. These save the time traditionally spent on research, meetings, and development, and give it back to your team to spend innovating, learning, and perfecting their projects. 

Ownership of the system is distributed 

More dependencies on the system mean more people care about the system is the best it can be, which incentivizes working together rather than apart. 

One source of truth 

This means better brand consistency across all channels. No more using over a hundred different shades of grey, or five primary buttons that don’t even show up in your style guide. If your brand guidelines update, your design system does too and applying those sweeping changes to your products becomes much easier, faster, and safer. 

Knowledge transfer becomes much easier 

Design and code handoffs don’t require nearly as much auditing and onboarding if everyone understands and trusts the components. 

What can be challenging? 

Upfront time commitment and allocation needs. 

It takes a lot of devoted work to create a solid design system. If you’re building it right, this should account for most (if not all) of the allocation for your systems team members for several months. Statistically, “successful” design systems seem to account for more elements (Things like typography, form components, voice, tone, etc) than those ranked “average” or “unsuccessful”. It takes time to save time. 

Work must be done to socialize the system. 

In order for a design system to be successful, it has to be used and supported by all, and everyone must know when and how to use and modify it. Teams should feel comfortable using and modifying patterns and components. This requires training, constant communication, and helping your teams take ownership of the design system. 

The system must stay up to date and document. 

In order for your design system to be trusted, components must be consistently updated and include the proper documentation. Failure to provide ample and thorough documentation or keep components current erodes trust in all you’ve built. 

Design Systems can save a lot of time in the face of complexity, but require a big investment of time and focus. So, is all that effort going to pay off in helping your organization achieve its goals? Let’s break it down. 

Conclusions 

A proprietary Design System is certainly more useful for companies that have a strong brand identity and values, sell proprietary products and services that evolve over time, and operate across multiple channels. 

An open-source Design System, on the other hand, could be a good starting point for companies or start-ups that do not yet have a well-defined identity and do not yet have the tools to develop their own DS. 

It is important to ask yourself the right questions at the beginning of the project. If you define the requirements well, it will be clearer to your which way to go.