Amener un meilleur processus de conception à votre organisation

En tant que concepteurs et chercheurs d'expérience utilisateur (UX), la plainte la plus courante que nous recevons des utilisateurs. est:

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

En fait, de nombreuses organisations disposent d'équipes dédiées à la satisfaction des besoins des utilisateurs et des clients. De plus en plus de développeurs de logiciels souhaitent travailler avec les concepteurs UX afin de coder des interfaces que les clients utiliseront et comprendront. Le problème est que des projets logiciels complexes peuvent facilement s’embourber dans des priorités concurrentes et créer une confusion quant à ce qu’il faut faire par la suite.

Il en résulte une conception médiocre qui nuit à 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 à la règle.

Depuis 2010, le Dr Ugent utilise deux systèmes de DME: avant 2010, il finissait rapidement le travail à 5 ​​h 15 tous les jours. Depuis que lui et ses collègues ont commencé à utiliser les DME, il travaille généralement une demi-heure supplémentaire à une heure et demie 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 de DME sont encombrants, inflexibles 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 sur des photos pour traiter des patients.

Ugent résume succinctement le problème posé par les DME:

«Les personnes qui les ont conçues [the EMR system] 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 peu pratiques. Les consommateurs et les professionnels du monde entier se plaignent de la même manière:

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

"Pourquoi rendent-ils les choses si difficiles?"

"Pourquoi dois-je créer un identifiant quand je veux simplement acheter ce produit. Je leur donne de l'argent. N’est-ce pas assez? ”

Les processus de conception défectueux sont l’un des principaux contributeurs au logiciel maladroit. Dans cet article, nous décrivons 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. Cession du contrôle à des fournisseurs extérieurs

1 . Complexité

L'échelle, de multiples parties prenantes et la nécessité d'un code sophistiqué comptent parmi les nombreux facteurs contribuant à la complexité de 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é aux sociétés d’assurance opérant dans plusieurs États. Les banques et les caisses populaires sont soumises à la réglementation, tandis que les services publics doivent respecter les lois environnementales fédérales et nationales.

Les produits et logiciels de santé soumis à la réglementation de la FDA constituent un défi encore plus grand. Le problème n’est pas que la réglementation soit déraisonnable. La sécurité est primordiale. Les enjeux 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., consultant UX possédant une vaste expérience des soins de santé, «ces exigences ajoutent quelques ordres de grandeur à la rigueur nécessaire pour la rédaction de protocoles de test, la configuration de tests, la collecte de données, l'analyse, les contrôles qualité et l'obtention de l'autorisation de mener la recherche à la première place. »Par exemple, une seule série de tests d'utilisabilité passe de six semaines (délai raisonnable pour test d’utilisabilité standard) à six mois. Et c’est avec un test unique d’utilisabilité . Deux ou plusieurs séries d'essais sont souvent nécessaires.

Ce niveau de rigueur est un avertissement pour les entreprises qui commencent à travailler avec la FDA. À plusieurs reprises, 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 difficile, mais nécessaire. «Cela vaut la peine d'être approfondi», déclare Horvath. En 2018, la FDA n'a approuvé que 11% des soumissions pré-commercialisation .

Les exigences imposées aux chercheurs, concepteurs et développeurs sont plus élevées pour les logiciels de santé nécessitant la conformité à la FDA que pour les logiciels traditionnels. Par exemple:

• Un chercheur UX ne peut effectuer qu’une ou deux sessions d’essai d’utilisabilité par jour, au lieu des cinq à six sessions quotidiennes les plus courantes pour les logiciels standard.
• Les concepteurs d’UX doivent rester extrêmement attentifs à tous les aspects de la l'interaction de l'utilisateur avec le logiciel. Même une interaction déroutante peut amener un clinicien à commettre une erreur susceptible de compromettre 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 expérimentés et bien intentionnés souhaitent souvent modifier le code dès que de nouvelles informations sont disponibles. Bien que cette approche puisse fonctionner dans des organisations bien rodées, 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 ce fut le cas lors de l'admission de Danielle McCray à l'hôpital Tallahassee Memorial. donner naissance. Pour soulager son inconfort, des travailleurs de la santé l'ont connectée à un appareil d'analgésie contrôlé par le patient, une pompe à perfusion programmable.

