← Back to main

“Design must drive Development and not the opposite!”

Design system, Atomic design, Component thinking

In 2017, I started a wonderful and stressful adventure in a startup. The goal was to build a large learning platform.
A “scalable” platform, which meant implementing new features almost every sprint!

As we grow, a design debt was starting to build up for many reasons. The most important one, in my opinion, was a bad (or even lack of!) collaboration between UX/UI Designers. I felt the same problem coming up again on the development side which was starting to generate technical debt in turn.
As Lead Designer, I had to take action. I had to limit the damage which drove me to build a Design System.

I knew the concept of the Design System and had already used it during a previous project but never created one on my own.
It was a bit of a revelation for me nevertheless there was still barely any experience reported anywhere on the implementation of such a product.

So, here we are, a few projects later, my return on the implementation of a Design System.


What is it?

A Design System is a UX and UI referential that a moderator or all stakeholders use to design and develop products and digital services whatever the subject (application, service platform, e-commerce website and else…), the sector (B2C, B2B, B2E…) or digital support (web, mobile, IoT…).

The main principles of a Design System

The first thing you have to understand is that you don’t have to see a Design System as a project itself but rather as a product supporting digital projects of a company.

We can identify 5 main principles in the Design System:

  1. Alive: Unlike Identity Guidelines, the Design System is a living product that evolves and improves over time according to new needs, new use cases and the identity of the company.
  2. Agnostic: It is the design that must drive development and not the opposite. A Design System must, therefore, be technology agnostic and, at the same time, compatible with all major front-end technologies.
  3. Atomic: The Design System is based on the principles of Atomic Design. Again, unlike traditional digital charters, a Design System is not defined by pages but by components. One of the cornerstones of designing a Design System is the identification of all the components and patterns of the company’s digital ecosystem.
  4. Universal: A Design System must be able to take up a set of universal standards that won’t require the users to acquire new habits. It must also be able to respond to the logic of internationalization whether it is on use cases or language.
  5. Inclusive: The Design System must be designed for everyone, regardless of the context of use and the level of users’ maturity with digital technologies. It must integrate the main rules of usability and accessibility.

In practice?

A Design System is usually materialized on a website accessible by all stakeholders who can work on a design topic.

It’s generally composed of 4 large parts and a space to recover resources.

  1. Visual guidelines: Bring together all the rules around color, typography, iconography, imagery and data visualization.
  2. Structure: Presents the rules for structuring pages and modules, the responsive grid, spacing rules, navigation and menus.
  3. Components and patterns: Include all primary components (atoms) of a web platform like buttons, lists, text fields, cards, toolbars, tooltips, selection control, etc. As well as common patterns (molecules) like a form, search, authentication, chat, notification, etc. These elements are specific to the context of the company and must be identified at the start of the design.
  4. Language: Introduces the main language rules to know what tone to adopt, how to speak to users, grammar, vocabulary, rules of abbreviation, presentation of dates, feedback texts with Do’s and Don’ts to illustrate the about.
  5. Resources: The proposed resources depend on the purpose of the Design System. At least, the stakeholders can find a visual presentation of the different components and written rules to apply them. They also find color references, information about pixels, radius, shadows, etc. Optimally, stakeholders can find a set of source files like some Sketch files, iconography in different formats (.png, .svg, …), CSS files or even grab some code snippets in HTML5, React, Angular, etc. depending on the choices of the company.

The benefits

The implementation of a Design System will allow us to achieve these objectives:

  • Maintain a consistent experience across our different services and features. Which is still one of the foundations of ubiquitous platforms.
  • Focus the workload on features design instead of the look & feel and components.
  • Increase the performance of the product by minimizing front-end resources.
  • Make the product easily scalable.
  • Save time and money: With a Design System, including the components together with source code, it will be easier to onboard new developers and combining components to implementing views in front-end will become faster and joyful experience.

Here are some references

Carbon Design System by IBM
Lightning Design System by Salesforce
Atlassian Design by Atlassian
Mailchimp’s Pattern Library by Mailchimp
Shopify Polaris by Shopify
Digital First by Audi
Porsche Design System by Porsche