Let's start from the beginning

Design system. In recent years this term is everywhere. For us, designers, the definition and usefulness of a design system are self-evident. However, for other team members, it's not always so clear. 

If you already know what a design system is, do not hesitate to jump directly to the paragraph on communication.

In 2018, Usabilis offered this description: a Design System is like a library of components (library), visuals and principles with reusable code. This scalable kit offers a UX and UI repository for designers and developers of digital products and services. Ok, but without technical jargon? 

We could compare a design system to a large kitchen. There are plenty of ingredients and recipes that allow you to use these ingredients correctly.

The cooks of the design system are the designers (UI and UX) and the developers. It is to them that the design system will serve the most. The designers will select the ingredients (create the components), write the recipes (make the models) and provide them to the developers who will cook the dishes (develop the websites, apps, etc.).

By using a common kitchen, using the same ingredients and the same recipes, designers and developers are sure to have consistency on all the dishes delivered to the room (in production) and above all to have a result developed very close or even identical to the models created upstream.

And that's not even the main advantage of the design system! Indeed, its main asset is the speed of execution that it makes possible for the entire product team (designers + devs). The components being already ready, all you have to do is assemble them to create new pages, interfaces,…! We often compare the design system to Lego, it's not for nothing.

The other main benefit comes from component updates. Indeed, all the components being “connected” to the library, an update of one of them directly in the library makes it possible to update the component effortlessly wherever it is used. Saves time, saves effort (no need to search by hand where the component is used!), what more could you ask for?

Disclaimer: for the developers, the design system only has advantages for the front. It in no way takes away from the complexity of the back and the management rules.

# Contents

A design system generally consists of 2 sources of work. A source for designers, compatible with the software used (Sketch, Figma,…) and a source for developers, which presents all the components already developed as well as their code. In either case, the components present on these sources can be “called” directly (either in the models for the designers, or in the code for the devs) which saves a lot of time and consistency on the realization.  

When we talk du design system, most often we refer to the dev source because it is what is used in production. These are the elements it contains that will be seen by end users. The designer source is intended only to be visible to designers and developers.

But what's inside? Well it depends. There are of course guidelines, a multitude of articles listing best practices. Do not hesitate not to follow them if they do not quite correspond to the needs. Moreover, setting up a design system is something very long. Doing it all at once is complicated. There are, however, important elements towards which to tend, less primordial elements that it is nevertheless good to have and that we can completely add later.

Some important content elements:

• colors
• typography
• grates
• the components
• the guidelines for use of all the elements mentioned above
• the tone to use

In my experience, the main issues when setting up a design system are:

• for the company: the cost of setting up and maintaining which will be profitable in the long term
• for the teams that will set it up and use it: anticipating the arrival of new members in the team and designer-developer communication

Here we will focus on what directly affects the teams.

If you are wondering what is so special about the arrival of future members, I have a question for you. Have you ever tried cooking at someone else's house? If so, did you open all cupboards and drawers to find the ingredients and utensils you needed? Were you surprised not to find a spice that you consider essential? For me, the answer is yes.

It's exactly the same for our design system. Whether it's a new developer or a new designer who joins the team, he will have to be able to find what he is looking for very quickly on his own, and that the instructions for use are sufficiently clear to allow him to use the components correctly. This will allow our newbie (let's call him Fred) to be able to take charge of this new project in the best conditions and without frustration.

Then comes the issue of communication. By extension of the nomenclature and arrangement of components in the design system. Indeed, for team members (new or not) to find their way around, the design system must already be intuitive.   

If team members use multiple terms to refer to the same component, sooner or later it will become a problem.

Let's take a simple example : 

Some will speak here of droplist, others of dropdown. Still others from drop-down list or even from DDL. 4 possible names to designate a single component.

If for several components of the design system everyone uses their own name, communication between people will be more and more difficult because everyone will have to make the effort to remember that Lenny says “dropdown”, Karl “DDL”, Lisa “droplist” .

Each will therefore each time translate the thought of the other. In this context, now imagine Tony, the latest arrival. He does not yet know that these colleagues use different names to talk about the same thing. During a conversation, Lisa will talk to him about “droplist”. That's good, Fred needs it for his job. It will therefore refer to the design system and… there is no component named “droplist”. It will therefore take an extra effort for Fred to find the famous component. He will also have to learn that Lenny and Karl use other terms. 

Conversely, if to talk about the next color you said “blue”, and the whole team uses the same term, then the communication will go well. If we say “this component is blue”, everyone around the table will know what shade of blue we are talking about.

As you can see, having a single nomenclature for all team members, both verbally and in the design system, is very important to have fluid communication, and also to allow easy handling and navigation in the design system.

# Maintaining and updating the design system

A key term in the Usabilis description is “scalable”. A design system is meant to be in motion. These are not laws carved in stone: the elements that compose it can be updated, others can be created, old components can be deleted. Just as we adapt a recipe to our tastes after having made it several times, we can add new ingredients to obtain more flavors, more subtleties. 

A design system is not an end in itself. It is a working tool for designers and developers. As such, he evolves with teams and projects.

A design system should not be considered as a project with a limited duration. The components and rules it contains may change. Exceptional variations of some components may be required. Therefore, it is important to continue to allocate resources (dev + designers) to monitoring and maintaining the design system. If it was left out for a year, updating it would almost be like redoing all the work to set it up. It's very long. Nobody wants to do this twice. Not to mention the cost to the business. It is therefore essential to allocate resources to the maintenance and evolution of the design system. One hour per week may be sufficient depending on the degree of maturity of the DS.

# Key points

If you have come this far, I hope this article has opened up new horizons for your design system, or that you have a better understanding of what it is and what it is for.

If you had to remember only a few points :

• The design system is a creation and communication tool built by and for designers and developers
• It ensures the consistency of a product
• Its cost of implementation and maintenance is largely compensated by the speed of execution it offers designers and developers.
• It can change over time
• It should be updated regularly