Avant de définir les écrans, l’équipe a examiné la littérature académique sur les dossiers de santé électroniques et l’analytique en santé. Parmi trente-deux articles, dont plusieurs issus de revues telles que le Journal of Biomedical Informatics, huit études ont été identifiées comme directement pertinentes pour les décisions d’interface. Elles analysaient la manière dont les cliniciens et les chercheurs effectuent des recherches dans les systèmes de DSE, la fréquence à laquelle ils perdent le contexte lors de longues sessions, et les points où le design des interfaces de DSE ne rend pas la provenance visible.

Ces études décrivaient des comportements concrets. Les utilisateurs passent souvent d’un jeu de données cliniques structurées à des notes narratives. Ils s’appuient sur des schémas temporels dans le dossier patient, mais perdent la trace des filtres actifs. Lorsque les requêtes sont affinées à plusieurs reprises, l’historique des décisions devient opaque, ce qui nuit à la reproductibilité. Les données cliniques sont techniquement riches, mais cognitivement fragiles.

Les résultats ont été traduits en exigences pour le logiciel de recherche médicale. La plateforme de données de santé devait fournir des repères clairs de provenance, un historique de requêtes visible et une vue stable des données patient actuellement incluses. Les principes de design d’interface des DSE issus de la littérature ont été utilisés comme contraintes plutôt que comme éléments décoratifs. La plateforme devait aider les utilisateurs à comprendre où ils se situaient dans les données et comment ils y étaient parvenus.

Grâce à Sandbox Experiments, une phase de discovery de deux semaines a combiné recherche qualitative et analyse des tâches avec des utilisateurs issus de trois environnements. Quatorze entretiens individuels et trois groupes de discussion ont réuni vingt-quatre participants, dont des analystes du NHS, des chercheurs universitaires et des équipes de recherche pharmaceutique. Chaque groupe travaillait dans des cadres institutionnels et des processus d’approbation différents, mais tous devaient réaliser des analyses de données patients sur les mêmes jeux de données en santé mentale.

Les équipes universitaires ont décrit de longues procédures d’approbation éthique et d’accès aux données avant de pouvoir simplement se connecter à des logiciels de recherche clinique utilisant de vrais dossiers patients. Les équipes pharma disposaient de plus de liberté pour l’exploration précoce, mais faisaient face plus tard dans le projet à des obligations strictes de reporting et d’audit. Les analystes du NHS utilisaient des outils similaires pour l’évaluation des services et avaient besoin de limites claires entre la recherche et l’usage opérationnel. Ces réalités ont davantage façonné le design que n’importe quelle description de persona générique.

L’analyse des tâches a cartographié la séquence d’actions tout au long d’un parcours d’étude complet, de l’idée initiale à l’extraction finale. La recherche a confirmé que la confusion apparaît souvent lors des passations entre personnes ou entre étapes de gouvernance. Cette observation a conduit à un fort accent sur la continuité des workflows et des états clairs, afin que la même plateforme de données de santé puisse prendre en charge des parcours d’approbation très différents sans fragmenter l’expérience.

Pour comprendre la base des logiciels de recherche clinique, neuf outils commerciaux de Healthcare Analytics ont été benchmarkés en profondeur. Il ne s’agissait pas de prototypes universitaires, mais de produits réels utilisés dans les hôpitaux, les instituts de recherche et l’industrie. L’évaluation a porté sur les query builders, le design des interfaces EHR, les modèles d’espace de travail, les audit trails et la manière dont chaque système exposait la logique de sélection des cohortes de patients.

Plusieurs problèmes récurrents sont apparus. Certains outils n’affichaient que le résultat final d’une requête, laissant les utilisateurs incertains quant aux conditions réellement appliquées. D’autres forçaient les chercheurs à suivre des procédures fixes par étapes qui ne correspondaient pas à l’évolution des études en santé mentale dans le temps. La provenance des données était souvent cachée dans des logs techniques plutôt que présentée comme une partie de l’expérience utilisateur. Même lorsque les fonctionnalités étaient riches, l’UX des logiciels médicaux rendait difficile la confiance dans les résultats.

Le benchmark ne s’est pas contenté de critiquer les concurrents. Il a clarifié quels schémas les utilisateurs connaissaient déjà, comme les contrôles de filtres familiers, et quels problèmes structurels devaient être évités. La plateforme Akrivia a été positionnée comme une plateforme de données de santé qui rend visible le raisonnement derrière les résultats et respecte les contraintes cognitives et réglementaires de la recherche en santé mentale, plutôt que de suivre des conventions génériques de business analytics.

Sur la base de la recherche et du benchmarking, cinq modèles d’interaction distincts pour la construction de cohortes ont été proposés via option space mapping. L’un fonctionnait comme un assistant, guidant les utilisateurs à travers des étapes séquentielles. Un autre présentait la requête sous forme de blocs logiques imbriqués. Un troisième organisait les conditions autour de la chronologie du dossier patient. Les modèles restants mettaient l’accent sur la réutilisation de fragments de cohortes ou la comparaison côte à côte de variantes. Chacun représentait une hypothèse différente sur la manière dont pensent les chercheurs cliniques.

Ces modèles ont traversé six cycles de design avec une fidélité croissante, des wireframes aux prototypes interactifs. Huit sessions d’utilisabilité avec des utilisateurs du NHS, du monde académique et du secteur pharma ont testé des tâches réalistes, comme la création d’une cohorte de dépression résistante au traitement ou l’ajustement d’une cohorte existante à de nouveaux critères d’inclusion. Les participants ont été observés alors qu’ils cherchaient à comprendre des décisions passées, à modifier des conditions et à expliquer leur raisonnement à un collègue.