Huit heures plus tard McCray est déclaré mort d'une overdose de morphine . La conception défectueuse de la pompe à perfusion utilisée pour administrer les médicaments a joué un rôle majeur dans cette tragédie. La pompe a nécessité 27 étapes de programmation. Le fait de ne pas traiter une telle complexité en concevant une interface utilisateur plus intuitive a entraîné une mort inutile.

Solution

La solution consiste à reconnaître et à gérer la complexité. Ce point semble logique. Cependant, comme expliqué ci-dessus, les réglementations complexes de la FDA surprennent souvent les dirigeants d’entreprise. Le déni ne fonctionne pas. Si vous ne planifiez pas, votre organisation fera probablement partie des 89% de soumissions pré-commercialisation que la FDA a rejetées en 2018.

Lors de tests d'utilisation, les chercheurs en expérience utilisateur doivent suivre trois étapes pour gérer la complexité associée aux réglementations de la FDA: [19659036] Le modérateur (la personne qui effectue le test d'utilisabilité) doit être hyper attentif. Par exemple, si une analyse 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 afin de déterminer si le participant respecte les instructions à la lettre. Dans le cas contraire, 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. Syndrome de la prochaine libération

L'un des facteurs expliquant l'incapacité à reconnaître la complexité est un état d'esprit qui consiste à réparer ce qu'il est advenu ultérieurement, appelé syndrome de la prochaine libération. Les bogues logiciels ne sont pas un problème, car «nous corrigerons cela dans la prochaine version». L'accent mis sur la rapidité sur la qualité et la sécurité facilite le report de la résolution des problèmes difficiles.

Toute personne impliquée dans la conception et le développement de produits doit s'attaquer au syndrome de la prochaine libération.

• Nous avons découvert de graves problèmes de conception avec 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. Il n’est donc pas surprenant que les clients soient mécontents.
• Nous avons effectué des tests d’utilisabilité pour une grande caisse populaire établie 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 confuses, des boutons mal définis et un lien presque masqué empêchant les participants d'afficher des données importantes. N'oubliez pas que si l'utilisateur ne le voit pas, ce n'est pas là. Lorsque nous avons rendu compte des résultats, la réponse a été la suivante: «Nous corrigerons cela dans la prochaine version.» Comme prévu, l’application Web n’a pas été bien reçue. Les réponses des utilisateurs incluaient notamment: «Pourquoi nous avez-vous demandé de revoir l'application si vous n'aviez pas l'intention de faire des changements?»

Solution: rejetez la mentalité «Fix-It-Next-Time»

La solution est de s'attaquer sérieusement à la conception problèmes maintenant. Cela semble simple. Mais comment convaincre les décideurs de changer l’esprit enraciné de «solutionner plus tard»?

L’essentiel est de détourner le débat sur les réalisations de la livraison de produits vers la valeur créée. Par exemple, les équipes qui prennent le temps de réviser une conception basée sur des recherches auprès des utilisateurs verront probablement de meilleures réactions des clients et, au fil du temps, une fidélité accrue des clients.

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

La redéfinition de la valeur est en réalité une amélioration de processus car elle établit un nouvel ensemble de priorités qui servent mieux les clients et les intérêts à long terme de votre entreprise. Comme le rapporte McKinsey dans La ​​valeur commerciale du design : «Les entreprises du quartile supérieur embrassent l'expérience utilisateur complète; ils suppriment les barrières internes entre la conception physique, numérique et la conception de services. ”

3. Temps insuffisant pour les itérations de conception

En ce qui concerne le syndrome de la prochaine version, le temps manque 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", dit-on couramment aux développeurs et aux propriétaires de produits. Les concepteurs travaillant dans des environnements agiles subissent fréquemment des pressions pour éviter de «gêner» l'équipe de développement.

La ​​vitesse de développement s'accélère et le logiciel est publié. Nous avons tous vu les résultats d’applications téléphoniques confuses, d’un logiciel de dossiers médicaux fastidieux, d’une interface utilisateur encombrante pour les conseillers financiers mentionnée ci-dessus.

Solution: Design Spikes

Une solution provient du monde de la programmation. Dans son article «« Intégrer l’UX grand format dans un développement agile », Damon Dimmick propose l’idée de pointes de design,« des bulles de temps qui permettent aux concepteurs de se concentrer sur des problèmes UX complexes ». Ils s’inscrivent parfaitement dans le cadre Scrum. en prenant temporairement la place d'un sprint régulier.

