Marie-Liesse de Solages
← Tous les projets
Edenred · Le produit pour les restaurateurs

Le design system

Un portail entier construit dans un système existant

Dans le design system d’Edenred, j’ai construit la partie spécifique à l’espace Marchand : ses composants, ses écrans et tous leurs états. J’ai créé ceux qui manquaient et remis en question ceux qui existaient dans d’autres produits sans correspondre tout à fait.

Le design system existait avant moi : les fondations, les tokens, les composants de base. Je n’en ai pas écrit les règles. J’ai appris à concevoir dedans et à repérer les moments où il fallait les étendre.

Portail marchand · Composants, écrans et états conçus dans le système Edenred
Composants
La planche des composants du design system, avec leurs cotes : boutons, champs, badges, tuiles de données, liste déroulante, interrupteurs et sélecteur La planche des composants du design system, en format mobile
Variants Documentation Responsive
Le produit

Le portail marchand Edenred est l’espace où les commerçants et restaurateurs suivent leurs transactions, leurs factures et leurs points de vente. Les composants de cette page ont tous été conçus pour ce produit.

Voir le projet Portail marchand →
Les composants

Des composants documentés jusqu’au dernier état

Mon critère pour dire qu’un composant est fini : quelqu’un d’autre peut le reprendre sans venir me poser de question. Ça veut dire avoir créé ses variants, ses états et son comportement à chaque taille d’écran.

Table & banner

Les deux composants qui portent les écrans de gestion : le tableau porte les données, la bannière dit ce qui se passe.

Table

En mobile, j’ai préféré redessiner le tableau plutôt que le rétrécir : colonnes sur desktop, cartes empilées sur mobile.

Anatomie3 statutsDesktop / mobile3 usages
La brique d’en-tête de colonne, avec son tri
En-tête
La brique de sélection : la case à cocher de ligne
Sélection
La brique de contenu : référence et date, en une ou deux lignes
Contenu
La brique de statut : payé, impayé, partiellement payé
Statut
La brique d’actions : ouvrir la ligne et le menu contextuel
Actions
La table des factures assemblée sur desktop : sélection, date, statut, montant et actions
Assemblée. Le tableau des factures sur desktop.
La même table des factures sur mobile : chaque ligne devient une carte
En mobile. Les lignes sont redessinées.

Banner

Cinq registres pour tout ce que l’écran doit signaler : information, avertissement, erreur, succès, neutre. En desktop la bannière tient sur une ligne ; en mobile, les actions passent dessous.

5 registresDesktop / mobileActions & fermeture

La navigation

Header

Connecté et non connecté, sur quatre largeurs d’écran.

4 largeursOrdre d’effacement
Le header connecté sur cinq largeurs : entité, langue, aide et compte disparaissent dans un ordre décidé, jusqu’à la version compacte à menu

Footer

Quatre largeurs, du bureau au mobile : j’ai choisi de tout replier plutôt que d’enlever quoi que ce soit.

4 largeursLiens & réseaux
Le footer sur quatre largeurs d’écran : liens légaux et réseaux sociaux se replient sans rien perdre

Menu latéral

Il est plié ou déplié sur desktop. Sa version mobile est plus longue : elle récupère ce que le header n’a plus : l’aide, la langue, le compte.

Le menu latéral déplié et replié aux icônes sur desktop et sa version mobile qui reprend l’aide, la langue et le compte
La documentation

Ce qu’un autre doit pouvoir reprendre

Voici à quoi ressemble un composant qu’on peut reprendre sans venir me poser de question.

La page Zeroheight du composant Dropdown, onglet Design : le champ au centre, sept repères numérotés autour de lui et leur légende en dessous
L’anatomie du composant.
La même page Zeroheight plus bas : une grille de vingt états du Dropdown, vide ou rempli, au repos, au focus, désactivé et en erreur, puis une paire Do et Don’t sur le texte d’erreur
Les vingt états du même composant et en dessous, les bonnes pratiques. Celle-ci dit qu’un message d’erreur remplace le texte d’aide au lieu de s’ajouter à lui.
Les états

Un parcours entier, état par état

Le parcours que je montre est court : modifier ses coordonnées bancaires, cinq écrans.

Cet écran utilise les composants Header, Menu et Table présentés plus haut.

1Vide

Aucun compte enregistré. Pas de badge de statut, une phrase qui explique à quoi ça sert, un bouton principal.

Écran de coordonnées bancaires sans compte enregistré, version desktop
Écran de coordonnées bancaires sans compte enregistré, version mobile

2Formulaire

J’annonce les contraintes avant la saisie : formats et taille acceptés.

Formulaire de saisie des coordonnées bancaires vierge, version desktop
Formulaire de saisie des coordonnées bancaires vierge, version mobile

3Erreur

L’IBAN et le fichier sont tous les deux invalides. Chacun a son message et le bouton reste inactif.

Formulaire avec IBAN invalide et fichier non conforme signalés simultanément, version desktop
Formulaire avec IBAN invalide et fichier non conforme signalés simultanément, version mobile

4Succès partiel

Le RIB est accepté. L’utilisateur sait où il en est avant même d’avoir validé.

Formulaire avec certificat accepté et bouton de validation actif, version desktop
Formulaire avec certificat accepté et bouton de validation actif, version mobile

5Confirmation

La demande est envoyée. Le statut passe d’actif à « mise à jour en attente ». La modification n’est pas encore effective et l’écran le dit.

Confirmation d’envoi et statut passé en mise à jour en attente, version desktop
Confirmation d’envoi et statut passé en mise à jour en attente, version mobile

Mon critère

J’ai appris davantage en me demandant comment un composant se comporte quand ça tourne mal qu’en le dessinant directement. Cette question-là fait sortir tous les cas auxquels personne n’avait pensé.

Au quotidien, j’ajoute au design system ce qui lui manque pour le portail. Je propose un variant plutôt que de contourner le composant dans ma maquette. Je signale aussi les écarts entre la documentation et la production.