Le query builder final du logiciel de recherche clinique est une convergence de ces expérimentations. Il conserve la lisibilité du modèle imbriqué, reprend des repères temporels du modèle chronologique et intègre des fragments réutilisables entre projets. En termes de healthcare UX design, il offre la liberté d’explorer sans sacrifier la traçabilité, ce qui est essentiel pour la gouvernance et l’évaluation scientifique.

Au-delà de la sélection des cohortes, la plateforme devait également prendre en charge l’analyse des données cliniques dans le même environnement. La plateforme de données de santé intègre des modules de statistiques descriptives, d’exploration des corrélations et de vues comparatives entre cohortes. Les chercheurs peuvent examiner les distributions des mesures clés, suivre les trajectoires de résultats et comparer les réponses aux traitements sans exporter prématurément les données vers des outils externes.

La visualisation suit une grammaire claire adaptée aux logiciels de recherche médicale. Les graphiques basés sur le temps aident les équipes à voir comment les scores de symptômes évoluent avant et après les changements de traitement. Les vues comparatives montrent les différences de schémas de médication ou d’utilisation des services entre les cohortes. Ces vues ne sont pas des tableaux de bord décoratifs, mais des instruments de raisonnement clinique. Elles sont conçues pour qu’un statisticien, un psychiatre et un responsable de la gouvernance des données puissent tous comprendre ce qui est présenté.

En intégrant ces modules d’analytics, la plateforme réduit le nombre d’outils nécessaires pour l’analyse des données patients. Elle maintient également une plus grande partie du parcours analytique dans un environnement conçu pour la sécurité des données, la provenance et la gouvernance du NHS. Pour de nombreuses équipes, cela est aussi important que le design visuel lui-même.

Comme Akrivia sert plusieurs institutions, la plateforme devait fonctionner comme un système de données de santé multi-équipes plutôt que comme un simple outil de projet. Des workspaces, des projets et des niveaux d’autorisation ont été définis afin que les trusts du NHS, les groupes universitaires et les partenaires pharma puissent partager le même logiciel de recherche clinique sans brouiller les frontières de la gouvernance. Chaque étude s’inscrit dans un cadre clairement délimité avec ses propres règles d’approbation et d’accès aux données.

Les responsables de la gouvernance des données ont été impliqués dans la définition du modèle de demandes d’accès, d’approbations et d’audit. L’interface indique clairement quels jeux de données un utilisateur peut consulter, quel est son rôle et quelles actions sont autorisées à un moment donné. Cela est essentiel pour la conformité au RGPD concernant les données de santé sensibles. Le healthcare UX design ne vise pas ici la commodité, mais la prévention des accès inappropriés sans obliger les utilisateurs à mémoriser des documents de politique complexes.

La plateforme maintient également une piste d’audit explicite des actions analytiques, afin que les équipes de gouvernance puissent examiner comment une cohorte a été construite et comment les données cliniques ont été utilisées. Cela réduit la charge liée au reporting de conformité et donne aux institutions davantage de confiance lorsqu’elles ouvrent leurs jeux de données à un usage de recherche plus large.

Le système visuel de la plateforme Akrivia a été traité comme un élément de healthcare UX design à part entière. La plupart des écrans offrent une surface neutre et calme pour un travail concentré avec des données cliniques. La hiérarchie typographique est claire et aide les utilisateurs à distinguer la structure, le contenu et les contrôles sans effort conscient. Les schémas d’interaction sont cohérents entre les modules, permettant aux chercheurs de transférer leur compréhension de la construction de cohortes vers l’analytics et la gestion des workspaces.

La couleur est utilisée avec parcimonie et avec une signification définie. Dans le query builder, elle sépare les groupes logiques et met en évidence les conditions actives. Dans les vues d’analytics, elle correspond aux cohortes ou aux états de résultats plutôt qu’à des palettes décoratives. Le résultat est un design d’interface clinique qui reste lisible lors de longues sessions, facilite la supervision et la revue, et ne concurrence pas le contenu.

Pour l’UX des logiciels médicaux, cette retenue est un choix stratégique. L’environnement doit inspirer confiance aux équipes du NHS, aux universitaires et aux chercheurs du secteur pharma qui s’appuient sur l’application pour prendre des décisions importantes. Le langage de design soutient cette confiance en privilégiant la clarté, la cohérence et la lisibilité plutôt que des effets visuels expressifs.

Dès le début, les designers et les ingénieurs ont considéré la plateforme Akrivia comme un logiciel de santé durable, et non comme un prototype à court terme. Le produit est une plateforme de recherche clinique basée sur le web qui doit s’intégrer aux pipelines de données et aux systèmes opérationnels existants. Des ateliers techniques organisés au début du projet ont clarifié les contraintes liées aux performances, à la sécurité et au déploiement, afin que les modèles d’interaction ne soient pas en conflit avec les réalités architecturales.

En parallèle, un design system a été créé pour soutenir l’implémentation et la feuille de route future. Il définit des composants pour les blocs de requête, les vues de dossiers patients, les panneaux d’analytics, la gestion des workspaces et la navigation, chacun avec des règles de comportement et des états précis. Pour les développeurs, cette bibliothèque agit comme un contrat. Elle relie les décisions de healthcare UX design à des détails d’implémentation concrets dans une forme stable dans le temps.

Pendant la phase de build, l’équipe de design est restée impliquée pour répondre aux questions, ajuster les schémas lorsque l’ingénierie identifiait des edge cases, et s’assurer que le logiciel de recherche clinique se comportait comme prévu dans des environnements réels. Cela a évité l’écart habituel entre le concept et la production et a donné à Akrivia une base pour plusieurs années d’évolution produit.