Contexte
Module SaaS de l'ERP de pharmacies pour permettre la conception de modèles d'étiquettes et affichettes personnalisés.
Durée : 6 mois à temps plein, répartis sur une année.
Rôle : Product Designer.
Equipe : J'ai travaillé étroitement avec Audrey Mandin (PO), ainsi qu'une équipe de 2 développeurs.
Enjeux
Constat : A chaque fois qu'une pharmacie a besoin de personnaliser ses étiquettes, elle appelle le support Smart-Rx qui va réaliser le travail.
- Support dérangé pour des sujets non critiques
- Une interface avec des menus surchargés par tous les modèles disponibles
Impacts :
Brief : Concevoir un éditeur d'étiquettes qui rendent les pharmacies autonomes, et décharge le support Smart-Rx.
Discovery
User research
Audrey avait déjà collecté des informations sur les problèmes rencontrés par les pharmacies pour imprimer des étiquettes.
Nous avons étudié l'ensemble des problèmes pour définir la liste des problèmes que nous souhaitions résoudre.
Je n'ai plus accès aux informations de recherche pour fournir des informations plus détaillées.
Enseignements
Enseignement clé : Pour imprimer des étiquettes, les pharmaciens démarrent par les produits, pas par le modèle d'étiquette. Le parcours utilisateur original est illogique.
Autres enseignements :
- Menus à rallonge avec tous les modèles proposés
- Difficulté à s'y retrouver parmi tous les modèles propsés
- Devoir contacter le support Smart-Rx pour tout changement
- Délai d'attente de plusieurs jours pour avoir un nouveau modèle, qui prend moins d'une heure de travail effectif (source: le support Smart-Rx)
- Les pharmacies peuvent imprimer des étiquettes pour des dizaines de produits, en une seule passe
Contraintes et worflow
Contrainte technique : le choix de basculer le front-end sur React venait d'être acté, mais la montée en compétence des développeurs aurait ralentit les développements de l'application.
Choix technique : Collégialement, avec l'équipe de développement et l'architecte technique, nous avons décidé de conserver ces développements basés sur la librairie front-end maison.
Parcours initial
Le parcours utilisateur initial était illogique. La recherche nous avait appris que les pharmaciens démarrent des produits pour imprimer les étiquettes, pas des modèles.
Nouveau parcours
Nous avons défini un nouveau parcours, plus logique, où l'utilisateur choisit d'abord les produits pour lesquels il souhaite imprimer les étiquettes, puis le modèle à utiliser.
Ce nouveau parcours nous permettait de chaîner les étapes de l'impression de manière plus efficace et intuitive, et nous permettait d'y insérer le parcours de conception de nouveaux modèles.
Wireframes et tests utilisateurs
Utilisateurs "proxy" : L'impression d'étiquettes et la conception de modèles ne sont pas des actions spécifiques du métier de la pharmacie.
Aussi, pour accélérer le go-to-market du produit, et moins déranger les pharmaciens, des salariés de Smart-Rx, non impliqués dans la conception du produit, ont testé et validé la conception.
Les wireframes ont permis de valider les 3 groupes de fonctionnalités :
- Impression d'étiquettes à partir d'une liste de produits, avec sélection des modèles.
- Création d'un modèle, en partant d'un modèle vierge ou déjà existant.
- Design graphique d'un modèle.
Les tests des wireframes ont permis d'identifier les frictions des premiers prototypes, que nous avons pu corriger avant de passer au design haute-fidélité.
Affectation groupée du modèle
Le parcours démarre des produits, mais il fallait garder la possibilité de changer le modèle sélectionné pour toute ou partie des produits.
La nouvelle approche :
- Un clic sur l'en-tête Modèle dans le tableau permet de sélectionner un modèle pour tous les produits de la liste.
- Un clic sur le modèle d'un produit permet de sélectionner un modèle spécifiquement pour ce produit.
On préserve ainsi à la fois l'efficacité maximum (affectation globale du modèle) et la spécificité d'un modèle au cas par cas.
Spécifier les dimensions
Les étiquettes sont généralement imprimées sur des planches adhésives prédécoupées, dont avec des dimensions prédéfinies. Or, comment spécifier ces dimensions et permettre le design graphique, sans alourdir l'utilisation ?
Nos premiers tests montraient que c'étaient un point clé. Mélanger les 2 aspects (dimensions et design) compliquait beaucoup la fluidité du parcours.
Pour résoudre cette difficulté, j'ai découpé le parcours en 2 étapes :
- La première partie est réservée à la manipulation des modèles, création, duplication, suppression. Et c'est ici, pour chaque modèle, que l'utilisateur va décider des dimensions finales.
- Dans la deuxième partie du parcours, c'est sur le contenu du modèle que l'on va travailler.
Les premiers tests nous ont permis de d'identifier et de résoudre les difficultés rencontrées lors d'une deuxième itération. Lors de cette deuxième itération, les parcours ont été jugés intuitifs et faciles.
Prototype haute-fidélité
Les parcours validés par nos tests, j'ai pu passer au design visuel de l'application.
Le défi portait sur l'espace de création des modèles :
- Ajouter supprimer des éléments, comme un caractéristique du produit (libellé, prix, quantité, etc), ou un message libre.
- Pour modifier les caractéristiques des éléments du modèle (police, couleur, etc).
- Enregistrer le modèle.
- Reprendre le parcours d'impression, puisque la création d'un modèle s'insère dans le workflow de l'impression.
Observation : Les pharmaciens n'impriment pas que des étiquettes, mais aussi des affiches promotionnelles, et autres supports pour faciliter la vente. Et pour ça, ils utilisent des outils répandus comme PowerPoint ou Canva.
Le choix de baser la conception sur des paradigmes d'outils de création connus, comme Canva, Figma, PowerPoint, ou Sketch, s'est donc imposé naturellement :
- A gauche, une liste d'éléments que l'on peut ajouter ou supprimer du canvas de travail.
- Au centre, le canvas de travail avec un rendu wysiwyg.
- A droite, un inspecteur de propriétés de l'élement sélectionné.
Côté UI, les défis ont porté sur la création de composants spécifiques pour :
- Afficher le rendu visuel des modèles dans le parcours de création.
- Afficher les propriétés dans l'inspecteur.
Pas d'auto-layout dans Adobe XD (outil initial), ni dans Figma au moment de la migration.
En production
Adoption
+2000 pharmacies
+30% de la base client / ~10% du marché français
Pharmacie Massé - La RochelleC'est très facile et intuitif à utiliser. Merci pour ce beau travail !
Enseignements clés
Avec cette application, nous avons appris à faire des compromis qui nous ont permis d'accélérer la conception, de faciliter le développement, et au final d'avoir un go-to-market plus rapide.
- Sur un sujet qui n'est pas métier, utiliser des utilisateurs "proxy" est aussi efficace et permet d'itérer plus rapidement sur la conception. Mais la validation avec les utilisateurs finaux reste essentielle pour garantir l'adéquation du produit aux besoins réels.
- Conserver la librairie front-end maison, et ne pas forcer la transition vers React, a permis de maintenir la maîtrise technique par l'équipe. Ce choix n'est pas gratuit, il imposera une récriture totale du code front-end quand l'application passera sur React.
Ce que je ferais différemment
- Mesurer le temps de création de modèle (baseline vs après lancement). Même si le support était le goulet d'étranglement évident, avoir des chiffres aurait permis de connaître l'impact avant/après.
- Suivre le taux de complétion des parcours pour identifier les points de blocage et améliorer l'expérience utilisateur.
- Mesurer la baisse des tickets support qui portaient sur les modèles d'étiquettes.
Pourquoi ne pas l'avoir fait
- RGPD : Smart-Rx était en cours de définition de sa politique analytics. Et dans le contexte sensible de la santé, il était totalement impossible de mettre des sondes type Google.
- Aucun outil technique, conforme à la politique de traitement des données personnelles de Smart-Rx, n'était disponible.