Design : Conception centrée sur l’homme dans la technologie hospitalière

Si tu as déjà lu La conception des choses de tous les jours par Donald Norman, vous avez probablement entendu parler du terme «conception centrée sur l’homme». En termes simples, la conception centrée sur l’homme consiste à concevoir des choses pour les utilisateurs humains. Cela peut sembler une tâche évidente et simple, mais ce n’est vraiment pas le cas, et est souvent considéré comme acquis.

Dans Fait pour coller par Chip et Dan Heath, ils introduisent l’idée de «La malédiction de la connaissance». Vous êtes maudit de connaissance lorsque vous ne pouvez plus vous mettre à la place de quelqu’un qui ne sait pas ce que vous savez. Lorsque vous essayez d’expliquer quelque chose à quelqu’un, vous faites toutes sortes d’hypothèses sur ce que l’autre sait. Par conséquent, l’autre personne a du mal à comprendre ce que vous essayez de lui expliquer, sans faute de sa part.

La conception centrée sur l’homme consiste à concevoir des choses avec la mentalité selon laquelle les personnes qui utilisent ce que vous concevez ne savent peut-être pas tout ce que vous pensez qu’elles savent. Cela peut inclure des choses aussi subalternes et inoffensives que des portes (êtes-vous censé pousser ou tirer la porte pour l’ouvrir?), Ou cela peut inclure des situations de vie ou de mort, telles que les contrôles de centrales nucléaires (que fait ce gros bouton jaune?) .

Il est regrettable que les designers soient souvent tenus pour acquis, en particulier dans le domaine de la technologie. Beaucoup de gens semblent penser que le design consiste uniquement à rendre les choses jolies. Cela peut avoir des conséquences désastreuses, en particulier dans l’industrie informatique des soins de santé – par exemple, si une interface utilisateur mal conçue a entraîné la saisie d’informations incorrectes par un professionnel de la santé dans un système électronique.

En tant que personne qui voulait pénétrer moi-même dans l’industrie informatique des soins de santé il y a environ trois ans, je voulais me démarquer des autres programmeurs, qui peuvent considérer le design comme un métier de niveau inférieur. Je voulais mettre l’accent sur la conception centrée sur l’homme, plutôt que de se concentrer uniquement sur la capacité technique. Heureusement, j’ai eu l’occasion de le démontrer dans le cadre du processus d’entrevue pour une entreprise de logiciels de santé pour laquelle je voulais vraiment travailler.

Il y a quelques années, j’ai eu l’opportunité de rencontrer le PDG d’une société de logiciels de santé pour laquelle je souhaitais travailler. À l’origine, la réunion était censée être pour le café, et je voulais choisir le cerveau du PDG sur ce que l’entreprise a fait. Cela a fini par devenir ma première entrevue avec l’entreprise après qu’il m’a présenté un gestionnaire qui embauchait.

J’ai reçu un rappel après ma première entrevue et on m’a demandé de préparer une démonstration pour ma deuxième entrevue dans deux semaines. Ils ont gardé les exigences très ouvertes: tant qu’il utilisait leur logiciel (un moteur d’intégration du système de santé) d’une manière ou d’une autre, et tant qu’il mettait en évidence mes propres compétences que je pense que j’apporterais à l’entreprise, alors cela suivait leurs exigences.

Avant même de penser aux types de technologies que j’utiliserais pour effectuer ma démo, j’ai d’abord pris quelques pas en arrière. Je voulais répondre à ma démo pour essayer de résoudre une sorte de problème dans l’informatique de santé, et je voulais me concentrer sur le processus de recherche de solutions.

En d’autres termes, je voulais construire quelque chose qui résolvait un vrai problème, plutôt que de construire quelque chose qui était axé sur la technologie utilisée. Quelle que soit la technologie utilisée, la solution au problème doit être résolue, et non l’inverse.

Après avoir regardé une vidéo YouTube montrant Travis Neilson utilisant le design thinking pour résoudre un problème, J’ai pris quelques notes sur ce à quoi ressemblerait le processus:

1. Découvrir: Définissez et comprenez le problème en utilisant l’empathie pour identifier les besoins et affiner la concentration.
2. Idée de génie: Utilisez les connaissances acquises lors du processus de découverte pour trouver des idées pour résoudre des problèmes (10 fois vos idées).
3. Prototype: Communiquer des idées et des solutions aux problèmes en utilisant les connaissances acquises dans les étapes précédentes.
4. Répéter.

Étant un nouveau diplômé universitaire à l’époque, je n’avais certes aucune expérience dans l’industrie informatique des soins de santé. En fait, mon diplôme n’était même pas lié au développement de logiciels – je me suis spécialisé en astrophysique.

