If you work with clients who have a strong graphic identity, there might come a day when you will be confronted with the creation of a design system. This recently happened to my team. We were working on a mobile application for our client and they decided they wanted to create a second application that would reuse the same graphical elements as the first one. In order to save time, ensure consistency and share code, a design-system became mandatory.

In theory, it was a good idea but in practice it was a nightmare. Using the experience acquired on this project, I will show you the mistakes we have made and I will try to share some tips on how to avoid them. These tips should allow you to reduce the amount of problems encountered, and to improve the implementation process of your design system. Keep in mind that a design system is never finished!

‍

What is a design system? What is it made of? what is its role, its objectives?

A design-system is a library of shared and reusable resources, it can contain graphic elements, UX principles and recommendations, along with developed components, so that designers and developers can quickly design coherent products together. It enables the creation of consistent user experiences for websites, mobile applications, or other types of HMI, while optimizing the design process.A good design-system must be able to respect these different rules:

• It must be scalable / alive: it is constantly fed by new resources and it is constantly evolving,
• it must be updatable: reusable elements are automatically updated across different platforms,
• it must be able to be reusable, adaptable and therefore it has to be platform agnostic: it must have HMI ergonomics rules and design standards so that it is reusable and adaptable to technologies (Smartphone, web, other HMIs).

The design-system is a great tool to improve the quality of the product (both at the level of the code and at the level of the result) but one must keep in mind that every design-system is an ambitious project, that requires rigor and methodology. One of the most popular methodologies was theorized by Brad Frost with Atomic Design. His theory breaks down as follows:

• Atoms: the basic elements (theme, small components...),
• Molecules: groups of atoms,
• Organisms: group of molecules,
• Templates: the general content structure without the content,
• Pages: the real and finished content
  ‍

Mistakes I have encountered and how to avoid them

Always involve developers in the creation of a design-system

Not involving the developers in the conception of the design-system, can be a mistake, even more so if you are starting with an already existing application. There is a world between the theory of the design system and the practice at the level of the code. In this world we can find constraints related to the architecture of the code or even technical dependencies requiring the use of certain designs (framework, libraries…).

As an illustration our designer had designed a calendar component unfortunately at the code level designing a calendar component from scratch can be complex and time consuming, enough that other developers have already dedicated time to compose this kind of component in the form of a library. Therefore it is much more pragmatic to try to make the design stick with something existing and trying to customize it to make it your own. After that we, the developers, had to do a study on the existing calendar components and how they are customizable, then the designer could choose one and customize it within the limits offered by the component.

Let me put you back the context of my project and show you another way that mistake can unfortunately impact the project. We had already developed an application for mobile devices but also for tablets and web browsers. And we have developed this application to be as responsive as possible. Therefore we designed our applications to have correspondence between mobile and tablet (web), in this way when we use the font: LabelSmall it will call the right font size depending on the type of the device/plateform. This allows us to be more responsive but also to keep a good overall consistency of the design which improves the user experience. At the beginning our designer had created the mobile and tablet models without using all the correspondences between the two. After that our designer had to review all the designs using text (in other words all the designs).

‍

Never forget to ask the developers if they consider the design-system ready for development

Involving developers also allows them to give an opinion on whether the design-system is ready enough to start developing. If the go/no go is not given by the development team then you can find yourself in a situation where the developers have to give feedback to the designers because they have too many uncertainties about what they have to develop. This obviously wastes time for the developers but also for the designers who cannot continue to progress on their work, and you wind up arriving in a tense flow between the creation of the designs and their development, which is not necessarily a problem. Unless, as in our case, your designers work on your project only 2 days a week. Having a 100% staffed designer in the early development phases of the design-system is a big recommendation. As you can imagine at the beginning of a project if the developers have not been involved in the design-system, they will have a lot of questions for the designers.

‍

Always have someone accountable for taking decision

Another mistake is to not have a clear decision maker. When developing an application, you have to be pragmatic and make concessions between the quality of the result (both in terms of code and design) and the development time (and therefore the monetary impact of the development). At BAM we make it a point of honor to give our clients what we believe is the best compromise. However, if they decide to allocate a week of development to create a component instead of using something existing, that is their right and their choice.

In short, the decision-maker's role is to decide between the ideas of the designers and the expertise of the developers.

For example, it was very complicated for us to explain and to ask the designer to allocate time to go over all the designs and thus create the concordance between tablet and mobile. We must not forget that developers and designers work together and not for each other. Thus only someone who is responsible for the budget and the quality of the application can be legitimate in this kind of decision.

‍

Be sure to have the same aim

Finally it is very important that all the actors of the project are aligned on the objectives of the design system, it is the only way for the right decisions to be taken and understood by the teams. For example on my project on the developer side, we understood that the objectives of the design-system was to have consistency between the old and the new application but also to save time. Whereas for the designer the objective was to create a design system that would be reusable by other actors in his company. This may seem trivial but there is a big difference since on the dev side decisions are made to make the design-system work in our environment where the designer seeks to create something usable in any type of environment. This involves many different decisions just in what we want to put or not in the design system. Which can lead to decide to have a different design-system in terms of its content between the designers side and the developers side.

‍

‍

Other design-system related tips that might interest you

1. Take some distance if an application already exists

If you create your design-system based on an existing application try to take a step back, it is sometimes more efficient to create a new component and integrate it into the existing application rather than integrating the components of the existing app in the design-system. We made this mistake and ended up with components having to support a large number of different sizes and colors (which implies complexity at the code level), where we could have worked on the design of the existing app to reduce the number of variations.

‍

2. Choose the right communication tool

Communications tools are key in business, but not having one adapted to your needs can be detrimental to the communication between the different project stakeholders. If you are used to communicating in writing, I would advise you to use a tool allowing threads. Otherwise you could find yourself in the same situation as us where regularly in the morning the developers were sending a certain number of questions concerning their ticket, and then found themselves with questions and answers that are mixed making communication slow, painful and generating a number of notifications (that distract for nothing) for all project stakeholders. Communication by private message is rarely a viable solution since generally more than two people are involved in the precise decision-making and the entire team may be of interest.

‍

3. Define how you will properly check the development of your design-system

If you work like us with product owners in charge of the good development of the application, it can be difficult for them to check that the design-system has been rightly developed. Having a clear process on how to check the proper development of the design-system is a must have. On our project we decided to ask the designers to take care of the validation of the design developments, his background as developers allowed him to verify that all the dimensions and properties of the components were well respected.

Conclusion

A design system is not only for the designer and should not be designed by him alone. Developers and decision makers must be involved, this is the best way to obtain a usable, adaptable and improvable tool. It’s also the only way that improvements in quality and development times will be felt. But it is also up to the developers to remember that the design-system is not necessarily built for their sole use either.

‍