Sam est arrivée avec une thèse de doctorat complète, des articles de soutien et des présentations sur le signalement des incidents dans des organisations complexes. La première phase s’est concentrée sur la traduction de ce matériau en un modèle conceptuel prêt pour le produit grâce au domain learning. Nous avons parcouru ses chapitres principaux, extrait les entités et relations clés, et cartographié la façon dont les incidents passent de la saisie initiale à l’évaluation, l’escalade et le suivi.

Lors de plusieurs sessions de travail, nous avons vérifié notre synthèse avec elle. Nous avons regroupé les motifs récurrents issus de la recherche, tels que les catégories d’incidents, les échelles de gravité, les événements de type near miss et les actions de suivi. Ceux-ci sont devenus l’ossature du langage produit. Au lieu d’un outil de signalement générique, nous disposions désormais d’un modèle clair de ce qui devait être saisi, dans quel ordre et avec quelles dépendances.

Cette phase a fonctionné comme une démarche de evidence based UX design appliquée à un corpus académique. Elle a également offert à Sam un espace neutre pour distinguer les idées à intégrer dans la première version de celles qui pouvaient attendre. Les fondations ainsi créées ont soutenu la conception de prototypes pour des fondateurs devant démontrer à la fois une expertise métier approfondie et un plan d’exécution réaliste.

Avec le modèle conceptuel en place, nous nous sommes tournés vers la structure lors des Sandbox Experiments. L’objectif était de concevoir une architecture de l’information capable de gérer différents types d’incidents sans submerger des utilisateurs qui ne déposent peut-être un rapport qu’occasionnellement. Au cours de la première semaine, nous avons exploré trois concepts d’architecture à travers option space mapping, allant d’un flux très linéaire à une approche plus modulaire où des blocs réutilisables apparaissent ou disparaissent selon le contexte.

Nous avons utilisé des diagrammes de flux simples pour comparer les options. Avec Sam, nous avons examiné comment chaque structure se comporterait pour des incidents mineurs, des blessures graves et des rapports de near miss. Un parcours type commençait par une courte description, puis se divisait en sélection de la gravité, zone du corps, actions immédiates, pièces jointes de preuves et notification du superviseur. Si la gravité dépassait un certain seuil, des champs supplémentaires pour le traitement médical et la planification du suivi apparaissaient.

Après avoir analysé les compromis grâce au tension-driven reasoning, nous avons choisi une architecture modulaire qui conserve une structure centrale cohérente tout en ajoutant des sections conditionnelles. Elle est devenue l’architecture UX pour les applications mobiles devant allier clarté et flexibilité. Cela a donné à Sam un moyen concret de discuter du périmètre avec de futurs développeurs, car elle exprimait à la fois les éléments stables et les parties configurables du système.

En parallèle du travail structurel, nous avons mené des échanges dédiés à la direction. Sam était une first-time founder et souhaitait comprendre comment une idée fondée sur la recherche devient un produit pouvant être conçu, vendu et maintenu. Ces sessions étaient structurées, pas inspirantes. Nous avons parcouru la stratégie produit pour les first-time founders dans sa situation, en utilisant son idée comme point de référence.

Nous avons discuté de plusieurs options de déploiement. L’une se concentrait sur un flux central unique pour la déclaration et la revue des incidents au sein d’un nombre limité d’organisations pilotes. Une autre intégrait plus tôt l’analytics et le reporting, ce qui aurait nécessité davantage d’investissement, mais pouvait séduire certains acheteurs. Nous avons également évoqué des options de partenariats avec des cabinets de conseil en sécurité et des organismes de formation déjà présents dans les entreprises.

Tout au long du processus, nous avons relié chaque orientation stratégique au prototype et au UX design pour les start-ups qui opèrent sous des contraintes de ressources. À la fin de cette phase, Sam disposait d’une roadmap simple indiquant quoi construire en premier, quoi reporter et comment chaque choix influencerait les coûts, le calendrier et les risques. Le travail de design et la réflexion stratégique se sont renforcés mutuellement au lieu d’évoluer sur des trajectoires séparées.

Pour vérifier que nos hypothèses tenaient également en dehors de l’équipe projet, nous avons mené une session de tests utilisateurs pour des produits en phase initiale avec un petit groupe de personnes qui gèrent régulièrement des incidents sur le lieu de travail. Chaque participant devait enregistrer un incident récent ou plausible, puis examiner un incident existant et ajouter une note de suivi. Nous avons observé leurs parcours, leurs questions et leurs points d’hésitation.

Les tests ont fait ressortir quelques thèmes récurrents. Certains utilisateurs hésitaient lorsque le système passait de formulaires courts à des formulaires plus longs, nous avons donc ajusté l’introduction et réorganisé certaines sections afin de créer une progression plus claire. Le regroupement des pièces jointes et des détails contextuels a réduit les allers-retours. La simplification de certaines règles de branchement a permis aux utilisateurs de mieux comprendre pourquoi de nouveaux champs apparaissaient.

Ces ajustements n’ont pas modifié la recherche sous-jacente, mais ont permis de mieux l’aligner sur les comportements observés. Pour Sam, c’était une démonstration concrète de la manière dont un UX fondé sur la recherche et les preuves issues du terrain se renforcent mutuellement. Le prototype mis à jour lui a donné davantage de confiance pour expliquer le concept, car elle savait qu’il avait été utilisé par des personnes en dehors de son propre cercle.