Dans le domaine des dispositifs médicaux numériques (et de manière générale des logiciels, site web et application), la réussite d’un produit ne repose pas uniquement sur sa conformité réglementaire ou sa robustesse technique. Elle dépend aussi de son adéquation avec les besoins des utilisateurs. Pour y parvenir, la collaboration entre différentes expertises est essentielle.
‍

Avant de rentrer dans le vif du sujet, voici un rappel des rôles principaux impliqués dans ce processus :

• Le Product Manager (PM) : il est garant de la vision produit. Il coordonne les besoins du marché, les retours utilisateurs, les objectifs business et les contraintes réglementaires. Il est souvent au cœur des arbitrages entre UX, technique et utilisateurs.
• L’UX/UI Designer : il conçoit l’expérience et l’interface utilisateur, en s’appuyant sur des méthodes de recherche, de test et d’itération. Il collabore de près avec les développeurs front-end pour s’assurer que l’intention de design soit bien traduite dans le produit final.
• Les Développeurs :
○ Front-end : ils traduisent graphiquement les maquettes et gèrent les interactions visibles côté utilisateur.
○ Back-end : ils gèrent les données, la logique métier et les connexions avec les bases. Leur rôle est crucial, notamment lorsqu’il s’agit de créer les endpoints nécessaires pour faire vivre les interfaces imaginées côté UX.  

Ce qui suit est un exemple de processus collaboratif construit et affiné au fil des projets, en collaboration avec des équipes techniques (front et back) et des PM.

Il ne s’agit pas d’une vérité universelle, mais d’un cadre de travail éprouvé qui peut servir de point de départ. Chaque équipe ayant ses outils, son organisation et ses contraintes, rien ne remplace une discussion en amont avec les développeurs et le PM pour ajuster les méthodes, poser les bonnes bases de communication et construire ensemble le bon processus pour le projet.  
‍

‍1. Comprendre l’existant

Lorsque le logiciel est déjà en production, la première étape consiste à analyser ce qui fonctionne… et ce qui coince. Deux approches sont possibles (souvent combinées) :
‍
• Des entretiens utilisateurs, des tests utilisateurs, des questionnaires, des journaux de bord…  pour recueillir des retours concrets sur les points de friction.
• Un audit UX de l’interface existante, pour identifier les problèmes de navigation, de compréhension, ou d'accessibilité.

À cette étape, il est aussi utile de mesurer une métrique de référence (NPS, CSAT, CES, etc.), de façon globale ou ciblée (ex. : effort pour filtrer un dossier, compréhension du menu, etc.), pour pouvoir évaluer les améliorations futures.  

Le PM est souvent une source précieuse d’insights : il concentre une grande partie des retours utilisateurs.  


‍2.  Définir les parcours utilisateurs (user flows)

Avant même de concevoir des maquettes, les parcours utilisateurs sont définis sous forme d’user flows. Ces schémas simples permettent de visualiser toutes les étapes clés, les actions possibles et les différents scénarios (succès, erreur, exception…).

Exemple : “Que se passe-t-il si l’utilisateur ne trouve pas son document ?” ou “S’il fait une faute de frappe ?”  
‍

‍3.  Concevoir des pistes : DRAFT & faisabilité

Sur la base des enseignements et des users flows validés, des maquettes rapides (DRAFT) sont réalisées, souvent sur une page ou un flux spécifique. L’objectif n’est pas encore la perfection visuelle, mais la proposition d’idées concrètes à discuter et proposer aux utilisateurs.  

Dès cette étape, une discussion avec les développeurs (notamment front-end) est essentielle : est-ce techniquement faisable ? Combien de temps cela prendrait ? Le PM vient ajouter sa vision business et ses contraintes de planning. Cela permet d’éviter de fausses bonnes idées et de s’ancrer dans le réel.  (Photo draft avec TO GO / OUT)  


‍4. Tester avec les utilisateurs

Une fois la faisabilité validée, les maquettes sont testées avec des utilisateurs finaux. En général, il s’agit de prototypes interactifs car cela permet aux testeurs de mieux se projeter.

‍Tester des écrans non validés techniquement est fortement déconseillé : Proposer une solution qui semble idéale mais qui ne pourra jamais être développée, c’est risquer de générer de la frustration chez les utilisateurs, même si l’expérience en elle-même est améliorée.  
‍
Les retours sont ensuite synthétisés et présentés à l’équipe.  


‍5. Synthétiser les retours et documenter

Les résultats des tests donnent lieu à un rapport clair, destiné à :
• Transmettre les apprentissages à toute l’équipe
• Appuyer les décisions auprès des développeurs et du PM
• Garder une trace du raisonnement derrière chaque choix  

Une ou plusieurs slides de synthèse sont toujours présentes au début du rapport. Elle est souvent la plus lue, tandis que le détail est utile au PM ou pour les arbitrages plus complexes.  

Partager la connaissance utilisateur avec les équipes permet aussi de répondre à certaines critiques internes (“C’est logique, on peut le laisser là”) en s’appuyant sur des retours concrets (“13 utilisateurs sur 15 ne comprenaient pas cette étape”).  


‍6. Recommandations et priorisation

