Contexte
Design system conçu pour supporter la conception de tous les parcours de l'ERP pour les pharmacies africaines.
Equipe : 3 personnes
Enjeux
Pour supporter et faciliter la conception des fonctionnalités de l'ERP, nous demandions à ce design system de :
- Assurer la cohérence de l'UX au travers de tous les modules de l'application, sur le temps long
- Supporter des écrans de téléphone jusqu'aux ordinateurs
- Assurer le respect de l'approche touch-first
- Rendre accessible la complexité de l'ERP à des personnes manquant de maîtrise des outils numériques
Stratégie & Process
La conception du design system s'inscrit dans une démarche d'ensemble qui tient compte des enjeux de l'ERP, des choix et contraintes techniques et de nos propres décisions design.
- L'ERP sera développé avec des technologies web
- Pour supporter les coupures de courant, notre appareil cible prioritaire est auto-alimenté et avec un écran assez grand, donc tablette d'abord et téléphone ensuite
- Le design system sera conçu selon la méthologie Atomic Design
- Les composants seront versionnés
Appareils cibles
Grâce à un fournisseur de Côte d'Ivoire, nous avons pu arrêter 2 équipements cibles sur lesquels les design étaient testés :
- Tablette Samsung Galaxy Tab A7 Lite, écran 1334*800
- Téléphone de marque Tecno, un écran de 360*806
Principes UI
Quelques principes UI pour le design system :
- Des couleurs classiques pour les actions classiques (rouge pour le danger, orange pour les warning, etc.)
- L'accessibilité n'est pas négociable
- Les actions principales sont actionnables avec des contrôles d'au moins 40px, taille qui représente le meilleur compromis densité/accessibilité sur les appareils cibles
- Une information n'est jamais véhiculée par la couleur seule
- Le design system propose des composants génériques à spécialiser pour chaque parcours métier
Librarie front-end
L'équipe technique avait fait le choix de ReactJs comme framework front-end, il nous fallait choisir une librarie de composants de base compatible.
Nous avons dédié une semaine à un benchmark de librairies front-end. Nos critères :
- Repose sur ReactJs
- Maintenue par une communauté active
- Documentation claire et complète
- Capacité de personnalisation
- Les composants ne sont pas visuellement marqués Android ou iOS
Le défi : concevoir un contrôle de filtre avec champ de recherche.
Nous avons évalué : Ant Design, Chakra UI,Semantic UI ainsi qu'une approche "in house", pour arrêter le choix sur Chakra UI.
Atome - Boutons
Nos principes UI nous ont beaucoup aidé à tamiser les variations du composant bouton.
Le composant Chakra propose 770 variations.
En éliminant les variations qui n'utilisent pas des couleurs classiques d'action, nous avons obtenu un composant générique comprennant 140 variations.
Certaines de ces variations n'ont d'ailleurs jamais été utilisées.
Puis nous avons défini notre convention pour les boutons d'action.
Nous sommes passés à 108 variations. Là aussi, certaines n'ont jamais été utilisées.
Enfin, nous avons spécialisé les boutons pour les actions les plus communes du produit.
Ces boutons spécialisés permettent : de maintenir la cohérence du produit, et d'éviter de nous poser certaines questions inutiles.
Atomes → Molécules → Organismes
L'approche Atomic Design n'a pas été inutile pour concevoir ce design system. Examinons ici comment nous avons conçu des composants plus complexes.
Notre produit faisant massivement usage de listes, nous avons consacré le temps nécessaire à réaliser un ensemble de composants pour concevoir des listes spécialisées rapidement.
Atomes
Nous démarrons avec 3 atomes : label, value et caption.
Ce n'est pas visible ici, mais ces composants ne sont pas exportés en dehors du design system.
Molécule : Number cell
Ces 3 composants sont assemblés pour former une cellule de liste, ici pour afficher un nombre (alignement à droite).
Ils sont bien sûr disponibles pour la tablette et le téléphone.
Petite astuce : pour contourner certains limitations de auto-layout, des versions avec des espaces vides ont dû être conçues, de manière à obtenir l'effet souhaité.
Organisme : BottomBar
Ce composant Number est lui même embarqué dans plusieurs composants plus conséquents, comme les listes, ou comme ici dans la BottomBar, avec des boutons et une barre de progression.
La version mobile est adaptée à l'espace disponible : boutons réduits et seulement les informations essentielles.
Templates
Pour les templates, nous avons mis en oeuvre un système de placeholders, qui permet de se réserver l'espace sur les interfaces, et de déléguer l'usage précis de cet espace aux cas métiers spécifiques.
Pour adapter le template :
- L'intégrer dans le design métier
- Adapter les onglets de la navigation secondaire
- Ajuster les propriétes aux besoins du cas métier : zone du haut, champ de recherche, etc
Design system de ~120 composants
Usage intense des possibilités de Figma : Auto-layout, Variant, Variables depuis 2023 (date de leur introduction) +versioning via l'usage du plugin Semantic-Versioning.
A l'usage - Point de vente
Composants métier
Voyons comment nous avons utilisé le design system pour créer des composants spécifiques pour le point de vente.
Ici, un assemblage de composants constitue le contenu principal de l'interface du point de vente. Cet ensemble est lui-même un composant.
Ecran final
Ce composant métier est intégré dans le template décrit ci-dessus, lui même configuré pour réfléter l'espace de vente.
Les zones noires (en haut) et grise (en bas) simulent les éléments système d'Android, le système de notre tablette cible.
En production
Le même écran en production. Certains éléments ont évolués depuis le design system auquel j'ai accès.
~200 composants métiers
Tous conçus à partir des composants du design system. Pour environ 10 modules dans l'ERP.
Enseignements clés
- 100% des designs utilisent ce system design, grâce auquel nous avons pu concevoir des nouvelles fonctionnalités en maintenant les cohérence UX et visuelle, sans avoir à tout réinventer.
- Traduction dans le code : Au début, nous avons travaillé avec Storybook pour traduire les composants Figma en code. Mais l'urgence de mettre en production un produit opérationnel et prouver notre market-fit a eu raison de cette initiative.
- UX mobile != UX écran large en plus petit : A mesure que l'enveloppe fonctionnelle de l'ERP grossissait, nous avons compris que pour tirer parti au mieux de chaque taille d'écran, nous devions faire diverger l'UX mobile et l'UX écran large. La recherche du market-fit nous a amené à remettre ce chantier à plus tard.