Use Case 02

Projet
Client
Rôle
Équipe
Durée
Outils

Outil de gestion pharmaceutique
Loblaw
Designer UX/UI
3 designers, 1 lead, 8 PA/PO, dev team
2 ans ½
Figma, Jira, Miro

Hook

Repenser de zéro un logiciel pharmaceutique que personne n'avait challengé depuis 2009 dans un contexte de résistance.

Mandat

Concevoir les interfaces d'un logiciel pharmaceutique — gestion des ordonnances, des stocks, des équipes et des patients

Démarche

1. Audit du logiciel Healthwatch
2. Lire les documents d'observation terrain
3. Communiquer avec PO/PA, comprendre les enjeux et créer des écrans à partir de user stories

1

Audit du logiciel en place

Healthwatch fonctionnait, ce qui était le premier problème.
Treize ans d'utilisation qui ont créé une familiarité absolue avec cet outil parfois incohérent, peu sécurisé et désuet. Dans mon processus, j'ai audité des interfaces existantes du logiciel pour avoir un regard critique. Voici un exemple d'analyse heuristique appliquée:

Accessibility —

UX / Usability —

Architecture de l’information

Notes:

② Unités incohérentes — Mélange pouces/kg sans option de bascule. Gymnastique mentale, fatigue ③ "Race" présélectionnée — valeur par défaut "Caucasian" sans justification clinique ni contextuelle — éthiquement contestable (médicalement aussi?) ⑤ Modale qui bloque le formulaire — Impossible de consulter et corriger les données sources pendant le calcul — architecture fondamentalement cassée.

2

Observation

Les documents de recherche terrain ont directement influencé les décisions de design. Le parcours du panier physique en pharmacie est devenu un Virtual Basket nominatif — composant central de l'architecture de l'interface.

L'éclairage intense des pharmacies, source de fatigue oculaire et d'erreurs de saisie, a motivé le choix du mode sombre par défaut. J’ai eu l’occasion de présenter un exemple d’écran. Les retours étaient très engageants mais l’idée a été mise de côté.

3

Analyse heuristique

Critiques

Layout split 30/70 déséquilibré
En environnement lumineux, la double colonne et la densité d’information augmentent la charge cognitive dès l’ouverture de l’interface.
Hiérarchie typographique absente
Tous les textes ont le même poids visuel, rendant le scan rapide d’une fiche patient presque impossible.
Mauvais feedback d'état ou de validation
L’absence d’états clairs dans les champs de formulaire augmente le risque d’erreurs de saisie à impact clinique

Modérées

Toolbar surchargée et non priorisée
Toutes les actions partagent le même niveau visuel, sans distinction entre actions primaires et secondaires.
Navigation par onglets peu lisible
Faible contraste donc onglets actifs difficiles à identifier, surtout en environnement lumineux

Mineures

Légende latérale illisible
Plusieurs séries deviennent difficilement lisibles en environnement lumineux , le contraste couleur/fond insuffisant.
Checklist sans état initial clair
Cases à cocher qui manquent de différenciation visuelle = états sélectionnés difficiles à repérer rapidement.

4

Étape de Design

Le mindset durant cette phase de travail était de trouver des solutions aux problèmes identifiés. Des contraintes se sont dressées au fil du temps. Ce projet m'a confronté à des contraintes réelles et variées — développeurs déjà en production à mon arrivée, processus qui oscillait entre Agile et Waterfall, accès aux utilisateurs refusé pendant deux ans. Autant de frictions qui ont exigé autant d'adaptations: négocier les priorités, documenter pour convaincre, avancer avec beaucoup d’incertitude. C'est sur ce projet que j'ai le plus appris à designer dans la “résistance”.

Finalement, plus le temps passe et plus je réalise que les contraintes n'ont pas ralenti le projet — elles l'ont façonné.

Voici comment:

5

Exemples décisions clés

Système de validation des dosages

Dans un logiciel pharmaceutique, une erreur de saisie n'est pas un bug UX — c'est un risque patient. J'ai conçu un système de validation à deux niveaux basé sur la sévérité de l'erreur :

Orange — erreur de point probable (1.5 vs 15). Warning visible, sans blocage complet. L'utilisateur est alerté, pas paralysé.
Rouge — chiffre incohérent (50mg vs 500mg). Overlay complet. Le message affiche le chiffre saisi et demande à l'utilisateur de le retaper avant de continuer.

La logique derrière la resaisie : un clic "confirmer" se fait en automatisme. Retaper le chiffre force une lecture active — impossible d'ignorer l'erreur sans la traiter consciemment.

= Forced vérification Baisse des erreurs cognitives

De "Sexe" à Sexe / Genre / Pronoms

Le logiciel ne distinguait pas le sexe biologique et genre. J'ai levé le flag face à de la résistance interne et porté l'argument auprès de la directrice de l’expérience numérique chez Loblaw: ne pas inclure ce champ, c'est exclure une partie de la patientèle.

Après engagement du DEI, trois champs ont remplacé l'unique champ "Sexe" :

Sexe — information clinique, nécessaire pour les dosages et interactions médicamenteuses
Genre — identité de la personne
Pronoms — comment le staff s'adresse au patient au quotidien

Trois concepts distincts. Les fusionner aurait créé de la confusion clinique. Les ignorer aurait exclu des patients.

= Design inclusif Impact systémique

6

Exemples de UI

Sur demande (confidentialité)

7

Résultats

Lors des tests utilisateurs — menés deux ans après le début du projet — les retours des pharmaciens ont été positifs. L'interface était jugée ergonomique, lisible et nettement supérieure à Healthwatch. Certains écrans ont nécessité des ajustements, mais la direction était validée.
Le projet a été mis de côté pour des raisons budgétaires. Mais certaines décisions ont survécu.
En quittant le projet, la directrice de l’expérience numérique chez Loblaw m'a dit de retenir que grâce à ce travail, le logiciel avait monté en inclusion. Pour moi, en tant que designer, c'est la validation qui compte le plus — pas le déploiement.

8

À refaire (différemment)

Pousser vers des tests d’utilisateurs dès le départ — pas après deux ans. Et refuser de livrer des maquettes tant que les développeurs codaient en parallèle sans maquettes finalisées. Sur ce projet, l'ordre des opérations a coûté des millions. Malheureusement, le design ne peut pas réparer en aval ce qui a été cassé en amont.

Top