Les pics de design offrent plusieurs avantages:

• Ils permettent aux équipes UX de se concentrer sur le holistique. éviter de s’embourber dans des problèmes de conception granulaires qui sont parfois soulignés au cours d’un seul sprint
• . Ils offrent l’occasion d’explorer des questions complexes relatives à l’expérience utilisateur à un niveau élevé. Si nécessaire, l'équipe de conception UX peut également engager une réflexion centrée sur la conception à tout moment afin de résoudre de plus grands défis UX;
• En adoptant des pics de conception, les équipes UX peuvent bénéficier de la même flexibilité que celle utilisée par les équipes de développement dans le processus agile. 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 de mêlée standard;
• Un développement peu susceptible d'être affecté par les décisions de conception peut continuer.

Naturellement, les itérations de conception affectent souvent certaines parties du code pour un site, une application ou un produit logiciel. Pour cette raison, pendant les pics de conception, tout code susceptible d'être affecté par la pointe de conception ne peut pas avancer. Mais, comme le dit clairement Dimmick, ce «retard» permettra probablement de gagner du temps en évitant de retravailler. Il n’est tout simplement pas logique de rédiger du code maintenant, puis de le réécrire quelques semaines plus tard, une fois que l’équipe s’est mise d’accord sur une conception révisée. En bref, remettre à plus tard le codage fait économiser du temps et de l’argent.

4. Se fier trop lourdement aux fournisseurs

Il est essentiel pour un processus de conception efficace de résoudre le problème de la complexité, de résister au syndrome de prochaine libération et de prévoir du temps pour la répétition. 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. Cependant, leur donner trop de poids rend difficile le contrôle de votre propre produit.

Nous devons certainement traiter les collègues et les fournisseurs avec respect et faire des demandes raisonnables. Cela ne signifie toutefois pas qu'il soit nécessaire de renoncer à tout recours au pouvoir, comme ce fut le cas pendant mon mandat dans une grande entreprise financière.

Pendant que je travaillais dans cette entreprise en tant que concepteur UX, j'ai souvent rencontré cette dynamique:

Manager : «Hey, Eric, peux-tu évaluer ce logiciel de gestion des sinistres que nous prévoyons d’acheter? Nous voulons simplement nous assurer que tout fonctionne comme prévu. "

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

Manager : “Excellent”

La semaine suivante:

Manager : “Merci pour votre commentaire. Je vois que vous avez relevé trois problèmes graves: difficile de trouver le numéro d’une revendication existante, écrans contenant trop de texte difficile à lire et difficulté de revenir à un écran précédent lors du traitement d’une nouvelle revendication. C'est préoccupant. Pensez-vous que ces problèmes vont entraver la productivité? ”

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

Manager :" Vraiment, c'est bon à savoir. Je viens d'envoyer le chèque. Je demanderai au vendeur de régler les problèmes avant qu'ils ne soient expédiés. "

Moi (hurlant à l'intérieur):" Noooooooooooooo! "

Ce directeur bien intentionné a précisément fait 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 répété à maintes reprises dans cette entreprise, mais j’en ai été témoin tout au long de ma carrière à l’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 restent dans le champ d’application, ne payez pas tant que le fournisseur n’a pas effectué les modifications. C’est aussi simple que cela.

Conclusion

Dans cet article, nous avons identifié quatre obstacles communs à la conception de la qualité et les solutions correspondantes:

1. Réglementations et normes complexes
   La solution consiste à reconnaître et à Résolvez la complexité en définissant des délais réalistes et un budget suffisant pour la recherche et la conception itérative.
2. Envoyez un logiciel contenant des bugs avec la promesse de les corriger plus tard
   La solution consiste à éviter le syndrome de prochaine mise à jour et à résoudre dès maintenant les problèmes graves. 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 les pointes de conception dans le processus de développement agile. Ces bulles temporelles remplacent temporairement un sprint et permettent aux concepteurs de se concentrer sur des problèmes complexes liés à l'expérience utilisateur.
4. S'appuyant trop sur les fournisseurs
   La solution consiste à conserver un effet de levier en retenant le paiement final jusqu'à ce que le fournisseur en fasse la demande. changements tant que ces changements sont dans 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 de réorganisation massive ni des millions de dollars. Cela nécessite simplement un engagement pour offrir une meilleure expérience.

(ah, il)