Setting up the foundations of your Design System : the O.S. case of PrestaShop

François Quetier
PrestaShop Product & Tech
5 min readJan 11, 2024

This article is the second in a series dedicated to the creation of a PrestaShop Design System. Read the first article here

[Summary article 1] The design system centralizes and documents all visual elements (colors, buttons, icons, logos, etc.) in one place. We decided to create a Design System as a follow-up to our rebranding, and to better integrate our new brand identity into our products.
After numerous discussions between the tech and product teams to clarify the challenges and objectives of the Design System, we were able to launch the initial workshops, the key to its success.

TL;DR :
- Carry out an audit before starting the Design System
- Estimate your design debt
- Collaborate with devs to agree on a common language

Analyze the current state of the product

Creating and deploying a Design System involves reworking the existing product. To do this, it’s essential to go through the product as a whole to establish the basis of our scope of intervention.

Code review
We undertook a complete review of our product to identify which parts of the code had been created manually and which used components. We found that many parts of the open source code used an older version of Bootstrap and two other libraries: Element+ and Tailwind.

Developer Documentation review
We carried out an internal audit to assess inconsistencies in user experience (UX) and user interface (UI) between our different pages. We identified that errors were often caused by incorrect or inconsistent use of our component libraries. Consequently, we decided to undertake a documentation audit to ensure that all information concerning the use of our libraries was clear and accurate.

Figma review
Next, we carried out an in-depth review of our Figma library, used to create our mock-ups. This revealed that some components were missing, poorly designed or inconsistent.

How to evaluate the design debt ?

Examining the design debt is one of the most important task before creating and developing a Design System. his gives us the arguments to justify such a project, and also to unite our teams around this subject.

In the form of a workshop, we listed all — or most — of our product screens in a Miro. All the teams pointed out the inconsistencies

Example of a one-page review
All screens listed during the workshop

Then we tagged, sorted and removed duplicates! Finally, we grouped each post it by component. It was a great job, allowing us to measure the entire scope of the project.

List of all identified inconsistencies…
All inconsistencies in order

In the second part of the workshop, we used card sorting to prioritize components with high user value, with a moderate design and tech effort. We got the developers and designers involved.

To sum up, we identified 4 steps for a successful workshop:

  • List your product screens
  • Identify your inconsistencies
  • Tag, sort and group your inconsistencies by component
  • Prioritize your components with high user value

The result is a design backlog of the first components to be created and implemented. For example: standardize the header, standardize primary and secondary buttons, standardize spacing, etc. Note that the first actions naturally concern basic elements of the design system. Now that we’ve done a complete review of our product, we can define a roadmap of first actions based on concrete elements and start to reduce design debt.

First, let’s speak the same language.

Communication between developers and designers is a key element for the creation of a design system to be successful. We’ve had a number of exchanges about component semantics, so that we can call a spade a spade. Or at least, to agree on the cat’s first name! We created a large table with all the atomic elements of our current design system. Every color, font, spacing and border-radius was listed. Corrections were applied to Figma and the documentation to ensure a perfect match.

when we talk about a red color, for everyone it will be red-500 and non-destructive-500, red or error-500

Some colors and typefaces have been modified or removed as they were too close or unnecessary. To facilitate implementation, we created a conversion table like this one:

Then we went over the basics (spacing, sizing, radius, shadows, typography, colors, opacity).

What now ?

The Design System project is well underway, and is starting to make some noise in the company. We’ve made several presentations to explain the project and its milestones. Some squads are looking forward to it, others are still skeptical. We’ve decided to take the time to delay the launch by 3–4 weeks, to ensure that the contribution and migration processes are well organized, and that the kit is available with a minimum of components. The next stage will be the creation of the first components, the technical migration documentation (Storybook), the design documentation (Zeroheight) and the creation of the main components (Figma).

The next 2 challenges:

There’s no denying the migration represents the first technical challenge where finding the right balance between priority and resource management is essential.

The second challenge is the contribution and adoption of the design system by teams and the public (Open Source contributors). Set up a contribution, validation and updating process. Both internally and for the community.

Our aim is to maintain the coherence of the system while preserving a certain degree of freedom so as not to hamper the speed of our teams and partners.

For the moment, we’re only looking at the Design System in terms of its internal issues, but we’ll try to tell you about our choices and issues surrounding its application in the context of our Open Source environment in future articles.

One thing is certain: it has already brought developers and designers closer together on a common subject, and fits in perfectly with our corporate vision and its objectives of product stability and customization. This convergence has been made possible by the creation of our 5 libraries, designed not only to facilitate internal use, but also to facilitate external use of the Design System by our Open Source community.

--

--