Pollux Core Design System

  • date icon

    Date:

  • question icon

    Description: Creation of the technical infrastructure of a Design System that can be declined into multiple Design Systems

  • label icon

    Type: Frontend development, Design System, Project Management

  • tools icon

    Tools: VSCode, Figma, Web-components, Stencil, Typescript, Component library, Storybook, An excellent team

Level 0: The color is chosen but makes no sense; Level 1: The color has a name. It's now part of a system but doesn't have a purpose or a context; Level 2: The color is defined in a context where it can be applied

What is Pollux?

Pollux is the UX and UI expert team of Docaposte. Most of the La Poste group interface experiences are made or validated by the Pollux team.

info icon

For information, La Poste is one of the oldest company in France best known for its postal service but there are a lot more. Also, La Poste is in the top ten companies with the most employees in France.

The Core project

Context

Inside La Poste group there are multiple Design Systems created for a specific area or department but also several dozen of different technical stacks.

When I joined Pollux there was no web frontend developer in the team and all the development was done by external teams. All my coworkers were UX designers, UI designers and Project managers. I mainly worked with a Design System Designer (Louis Marcos) and a Design System Manager (Théo Péridont) in tri-force.

My role was to build the whole technical infrastructure which will manage the development of all tools and solutions related to Design Systems.

The goal was to align all of these Design Systems on the same convention and technical constraints and make room for specificities. To do that the idea was to create a totally agnostic Design System called "Core" to rule them all. An ecosystem of design systems.

Here is a schema to better understand the governance strategy:

The Core block at the bottom, other Design Systems block on top of it and at the upper top projects blocks to represent the governance

Schemas demonstrating that the Core is a base for other Design Systems which serve products in multiple stacks.

On the technical side the Core and each Design System library were developed in web-components and compiled with the help of Stencil in dedicated packages usable in different stacks if needed. As the Core was not consumed directly in projects it just had to be available in Stencil components.

At the end, as all child Design Systems inherited from the Core, the whole ecosystem should use the same system strategy with the same naming convention, the same properties and constraints. If designers and developers switch from one project to another, the only differences they could see will only be the theming and the face of their new coworkers. The quickest onboarding ever!

Design Tokens

Based on the strategy previously explained the Design Tokens were designed to be as agnostic as possible but more importantly flexible enough to make room for all the theming of La Poste Group. Thanks to the Design System Designer I worked with, the work had already been done. Instead of defining things for one system he defined the whole palette as a source and create a token system on top of it that can be declined easily only by following the right naming convention.

Level 0: The color is chosen but makes no sense; Level 1: The color has a name. It's now part of a system but doesn't have a purpose or a context; Level 2: The color has a meaningful name, it defines its context so we know where it can be applied

This is an example of how a color can be defined as design token from the moment it is chosen to the moment it can be used.

By doing that, each design token was only a sort of container on which we can define a value in a desired context. For us this context could be the theming of an interface (dark, light, sepia...) but also a brand theming specific to a Design System. As simple as applying theme with CSS variables.

Components

For the component part, the idea was to create the most atomic and common components in the Core Design System and use them in the other Design Systems with a specific theme applied. If there are specific component need it has to be created in its specific context until the need becomes common (minimum 2 different areas). At this moment the component should be part of the Core.

A button component with design tokens which can be overrided with other values.

Example of a button component with design tokens applied and how it can be overrided.

The collaboration

Within the Pollux team there was no question about the use of Design Systems and their UI Kits. On the design side all of my coworkers were using or managing one of them. As I was the first developer I had to create the inexistant connexion with other developers (most of them were product developers using external UI Kits like MUI or Vuetify).

So, the idea was to evangelize the use of the libraries I was creating and accompany teams with the integration in their projects. This is one of the biggest part in the Design System Management because it allows to get feedbacks and make sure that the system is well used. Globally it is very similar to an open source project but with coworkers, there are a lot to do in terms of continuous improvements.

Conclusion

This is by far the biggest challenge I had to work on in my career and I'm pretty proud of what I've done. I also had one of the best designer/developer collaboration. My coworker Louis was a Technical Designer and, as I'm a Creative Developer, it was a real match in terms of collaboration. We did a great work together.

In conclusion, I'm still convinced that the tri-force Design/Dev/Management is the best team model for a Design System team.