Apporter un meilleur processus de conception à votre organisation

En tant que concepteurs et chercheurs en expérience utilisateur (UX), la plainte la plus courante que nous entendons de la part des utilisateurs est :

« Pourquoi ne pensent-ils pas à ce dont j'ai besoin ? »

En fait, de nombreuses organisations ont des équipes dédiées à fournir ce dont les utilisateurs et les clients ont besoin. De plus en plus de développeurs de logiciels souhaitent travailler avec des concepteurs UX afin de coder des interfaces que les clients utiliseront et comprendront. Le problème est que les projets logiciels complexes peuvent facilement s'enliser dans des priorités concurrentes et une confusion sur ce qu'il faut faire ensuite.

Le résultat est une mauvaise conception qui entrave la productivité. Par exemple, l'efficacité des soins de santé est entravée par les dossiers médicaux électroniques (DME). Les plaintes concernant ces systèmes logiciels sont légion. Le Dr Steven Ugent, dermatologue basé à Boston et ancien élève de la Yale Medical School, ne fait pas exception.

Depuis 2010, le Dr Ugent a utilisé deux systèmes de DME : Avant 2010, il terminait son travail à 5 ​​h 15 chaque jour. Depuis que lui et ses collègues ont commencé à utiliser les DME, il travaille généralement entre une demi-heure et une heure et demie de plus le soir. « Je ne connais aucun médecin qui soit satisfait de son système de dossiers médicaux. Ce qui est fou, c'est que j'étais beaucoup plus efficace lorsque j'utilisais un stylo et du papier.

Les systèmes EMR sont maladroits, rigides et difficiles à personnaliser. Ugent, par exemple, ne peut pas intégrer de photos directement dans ses notes de graphique. Au lieu de cela, il doit ouvrir le dossier avec la photo de la taupe, puis ouvrir un autre dossier pour voir le texte. Cette configuration est particulièrement lourde pour les dermatologues qui s'appuient fortement sur les photos lors du traitement des patients.

Ugent résume succinctement le problème des DME :

« Les personnes qui l'ont conçu [le système DME] ne comprennent pas mon flux de travail. S'ils le faisaient, ils concevraient un système différent.

Les médecins ne sont pas les seuls à être frustrés par les logiciels maladroits. Les consommateurs et les professionnels du monde entier formulent des plaintes similaires :

« Pourquoi ne puis-je pas trouver ce dont j'ai besoin ? »

« Pourquoi rendent-ils les choses si difficiles ? »

“Pourquoi dois-je créer un login alors que je veux simplement acheter ce produit. Je leur donne de l'argent. N'est-ce pas suffisant ?

Les processus de conception défectueux sont l'un des principaux contributeurs aux logiciels maladroits. Dans cet article, nous décrirons quatre problèmes de processus de conception et expliquerons comment les résoudre.

1. Complexité
2. Syndrome de prochaine libération
3. Temps insuffisant pour les itérations de conception
4. Céder le contrôle à des fournisseurs extérieurs

1. Complexité

L'échelle, les multiples parties prenantes et la nécessité d'un code sophistiqué font partie des nombreux facteurs qui contribuent à la complexité des grands projets logiciels.

Cependant, les lois et réglementations complexes sont parfois négligées. Par exemple, l'assurance est fortement réglementée au niveau des États, ce qui ajoute une couche de complexité pour les compagnies d'assurance opérant dans plusieurs États. Les banques et les coopératives de crédit sont soumises à une réglementation tandis que les services publics doivent se conformer aux lois environnementales fédérales et étatiques.

Les produits et logiciels de santé soumis aux réglementations de la FDA représentent un défi encore plus grand. Le problème n'est pas que les règlements sont déraisonnables. La sécurité est primordiale. Les problèmes sont le temps, le budget et la planification nécessaire pour répondre aux exigences de la FDA.

Comme l'explique Jeff Horvath, Ph.D., un consultant UX possédant une vaste expérience dans le domaine de la santé : "Ces exigences ajoutent quelques ordres de grandeur à la rigueur de l'écriture des protocoles de test, de la configuration des tests, de la collecte de données, de l'analyse, des contrôles de qualité et obtenir l'approbation pour mener la recherche en premier lieu. Par exemple, une seule série de tests d'utilisabilité passe de six semaines (un délai raisonnable pour un test d'utilisabilité standard) à six mois. Et c'est avec une seule série de tests d'utilisabilité . Souvent, deux séries de tests ou plus sont nécessaires.

