Le texto qui aurait rendu l’attente supportable

Il y a quelques semaines, j’ai passé une demi-journée dans la salle d’attente d’un hôpital vétérinaire avec mon chien Tupí. Notre clinique habituelle ne pouvait pas nous prendre, ni les nombreuses autres qu’on a appelées. On a donc fait ce que tout le monde là-bas avait fait : on est allés là où la porte était ouverte… et on a attendu.

Après quelques heures ensemble, les étrangers se mettent à parler. D’abord de leurs animaux, puis de l’autre chose qu’on avait en commun : l’attente. La conversation a glissé vers l’hôpital pour humains, où tout le monde s’entendait pour dire que c’était pire. J’avais ma propre histoire à raconter : une attente de 15 heures à l’urgence, il y a quelques années, parce qu’aucune clinique ne pouvait nous prendre sans rendez-vous. Certains hôpitaux du Québec publient maintenant les temps d’attente moyens et le taux d’occupation de chaque urgence, ce qui aide avant de partir de la maison. Mais une fois à l’intérieur, personne ne peut vous dire quand votre nom va sortir.

Une femme avait une solution : «Pourquoi ils ne m’envoient pas simplement un texto quand c’est presque mon tour?»

J’avais eu la même idée il y a quelques années. Ce n’est pas une mauvaise idée. Attendre à la maison, manger, dormir, revenir quand on nous appelle. Moins de monde dans la salle, un personnel plus calme, une meilleure soirée pour tout le monde. Ce serait peu coûteux à bâtir et si un hôpital me demandait de le concevoir, je pourrais avoir un prototype très rapidement. Pourtant, il y a de très bonnes raisons de mettre le frein là-dessus.

Ce que la fonctionnalité accepte

Chaque solution porte en elle un modèle du monde. Le texto dans cette situation porte celui-ci : l’urgence est un endroit où l’on fait la file assez longtemps pour que ça vaille la peine de rentrer chez soi entre-temps. La fonctionnalité rend ça supportable, peut-être même agréable. Mais elle ne touche pas à la source du problème.

Regardons ce qu’elle laisse en place. Il n’existe aucun chemin vers les soins qui ne finisse pas à l’urgence, parce que les endroits qui absorbaient autrefois un mal de gorge, les cliniques sans rendez-vous, sont pour la plupart passés uniquement aux rendez-vous, et les rendez-vous sont généralement à des semaines de distance, quand on réussit à en trouver un. L’urgence est devenue la porte d’entrée par défaut. Le texto serait une très belle sonnette sur cette porte.

Le cadrage habituel, c’est la capacité : plus de médecins, plus de lits, et la file raccourcie. Il y a du vrai là-dedans et je ne suis pas en position de débattre de politique de santé. L’argument contraire, en tant que designer, est plus déterminé : la file est un symptôme, et le système qui la produit est un système sans porte d’entrée. Bâtir du confort dans la file, c’est assumer que la file est permanente.

La douleur et le problème sont tous les deux réels

Ce n’est pas un argument contre la fonctionnalité. La femme dans la salle d’attente avait raison. La douleur est réelle, et une équipe produit qui l’ignorerait mériterait de la perdre.

C’est plutôt un argument sur l’ordre des choses. La demande arrive presque toujours comme une solution à une douleur, formulée comme une solution à un problème : un texto, un tableau de bord, un bouton d’export, un formulaire plus rapide. La résoudre telle quelle est habituellement la façon la plus rapide de rendre un utilisateur heureux ce trimestre-ci, un «quick win». C’est aussi, assez souvent, la façon dont un processus brisé devient permanent, parce qu’une fois la douleur atténuée, plus personne n’a de raison d’aller chercher sa cause. En médecine, un traitement qui soulage le symptôme et laisse la maladie progresser a déjà un nom. Ce n’est pas «guérison».

J’ai été des deux côtés. J’ai bâti la sonnette quand le budget, le mandat et le calendrier ne laissaient aucune place pour la porte. J’ai aussi vu des équipes bâtir trois générations de sonnettes pour une porte que personne n’avait eu le droit de remettre en question.

Trois questions avant de bâtir la demande

Quand une demande arrive déjà sous forme de fonctionnalité, j’essaie de poser trois questions avant de dire oui.

• Qu’est-ce que cette fonctionnalité accepte comme permanent? Écrivez la phrase. «L’urgence est un endroit où l’on attend assez longtemps pour rentrer chez soi.» Si c’est une phrase que l’organisation n’afficherait jamais au mur, c’est une information à considérer.
• Qui devient plus silencieux si on la bâtit? Une fonctionnalité qui soulage une douleur retire aussi la pression que cette douleur exerçait sur le système. Parfois, c’est le but. Parfois, cette pression était la seule chose qui gardait le vrai problème visible.
• Quelle est la plus petite version qui traite la douleur sans fermer la question? Un texto qui consigne aussi pourquoi chaque personne est venue, et si une clinique aurait pu la voir, traite la même douleur et garde le problème de la porte sur la table. Même coût, autre modèle du monde.

Rien de tout ça n’est une raison de refuser la demande. Les organisations ont des ressources limitées, des mandats limités et une influence limitée sur les systèmes qui les entourent. Parfois, traiter la douleur est la seule chose honnête à portée de main, et le faire bien, c’est du bon travail. L’échec, ce n’est pas de bâtir la sonnette. L’échec, c’est de la bâtir et de déclarer la porte réparée.

La question ouverte

Alors, où est la ligne? Quand est-il juste de traiter la douleur plutôt que le problème, et quand est-ce qu’une fonctionnalité qui rend un système brisé vivable devient ce qui lui permet de rester brisé?

Je ne pense pas qu’il y ait de réponse générale. Je pense que la question doit être posée à voix haute, chaque fois, avant le premier wireframe. Si vous avez un cas où vous avez tracé cette ligne, dans un sens ou dans l’autre, j’aimerais savoir comment vous avez tranché.