Have you ever seen that screen? You deployed so much menus that you cannot access the ultimate component you were looking for.
The screen was not sufficient enough to display the hierarchy, I decided to propose a design system more elaborated.

Principles

Unified & Universal
Our product and visual language should be consistent and accessible.
Our mission is to make the use possible on any types of devices, any types of apps, any types of users.

Useful & efficient
Our product is more utility than entertainment, meant for repeated daily use, providing value efficiently. This is why our core interactions, the ones users engage daily, are streamlined, purged of unnecessary clicks and wasted space.

Empower users
If we don’t know who the users are, we can’t design the right thing. That is why we keep our users in mind by doing the research, having empathy for them and designing what they need not what they want. This will ensure our designs empower them instead of overwhelming them.

‍

Organization

I suggested to have everything (Components, documentation, specifications) into Figma. UX developers using Storybook could see the design directly into Storybook and the attached documentation. All Specifications created by designers to mention pixel numbers were not necessary as the component would be developed, but also clicking on a component would redirect to the dedicated library with the information in case of doubt.

This is the organization I suggested after reviewing components we already had. It got inspired by Fluent from Microsoft.
Atoms first: The biggest issue of designers were to choose spacing, font-size, colors and icons.
It was there but I wanted them to take elements already made with right fonts, colors and spacing.
I dissociated few components, for example text field and dropdown in 2 different sections.

We started with 2 other designers to use iconography on layers to show what was started, done or needed reviews.

Tokens

We had so many similar colours, almost duplicated. Reducing the number of options to the minimum simplified the decision.
A UI Designer reviewed all colors throught examples. We established principal tokens and used for different components through the app.

Global tokens were used for component specific tokens for instance.

Primary buttons

Secondary buttons

Documentation example

A primary button should be unique on a page. It can be alone, especially if the screen is blocked on a specific page.
Examples of primary actions: “Save”, “Publish”, “Do”, etc...

A secondary button should be beside a primary button.
A limitation is necessary to not have unlimited button. Ideally two secondary buttons can be stacked beside each other in addition to the primary.
Examples of secondary actions: “Cancel”, “Save as a draft”, “Do not”, etc...

Specs

Primary button text
Font: $body-1-strong
Color: $text-light
Primary button container
Fill: $brand-secondary

Secondary button text
Font: $body-1-strong
Color: $brand-secondary
Secondary button container
Border: $brand-secondary
Fill: $background-light