Ce niveau de rigueur est un signal d'alarme pour les entreprises qui commencent à travailler avec la FDA. Plus d'une fois, Horvath a dû faire face à des conversations difficiles avec des clients qui n'étaient pas préparés aux délais prolongés et au budget supplémentaire nécessaire pour répondre aux exigences de la FDA. C'est dur, mais nécessaire. "Il vaut la peine d'être minutieux", déclare Horvath. En 2018, la FDA n'a approuvé que 11 % des soumissions avant commercialisation.

Les exigences vis-à-vis des chercheurs, concepteurs et développeurs sont plus élevées pour les logiciels de santé nécessitant une conformité FDA que pour les produits logiciels traditionnels. Par exemple:

• Un chercheur UX ne peut effectuer qu'une ou deux sessions de test d'utilisabilité par jour, contrairement aux cinq à six sessions plus courantes par jour pour les logiciels standard.
• Les concepteurs UX doivent rester hyper attentifs à tous les aspects de l'interaction de l'utilisateur avec le logiciel. Même une interaction confuse pourrait amener un clinicien à commettre une erreur qui pourrait mettre en danger la santé d'un patient. Pour la même raison, les concepteurs d'interface utilisateur doivent dessiner des interfaces qui restent fidèles à chaque interaction.
• Un délai plus long pour la conception et les tests d'utilisabilité signifie que les efforts de codage du développeur doivent être planifiés avec soin. Les développeurs compétents et bien intentionnés sont souvent impatients de modifier le code dès que de nouvelles informations sont disponibles. Bien que cette approche puisse fonctionner dans des organisations bien rodées à l'itération rapide, elle comporte des risques lors de la conception et du codage de systèmes complexes.

Ne pas gérer la complexité peut avoir des conséquences fatales, comme cela s'est produit lorsque Danielle McCray a été admise au Tallahassee Memorial Hospital alors qu'elle était sur le point d'accoucher. Pour soulager son inconfort, les travailleurs de la santé l'ont connectée à une machine d'analgésie contrôlée par le patient, une pompe à perfusion programmable.

Huit heures plus tard, McCray a été déclaré mort d'une overdose de morphine. L'un des principaux facteurs de cette tragédie a été la conception défectueuse de la pompe à perfusion utilisée pour administrer les médicaments. La pompe nécessitait 27 étapes de programmation. Le fait de ne pas aborder une telle complexité en concevant une interface utilisateur plus intuitive a contribué à une mort inutile.

Solution

La solution est de reconnaître et d'aborder la complexité. Ce point semble logique. Pourtant, comme expliqué ci-dessus, les réglementations compliquées de la FDA surprennent souvent les chefs d'entreprise. Le déni ne fonctionne pas. Ne pas planifier signifie que votre organisation tombera probablement dans les 89 % des soumissions de pré-commercialisation que la FDA a rejetées en 2018.

Lors de la réalisation de tests d'utilisabilité, les chercheurs en expérience utilisateur doivent suivre trois étapes pour gérer la complexité associée aux réglementations de la FDA :