Pour commencer, j’ai commencé à faire des recherches sur l’informatique de santé. Quels types de technologies ont été utilisées et comment tout cela s’inscrit-il dans le contexte des soins de santé? J’ai lu des DME et des DSE, comment les données des patients étaient gérées et comment les fournisseurs de soins de santé utilisaient la technologie des soins de santé.

Après une semaine entière de recherche (tout en apprenant également à utiliser le logiciel que je devais utiliser dans ma démo), je suis tombé sur des idées pour ce que je devais construire.

J’ai ensuite rapidement réalisé que je me concentrais trop sur la partie technologique – exactement ce que j’essayais d’éviter au départ. Je devais me concentrer moins sur les technologies utilisées et davantage sur les problèmes à résoudre.

Pour l’instant, je devais ignorer l’informatique de santé et en apprendre davantage sur ce que les professionnels de la santé font régulièrement. J’avais besoin d’en savoir plus sur les problèmes auxquels ils étaient confrontés. J’avais besoin de faire des recherches sur les utilisateurs.

Faire des recherches sur les utilisateurs

À cette époque, je venais de tomber malade. J’ai rendu visite à mon médecin de famille et j’ai profité de l’occasion pour lui poser des questions sur la façon dont il utilisait régulièrement la technologie. Je lui ai également demandé quels types de problèmes il rencontrait avec son flux de travail.

Par la suite, je me suis également souvenue que j’avais quelques amis qui avaient étudié les soins infirmiers et qui venaient tout juste d’entrer sur le marché du travail. J’ai contacté quelques-uns d’entre eux et leur ai posé des questions sur les problèmes et les difficultés auxquels ils étaient confrontés dans leur travail.

Rétrospectivement, ils étaient d’excellents sujets de recherche sur les utilisateurs, car ils commençaient tout juste leur travail et n’avaient pas encore connu «la malédiction ou la connaissance». Ils peuvent avoir eu des idées que ceux qui ont plus d’expérience peuvent ignorer, par exemple.

À partir de ces discussions, j’ai pris les notes suivantes:

• Les travailleurs de la santé ne connaissent généralement pas les détails techniques de bas niveau des technologies qu’ils utilisent – ils traitent la technologie comme un outil qu’ils utilisent, et rien de plus.
• De nombreux hôpitaux s’orientent actuellement vers la mise en œuvre d’une technologie moderne pour communiquer des informations importantes.
• Les médecins de famille passent lentement aux DSE – bon nombre d’entre eux conservent toujours les renseignements sur les patients dans des classeurs et envoient des renseignements sur les patients par télécopieur.
• Un gros problème auquel les infirmières sont confrontées aux urgences est de savoir comment améliorer efficacement le processus décisionnel. Par exemple, il est nécessaire de mieux organiser et de gérer plus facilement les informations entrantes (c’est-à-dire de trier les patients entrants).
• S’appuyant sur mon expérience de bénévolat dans un hôpital, je me suis également rappelé que de nombreuses interfaces utilisateur sur les ordinateurs avec lesquelles les prestataires de soins de santé devaient interagir étaient difficiles à lire.

Le grand aperçu que j’ai recueilli de tout cela était qu’il y avait une opportunité de résoudre un problème important dans les salles d’urgence, d’autant plus que les hôpitaux s’orientent vers l’intégration de la technologie moderne dans leurs flux de travail.

Les prestataires de soins de santé doivent être en mesure de prendre des décisions rapides et éclairées sous le stress. La connaissance des antécédents des patients est cruciale lors du traitement des nouveaux patients aux urgences. Ils doivent également prendre rapidement des décisions importantes en fonction des besoins et des priorités. Le problème que j’essaierais de résoudre, par conséquent, était d’améliorer en quelque sorte le processus décisionnel dans les services des urgences.

Maintenant que j’avais un aperçu réel des problèmes réels auxquels les fournisseurs de soins de santé étaient confrontés, il était temps de réfléchir à la façon d’essayer de résoudre certains de ces problèmes.

Il existe de nombreuses techniques de brainstorming, mais une technique que j’ai utilisée basée sur l’observation Travis Neilson était d’essayer de «10x» mes idées. Cette technique implique de commencer avec n’importe quelle idée et d’essayer de trouver 10 autres idées. Peu importe à quel point les idées étaient folles, essayez toujours de « Oui et.. » les idées, l’une après l’autre.

Les principaux points sur lesquels j’ai essayé de me concentrer avec mon remue-méninges étaient les moyens de permettre aux travailleurs de la santé d’obtenir rapidement des informations médicales importantes pour les patients qui se présentent aux urgences, comment améliorer la façon dont les informations sur les patients sont affichées pour les travailleurs de la santé, ce qui faciliterait la tâche. pour qu’ils lisent (en particulier lorsqu’ils sont en situation de stress), et pour rendre plus efficace le triage des patients entrants afin qu’ils puissent se concentrer d’abord sur les cas graves.

