You don't need to solve problems twice - you need a design system

The design system concept can be differently defined according to each person’s background. Designers may say that a design system is a style guide while developers may say it is UI standards, or specs, or even assets. Whatever the words used, a solid design system might have different purposes, but one can go through all backgrounds and areas: to be documentation. Design systems are documentation: document how components look, how they should be used, how they made part of products.

There are several ways to represent one. You can have static documentation using tools like Sketch, Invision, or Figma, usually preferred and used by designers. Interactive representation using tools like Storybook, bit.dev, or Zeplin, typically lead by developers. The great benefit of the second kind of documentation is that it can show all different states, dynamically changed by you, as if you were interacting with the implementation in the “real” product. No more unexpected states or “what is the button color when hovered?” slack messages.

Everybody knows that naming things is hard, right? If you use the design system’s components, you no longer have to deal with that. Stop having different names for the same thing: one project with input, another with form field, and another with text field. Have just one, rich and well defined, and everybody will be on the same page.

Solve problems (once!)

Even the smallest component can have to deal with multiple usage scenarios. If you solve a problem properly in one place, you don’t need to solve it every time you have the same usage scenario, and you won’t forget to implement some edge and not common scenarios. Make room for productivity, implement wisely. New use case? Solve it in the design system, you’ll have it solved next time, and you can skip it in a blink of an eye.

When you implement a design system, you join all components in just one place. You can have it exported as a library to use in all projects, allowing to code reuse, avoiding code duplication. It also means less CSS and less styling, no more slightly different components that should be equal, no more different margins and colors, no more small style fixes kind of commits. However, have in mind that changing anything in the library will change in all products when updated. That can be either good or bad: be careful with breaking changes.

Iterate

A design system is itself a project, but it shouldn’t have an end, it should grow as projects, and the company grows too. The process of defining it is iterative. Improvements are made, and components are added, don’t expect to have a finished design system from one day to the next. New projects bring new components: a design system is like a company’s baby, it starts small and will grow and improve as time goes by. Iterate. Redesign. Improve.

You can work in a project and update the design system at the same time, npm link is there for you. It allows developers to link the design system’s repository to the project that they are working on.

[Design System] npm link
[Project] npm link @your-design-system-library

This way, the project will no longer look for the package online, it will consume it locally, which means that every time the design system changes, your project will be updated. When the library is updated to the next version, there are no unexpected errors or changes. No excuses not to update the design system, right?

Single source of truth

Communication has a significant role in product success. When having different teams working for the same end, they need to be aligned. They need to work with the same thing in mind and to communicate properly. Having a design system implemented improves the communication between all team members since there is only one single source of truth resulting in transparency, well-defined process, and coherent products.

The communication between designers and developers isn’t always clean and precisely done. If both use the same documentation, designers will know that they only need to review it in one place and not everywhere the component is implemented. On the other hand, developers will be sure that they are using the right and most updated component.

We all know that everything changes fast. A single source of truth, updated and well defined, can improve the communication between all team members, avoiding lost or incorrect information. In addition, having all implemented as reusable components lead to a faster and optimized implementation. A design system can contribute to organized teams and to product success, give it a chance.

See more about npm link here.