1. Le modérateur (la personne qui exécute le test d'utilisabilité) doit être hyper-attentif. Par exemple, si une IRM nécessite qu'un technicien suive une séquence stricte d'étapes lors de l'utilisation du logiciel associé, le modérateur doit observer attentivement pour déterminer si le participant suit les instructions à la lettre. Si ce n'est pas le cas, la tâche est considérée comme un échec, ce qui signifie que la conception de l'interface et la documentation associée devront être modifiées ;
2. Le modérateur doit également suivre les appels rapprochés. Par exemple, un participant peut initialement exécuter les étapes dans le désordre, découvrir l'erreur et récupérer en suivant la séquence appropriée. La FDA considère qu'il s'agit d'un quasi-accident, et le modérateur doit le signaler comme tel ;
3. L'animateur doit également évaluer les connaissances du participant. Croit-elle avoir suivi la bonne séquence ? Cette croyance est-elle exacte ?

2. Syndrome de la prochaine libération

L'un des facteurs de l'incapacité à reconnaître la complexité est un état d'esprit de réparation ultérieure que nous appelons le syndrome de la prochaine version. Les bogues logiciels ne sont pas un problème car « nous corrigerons cela dans la prochaine version ». L'accent mis sur la rapidité plutôt que sur la qualité et la sécurité rend trop facile le report de la résolution des problèmes difficiles.

Toute personne impliquée dans la conception et le développement de produits doit lutter contre le syndrome de la prochaine version. Deux exemples font le point :

• Nous avons découvert de graves défauts de conception dans le logiciel de suivi des soins de santé d'un client. La société a choisi de publier le logiciel sans résoudre ces problèmes. Sans surprise, les clients étaient mécontents.
• Nous avons effectué des tests d'utilisabilité pour une grande coopérative de crédit basée aux États-Unis. Les participants étaient des conseillers financiers chevronnés. Les tests ont révélé de graves défauts de conception, notamment des icônes d'état déroutantes, des boutons avec un objectif peu clair et un lien presque caché qui empêchait les participants d'afficher des données importantes. N'oubliez pas que si l'utilisateur ne le voit pas, il n'y est pas. Lorsque nous avons signalé les résultats, la réponse a été : "Nous corrigerons cela dans la prochaine version." Comme prévu, l'application Web n'a pas été bien accueillie. Les réponses des utilisateurs comprenaient : "Pourquoi nous avez-vous demandé d'examiner l'application si vous n'aviez pas l'intention d'apporter des modifications ?"

Solution : Rejeter la mentalité Fix-It-Next-Time

La solution consiste à résoudre dès maintenant les problèmes de conception graves. Cela semble simple. Mais comment convaincre les décideurs de changer l'état d'esprit bien ancré du « réparer plus tard » ?

La clé est de déplacer la conversation sur la réussite loin de la livraison du produit vers la valeur créée. Par exemple, les équipes qui prennent le temps de réviser une conception basée sur la recherche d'utilisateurs sont susceptibles de voir de meilleures réactions des clients et, au fil du temps, une fidélité accrue des clients.

Renforcez le dossier en utilisant des données quantitatives pour montrer aux décideurs le lien direct entre la recherche d'utilisateurs, l'augmentation des revenus et une expérience client positive.

La redéfinition de la valeur est, en effet, une amélioration de processus car elle établit un nouvel ensemble de priorités qui sert mieux les clients et les intérêts à long terme de votre entreprise. Comme le rapporte McKinsey dans The Business Value of Design : « Les entreprises du premier quartile adoptent l'expérience utilisateur complète ; ils font tomber les barrières internes entre la conception physique, numérique et de service.

3. Temps insuffisant pour les itérations de conception

En relation avec le syndrome de la prochaine version, il n'y a pas suffisamment de temps pour itérer la conception en fonction des résultats de la recherche ou de l'évolution des besoins de l'entreprise. "Nous n'avons pas le temps pour cela", est le refrain commun des développeurs et des propriétaires de produits. Les concepteurs travaillant dans des environnements Agiles sont souvent contraints d'éviter de "retarder" l'équipe de développement.

Le développement s'accélère et le logiciel est publié. Nous avons tous vu les résultats des applications téléphoniques déroutantes, des logiciels de dossiers médicaux maladroits, de l'interface utilisateur encombrante pour les conseillers financiers mentionnés ci-dessus.

Solution : concevoir des pointes

Une solution vient du monde du codage. Dans son article "Fitting Big-Picture UX Into Agile Development", Damon Dimmick propose l'idée de pointes de conception, "des bulles de temps qui permettent aux concepteurs de se concentrer sur des problèmes UX complexes". Ils s'intègrent dans le cadre Scrum en prenant temporairement la place d'un sprint régulier.

Les pointes design offrent plusieurs avantages :

• Ils permettent aux équipes UX de se concentrer sur des problèmes holistiques et d'éviter de s'enliser dans des problèmes de conception granulaires qui sont parfois soulignés au cours d'un seul sprint ;
• Ils offrent la possibilité d'explorer des questions UX complexes à un niveau élevé. Si nécessaire, l'équipe de conception UX peut également s'engager dans une réflexion centrée sur la conception à tout moment afin de résoudre des défis UX plus importants ;
• En adoptant des pointes de conception, les équipes UX peuvent tirer parti de la même flexibilité que les équipes de développement utilisent dans le processus agile et consacrer le temps nécessaire pour se concentrer sur les problèmes de conception qui ne s'intègrent pas toujours bien dans un sprint Scrum standard ;
• Le développement peu susceptible d'être affecté par les décisions de conception peut se poursuivre.

Naturellement, les itérations de conception affectent souvent certaines parties du code d'un site, d'une application ou d'un produit logiciel. Pour cette raison, pendant les pics de conception, tout code susceptible d'être affecté par le pic de conception ne peut pas avancer. Mais, comme Dimmick l'indique clairement, ce "retard" permettra probablement de gagner du temps en évitant de retravailler. Cela n'a tout simplement aucun sens d'écrire du code maintenant et de le réécrire quelques semaines plus tard après que l'équipe se soit mise d'accord sur une conception révisée. En bref, reporter certains codages permet en fait d'économiser du temps et du budget.

4. Trop compter sur les fournisseurs

Aborder la complexité, résister au syndrome de la prochaine version et laisser du temps pour l'itération sont essentiels à un processus de conception efficace. Pour de nombreuses entreprises, une autre considération est leur relation avec les éditeurs de logiciels. Ces fournisseurs jouent un rôle important, voire critique, dans le développement. Pourtant, leur accorder trop d'effet de levier rend difficile le contrôle de votre propre produit.

Certes, nous devons traiter les collègues et les fournisseurs avec respect et faire des demandes raisonnables. Cela ne signifie pas, cependant, qu'il est nécessaire d'abandonner tout effet de levier, comme cela s'est produit pendant mon mandat dans une grande société financière.

En travaillant dans cette entreprise en tant que designer UX, j'ai fréquemment rencontré cette dynamique :

Manager : "Hé, Eric, pouvez-vous évaluer ce logiciel de gestion des sinistres que nous prévoyons d'acheter ? Nous voulons juste nous assurer que cela fonctionne comme prévu.

Moi : "Bien sûr, je t'enverrai mes conclusions préliminaires d'ici la fin de la semaine."

Gérant : "Génial"

La semaine suivante:

Responsable : "Merci pour l'avis. Je vois que vous avez trouvé trois problèmes sérieux : la difficulté à trouver le numéro d'une réclamation existante, les écrans avec trop de texte qui sont difficiles à lire et la difficulté de revenir à un écran précédent lors du traitement d'une nouvelle réclamation. C'est préoccupant. Pensez-vous que ces problèmes entraveront la productivité ? »

Moi : « Oui, je pense que ces problèmes vont augmenter le stress et le temps de traitement au centre de réclamations. Je suis assez inquiet car mon travail précédent avec l'équipe de Janet a démontré que les représentants du Centre des réclamations sont déjà très stressés. »

Gérant : « Vraiment bon à savoir. Je viens d'envoyer le chèque. Je demanderai au fournisseur de résoudre les problèmes avant l'expédition. »

Moi (criant à l'intérieur): "Nooooooooooooooo!"

Ce gestionnaire bien intentionné a fait exactement la mauvaise chose. Il a demandé des modifications après l'envoi du chèque. Pas étonnant que le vendeur n'ait jamais apporté les modifications demandées. Pourquoi le feraient-ils ? Ils avaient leur argent.

Non seulement ce scénario s'est reproduit à plusieurs reprises dans cette entreprise, mais j'en ai été témoin tout au long de ma carrière UX.

Solution

La solution est claire. Si le produit du fournisseur ne répond pas aux besoins du client et de l'entreprise et que les modifications que vous demandez sont dans le champ d'application, ne payez pas tant que le fournisseur n'a pas effectué les modifications. C'est aussi simple que ça.

Conclusion

Dans cet article, nous avons identifié quatre obstacles courants à une conception de qualité et aux solutions correspondantes :

1. Réglementations et normes complexes
   La solution consiste à reconnaître et à gérer la complexité en concevant des délais réalistes et un budget suffisant pour la recherche et la conception itérative.
2. Expédier des logiciels avec des bugs avec la promesse de les corriger plus tard
   La solution consiste à éviter le syndrome de la prochaine version et à résoudre les problèmes graves dès maintenant. Persuadez les décideurs en redéfinissant le sens de la valeur au sein de votre organisation.
3. Temps insuffisant pour les itérations de conception
   La solution consiste à inclure des pointes de conception dans le processus de développement agile. Ces bulles de temps prennent temporairement la place d'un sprint et permettent aux designers de se concentrer sur des problématiques UX complexes.
4. Dépendre trop des fournisseurs
   La solution consiste à conserver l'effet de levier en retenant le paiement final jusqu'à ce que le fournisseur apporte les modifications demandées, à condition que ces modifications respectent la portée du projet d'origine.

La quatrième solution est simple. Bien que les trois premiers ne soient pas faciles, ils sont concrets car ils peuvent être appliqués directement aux processus de conception existants. Leur mise en œuvre ne nécessite pas une réorganisation massive ni des millions de dollars. Cela nécessite simplement un engagement à offrir une meilleure expérience.