Le rapport contient également des recommandations UX. Celles-ci sont revues avec le PM et l’équipe tech pour évaluer ce qui sera effectivement mis en œuvre.

Un atelier rapide de priorisation est généralement organisé, basé sur trois critères :
• Impact utilisateur
• Effort technique
• Ressources disponibles  

Les actions sont ensuite classées en trois catégories claires : Now / Next / After. Cela facilite les arbitrages et permet de planifier de manière réaliste.  

De plus, prendre en compte l’évolution des écrans dans le temps permet d’anticiper les évolutions à venir et d’éviter de “tout casser” à chaque nouvelle fonctionnalité.
 

‍7. Itération ou passage en production

Selon l’avancement du projet, deux chemins sont possibles :
• Itérer : une nouvelle version est testée suite aux retours utilisateurs.
• Commencer les maquettes ready-to-dev : on entre alors dans la phase de design final, avec des maquettes prêtes pour le développement (PROD).  

Contrairement aux prototypes cliquables utilisés pendant les tests utilisateurs, les maquettes de production ne sont pas pensées pour "être jouées", mais pour être lues et comprises rapidement par les développeurs.

L’objectif est de donner aux développeurs toutes les informations dont ils ont besoin en un coup d’œil.

Plutôt que de leur demander de naviguer dans un prototype interactif, chaque état d’un écran est dupliqué et présenté à part. Par exemple, pour une fonctionnalité de recherche de dossier, on aura plusieurs écrans distincts :
• L’écran initial
• L’écran avec le champ en hover
• L’écran avec du texte saisi
• L’écran après validation de la recherche
• L’écran en cas d’erreur (aucun résultat, faute de frappe, etc.)  

On travaille donc par étapes, en représentant visuellement chaque changement d’état, chaque interaction possible, de manière isolée. Cela évite toute ambiguïté sur le comportement attendu et facilite le développement.

Tous ces états sont organisés et documentés clairement dans un logiciel de maquettage (Ex: Figma), ce qui évite aux développeurs de devoir lancer le prototype et reproduire toutes les étapes pour visualiser l’interaction ou les différents états.  

En complément, des user scenarios accompagnent les maquettes. Ils décrivent pas à pas les interactions et leurs variantes (erreurs, champs vides, actions secondaires, transitions, taille maximale d’un élément etc.). Ils servent de checklist fonctionnelle pour s'assurer que tout est couvert côté dev.

Et si certaines animations sont nécessaires, il ne faut pas hésiter à le préciser sur les maquettes : une description textuelle de l’animation et le chemin à suivre pour la voir.  
‍

‍8. Phase de développement : vérification et ajustements

Une fois le développement terminé, avant la mise en production, un point est fait avec les développeurs afin s’assurer que l’implémentation correspond bien aux maquettes, et trouver des alternatives réalistes si un point se révèle plus complexe que prévu.

Les développeurs apportent également un regard critique, basé sur leur expérience : ils repèrent parfois des manques ou des optimisations possibles dans les maquettes.  
‍

‍9. Mise en production et mesure de l’impact

Une fois les écrans mis en ligne, une nouvelle phase de mesure peut être lancée. On vient comparer les résultats avec la métrique initiale récolté lors de la première étape. Cela permet de valider les améliorations apportées et de documenter l’impact du travail UX dans le temps.  

‍10. Organisation et traçabilité dans un logiciel de maquettage

Une bonne organisation des fichiers est essentielle pour fluidifier la collaboration entre designers, développeurs et PM. Voici une structure qui a fait ses preuves :

👉 Fichier DRAFT : pour les tests et les idées

Chaque page correspond à un écran (ex : Homepage), et les différentes versions sont organisées dans des sections sur cette même page : V0.1, V0.2, etc.
• Les versions « To test » ou « To develop » sont identifiées clairement.
• Les versions OUT (non retenues) sont également notées, avec la raison du rejet indiquée (ex : trop complexe à développer, incompréhensible pour les utilisateurs, etc.).  
‍

👉 Fichier PROD : pour les écrans validés ou en cours de développement

Ce fichier est celui que les développeurs utilisent au quotidien.
• Chaque page correspond à un écran.
• Il n’y a pas de versioning ici : seuls les écrans validés pour le développement sont présents.  
‍

👉 Fichier OLD : pour archiver les anciennes versions

Ce fichier reprend la même structure que le fichier DRAFT : une page par écran, des sections par version (V1.0, V1.1, etc.).

• Chaque évolution est documentée avec la raison de la modification (ex : "ajout d’un champ", "retour utilisateur", etc.).  


Cette organisation permet aux développeurs d’avoir tous les écrans à jour dans un seul fichier (PROD), tout en garantissant une traçabilité complète des itérations et décisions de design.  
‍

‍Conclusion

Un bon produit ne se conçoit pas dans une bulle. La réussite passe par un travail collaboratif et structuré entre UX, PM et développeurs dès les premières idées jusqu’à la mise en production. Ce processus n’est qu’un exemple parmi d’autres, issu de l’expérience et d’une volonté constante de mieux faire ensemble. L’essentiel reste d’échanger en amont, d’écouter les contraintes de chacun, et de construire pas à pas un cadre adapté à votre projet, vos outils, et votre réalité d’équipe.