Un logiciel de santé se juge à son pire jour, pas dans la démo. Quand un service manque de personnel et que le téléphone ne s'arrête pas, l'écran aide ou gêne. Tout ce que nous construisons pour les soins part de ce moment.
Concevoir pour le jour chargé, pas pour la démo
Il est facile de rendre un outil de santé impressionnant en affichant chaque champ. Il est bien plus difficile de rendre évident, d'un coup d'œil, l'élément dont on a besoin pendant que le reste s'efface. Nous insistons sur cette retenue, car un écran plus calme est un écran plus sûr. Savoir quel élément doit mener, c'est exactement pourquoi nous construisons avec le terrain, pas seulement pour lui.

La fiabilité est une fonctionnalité que l'on ressent
Un système de soins parfois erroné est pire que rien, car les gens cessent de lui faire confiance. Nous traitons la disponibilité, des messages d'erreur clairs et la gestion sûre des données manquantes comme du périmètre central, pas une finition ajoutée à la fin.
L'interruption est le cas normal
Le travail de soin est un travail interrompu : un appel en pleine saisie, une alarme en pleine relève. Un logiciel pour ce monde doit rendre l'interruption sûre ; nous concevons donc pour la reprise : les saisies à moitié finies survivent, l'écran que l'on retrouve montre encore où l'on en était, et rien d'important ne dépend de quelqu'un qui termine un parcours d'une traite.
Prêt dès la première garde
Un outil qui exige une journée de formation avant d'être utile rencontrera des gens qui n'ont jamais eu cette journée. Nous visons un logiciel qu'un nouveau collègue peut utiliser dès sa première garde : le vocabulaire du service plutôt que celui du fournisseur, des valeurs par défaut qui suivent le cas courant, et les actions rares mais critiques protégées plutôt que cachées.
La conformité compte, mais elle ne peut pas être la raison pour laquelle une infirmière se bat avec l'interface. Les systèmes dont nous sommes fiers restent à la fois défendables et vraiment utilisables, à chaque garde.