1Vide
Aucun compte enregistré. Pas de badge de statut, une phrase qui explique à quoi ça sert, un bouton principal.
← Tous les projets
Edenred · Le produit pour les restaurateurs
Le design system
Concevoir dans un système existant
J’ai construit dans le design system d’Edenred toute la partie du portail marchand : ses composants, ses écrans, leurs états. Ceux qui manquaient, je les ai créés. Ceux qui existaient et qui tenaient mal, je les ai remis en question, y compris quand ils servaient d’autres produits.
Le système, lui, 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
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 ses variantes, ses états et son comportement à chaque taille d’écran. En voici une sélection.
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
J’ai préféré redessiner le tableau plutôt que le rétrécir : colonnes sur desktop, cartes empilées sur mobile. Trois statuts (payé, impayé, partiellement payé) et une seule anatomie déclinée pour les factures, les transactions et les points de vente.
Anatomie3 statutsDesktop / mobile3 usages
Banner
Cinq registres pour tout ce que l’écran doit signaler : information, avertissement, erreur, succès, neutre. J’ai gardé les mêmes pièces dans les cinq : icône, titre, description, actions, fermeture. En desktop la bannière tient sur une ligne ; en mobile, les actions passent dessous.
5 registresDesktop / mobileActions & fermeture
La navigation
Tout ce qui fait naviguer : le header, le footer, le menu. Je leur ai posé la même question : que garder quand l’écran se resserre et dans quel ordre lâcher le reste.
Header
Connecté et non connecté, sur cinq largeurs d’écran. Toute la question tenait dans l’ordre : qu’est-ce qui disparaît en premier et qu’est-ce qui tient jusqu’au bout.
5 largeursOrdre d’effacement
Footer
Quatre largeurs, du bureau au mobile. J’ai choisi de tout replier plutôt que d’enlever quoi que ce soit : les liens passent sous le copyright, puis tout se centre.
4 largeursLiens & réseaux
Menu latéral
Déplié et replié sur desktop, puis la version mobile plus longue : elle récupère ce que le header a lâché en route, l’aide, la langue, 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.
Les états
Un parcours entier, état par état
Le parcours que je montre est court : modifier ses coordonnées bancaires, cinq écrans. L’essentiel se joue sur les quatre derniers, ceux qui décrivent ce qui se passe quand ça ne va pas droit.
Les voici de bout en bout, en desktop et en mobile.
Cet écran utilise les composants Header, Menu et Table présentés plus haut.
2Formulaire
J’annonce les contraintes avant la saisie : formats acceptés, 2 Mo maximum.
3Erreur
L’IBAN et le fichier sont tous les deux invalides. J’ai voulu les signaler en même temps plutôt que l’un après l’autre. Chacun a son message et le bouton reste inactif.
4Succès partiel
Le certificat est accepté. L’utilisateur sait où il en est avant même d’avoir validé.
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.
Mon critère
Ce qui m’a le plus appris, ce n’est pas de dessiner des composants, c’est de les documenter. Écrire « voici comment ça se comporte quand » oblige à trouver tous les cas auxquels on n’avait pas pensé.
Au quotidien, je fais grandir le système. J’y ajoute les états qui lui manquent pour le portail et je propose une variante plutôt que de la contourner dans ma maquette. Je signale aussi les écarts entre la documentation et la production.