The PrestaShop Design System: the Open Source challenge

TL;DR:

• The design system can be a tool for managing design debt.
• The design system can be complex to set up in a company.
• The design system federates the Product/Tech/Brand teams.

Against a backdrop of accelerating growth and international expansion following the acquisition by the Italian group MBE Worldwide in 2022, PrestaShop is repositioning its brand in 2023. Repositioning means a new identity, and integrating it into our product and service offerings. This identified need enabled us to spend more time on an issue we knew about, but had only touched on at the time: design debt.

As PrestaShop is an Open Source solution created by and for a community of developers, user experience, UI and documentation of contributions were not the main priority. Our company was also growing fast, with growing product teams that needed to integrate quickly.

In this context, one question was at the heart of our reflections: how to integrate a new brand identity into a mixed technological environment based on an Open Source solution? For us, this new identity was an opportunity to consider the design debt, since it enabled us to align product components on the same basis, and make it a common issue for the whole company.

Design System as an alignment tool

The design system is considered the visual heart of the product. It centralizes and documents all visual elements (colors, buttons, icons, checkboxes, etc.) in one place. While developers comment, order and structure their code, why shouldn’t design be inspired by such an organization?

A design system really is useful:

• A 50% increase in velocity from design to development, for an annual saving of 250K for a team of 10 designers*.
• It considerably reduces, if not eliminates, design debt, the source of inconsistencies, accessibility problems and unsuitable user experiences.

The design system is an effective tool for scaling a business.

In the corporate world, the creation of a design system can be a thorny issue, regardless of size or level of maturity. Arguments against it abound: lack of time, apparent short-term usefulness, lack of resources and so on. Yet implementing a design system is just as strategically impactful as choosing the right technology to launch an MVP.

The first steps towards a corporate project

By 2022, PrestaShop’s design teams had grown considerably, from 4 to 16 Product/Content Designers, each with their own scope.

The designers had been working on a Design System for several months. The project was still in its infancy, even embryonic, with little knowledge of it within the company, not allowing sufficient mobilization of tech resources in particular. As a result, it was more akin to a UIKit than a DS as such. This lack of mobilization around the subject meant that it was not possible to address the structuring issues required for its successful implementation, such as the choice of technology and the implementation strategy. Discussions stagnated for a long time, and were unable to move forward constructively.

The need to reflect PrestaShop’s new identity, both for external communication mediums and on our software, served as a catalyst. From then on, adequated experts were able to officially take up the Design System project.

That’s how Fabien (VP Engineering), Aubin (Front Developer) and myself, Lead Product Designer, took control of the Design System topic. A few weeks later, we were joined by two Product Designers to ensure communication, followed by a Tech Manager, a Lead Product Manager and an Agile Lead.

Little by little, the project caught on. We’re now a team of 9 people, accompanied by our army of designers and developers, all motivated to contribute to this company project that’s being more and more visible.

As the initiative is new, we don’t have a team entirely dedicated to the project. It has been agreed that each contributor will devote a percentage of their time to a task related to the Design System. This way, we can move ahead with the project without having a dedicated team.

Negotiations, arguments, decisions and policy

Launching the Design System project led to the implementation of exploratory phases in the form of two simultaneous projects:

On the developer side, research was carried out to decide on the CSS framework to be used (Bootstrap, Tailwind, Element…) and a migration process was initiated.

On the design side, needs (theme, mobile, desktop) and UX were defined, and the first atoms (UI) were created.

The designers then work on a corporate challenge. How can PrestaShop’s new brand identity be applied to the software? All this while imagining a 5-year version of the product, with no constraints. An article will be dedicated to this challenge, so stimulating was it for the designers, but also for the company.

These two tasks were carried out simultaneously, and took around a quarter to complete. There were many discussions between the engineers, mainly about the technologies to be used. It took several meetings and individual responses to fears to reach agreement on the use of the Tailwind framework.

Here are some of the questions that got Slack talking:

• Why redo everything when you already have Bootstrap?
• Has Tailwind gone mobile-first?
• How do we migrate our 143 product pages?
• How do we make the two cohabit?
• How can I use Tailwind if I don’t use VueJS?
• The current library doesn’t meet my needs, what do I do?

Token or no token?

Another debate: Token Design. Being at the beginning of the project, and not wanting to miss a major turning point in the field, we’ve been testing and researching the use of tokens.

As I write these lines, Figma offers Variables to defend the subject. Other plugins, such as Figma Token, automatically push token design updates to GitHub. We could imagine Product Designers or even our Open Source contributors modifying the design system without touching a line of code. The complexity lies in the creation of the tokens themselves. On which components, atoms and values should we create a token?

What do we want to make modular? We’ve decided to integrate the basic tokens (colors, typography) and to keep an eye on the arrival of a new tool that could help us automate the creation of tokens on a wide range of components. One thing’s for sure: we don’t want to neglect this aspect.

Edit: In the meantime, Adobe has launched its tool, which we’re eager to get to grips with.

These early stages of the project enabled us to establish a common understanding of the objectives and challenges. Following these discussions, we were able to start the initial workshops to create a common basis for the Design System, both from a technological and a design point of view.

*Here are two excellent articles to back up these figures: https://zeroheight.com/blog/what-is-the-value-of-a-design-system/

https://www.smashingmagazine.com/2022/09/formula-roi-design-system/