L’objectif du prototypage n’est pas nécessairement de proposer un produit parfait qui résout immédiatement les problèmes de chacun, mais d’essayer de communiquer des idées et des solutions aux problèmes en utilisant les connaissances acquises, en gardant à l’esprit qu’il s’agit d’un processus itératif. Cela implique de définir des user stories, d’esquisser des armatures ou des diagrammes, de construire rapidement un prototype, puis de tester ce prototype.

De tous les brainstormings que j’ai faits, je me suis retrouvé avec l’idée de construire une petite application qui permettrait aux professionnels de santé de réaliser les user stories suivantes:

1. Capable de rechercher rapidement les informations d’un patient dans une base de données et d’afficher ces informations dans une interface conviviale.
2. Permettre à l’agent de santé de saisir des informations supplémentaires, puis de donner une note au patient en fonction de la gravité de son état lorsqu’il entre dans une salle d’urgence.
3. Il y aura un tableau de bord qui répertorie tous les patients qui sont venus aux urgences, affichant clairement leurs informations et la gravité de leur état (en utilisant le système de notation), pour permettre aux travailleurs de la santé de se concentrer d’abord sur les cas importants.

Bien qu’il s’agisse d’une solution très basique, c’était un point de départ parfait pour construire une démo pour mon entretien. J’utiliserais le moteur d’intégration du système de santé que j’apprenais à utiliser pour interroger une base de données et retourner les informations dont j’avais besoin. Je pouvais alors utiliser certaines compétences de base en développement Web que j’avais à construire un tableau de bord simple pour afficher et saisir plus d’informations.

Après avoir esquissé quelques idées sur la façon dont tout cela ressemblerait, je suis venu avec les wireframes suivants montrant le flux de travail général de l’application:

1. Lorsqu’un professionnel de la santé ouvre l’application, il verra une page d’accueil avec deux gros boutons, indiquant s’il souhaite ajouter un nouveau patient ou afficher les patients actuels dans l’urgence.
2. S’ils choisissent d’afficher les patients actuels, ils sont directement dirigés vers l’écran d’état du patient.
3. S’ils choisissent d’ajouter un nouveau patient, ils seront dirigés vers un écran qui leur permettra de rechercher des informations sur le patient dans la base de données.
4. Une fois qu’ils ont trouvé le patient, ils peuvent entrer des informations sur l’état du patient et attribuer une note de 1 à 5 sur la gravité de l’état du patient.
5. Lors de la saisie de ces informations, ils sont dirigés vers l’écran d’état du patient avec tous les patients actuels dans l’urgence, avec leurs informations et leur état clairement présentés sous la forme de la notation 1 à 5 qu’ils avaient entrée à l’étape 4.

J’ai essayé de rendre cette interface aussi facile à lire que possible, avec de grandes polices, de gros boutons, beaucoup d’espace, et j’ai également essayé de rendre l’interface visuellement attrayante.

Une fois que j’avais tout planifié, je suis allé de l’avant et j’ai commencé à écrire du code (enfin!). Sans entrer dans trop de détails, j’ai utilisé Bootstrap et AngularJS pour le frontend. Le backend a été géré par le moteur d’intégration, que j’ai utilisé pour servir les pages Web et interroger une base de données SQLite que j’utilisais pour stocker les informations des patients.

J’ai fini par tirer presque toute la nuit la veille de mon entretien pour que le prototype soit opérationnel. Heureusement, l’idée et savoir quoi construire était là où se trouvait la majorité du travail. C’est là que je voulais que l’objet de mon interview soit.

Le code que j’avais mis en place n’était pas parfait, ou tout ce que je considérerais même comme bon. C’était très compliqué, il n’y avait pas de gestion des erreurs pour les entrées invalides, ne tenait pas compte des cas tels que lorsque des noms identiques existaient dans la base de données des patients et aucune mesure de sécurité n’était mise en œuvre. Mais cela a fonctionné comme un prototype.

L’entretien s’est très bien passé. J’y suis allé avec la mentalité que je n’allais probablement pas obtenir le travail, car je n’étais probablement pas qualifié pour le travail (j’étais un majeur en astrophysique, après tout). Je voulais l’utiliser comme une opportunité pour ajouter quelque chose à mon portefeuille, ainsi que potentiellement réseauter davantage avec le gestionnaire d’embauche. Si quoi que ce soit, j’ai beaucoup appris tout au long de ce processus, et c’était déjà une grande victoire pour moi.