Bienvenue dans ce nouvel épisode de ma série d’articles consacrée à la stratégie de conception. Aujourd’hui, je vais vous présenter le témoignage d’un client, dans l’espoir que cela vous incite à réfléchir aux raisons pour lesquelles vous devriez changer vos méthodes, afin que votre programme puisse mûrir et se développer rapidement. Une fois de plus, je vais m’écarter du format classique des articles « pratiques » et des listes rébarbatives de consignes tactiques du type « faites ceci / ne faites pas cela ». Passons au témoignage…
Le problème
Ce client s'est adressé à nous pour que nous procédions à une évaluation de son patrimoine numérique. « Bien sûr », lui avons-nous répondu, « nous serons ravis de vous aider ! »
Leur site web présentait une multitude de problèmes. Il est important de savoir que ce n’est pas grave. Si l’on se concentre sur le côté positif de la situation, le client comprend désormais clairement où il en est et ce qu’il faut faire.
Eh bien. Ce scénario est en fait bien plus que « pas mal » : il est fantastique ! Pourquoi ? Parce que nous travaillons avec un client qui est désormais désireux à retrousser ses manches non seulement pour remédier au problème, mais aussi pour creuser en profondeur afin d’identifier et de corriger la cause première. En d’autres termes, il va s’attacher à corriger ce qui n’a pas fonctionné et consacrera son énergie à comprendre ce qu’il faut faire pour s’assurer que cela ne se reproduise plus. Cette approche aidera son organisation à se développer et à gagner en maturité rapidement.
À partir de là, voyons comment les choses se sont déroulées. Nous allons analyser les causes profondes et les enseignements à en tirer.
Ces résultats laissent-ils entrevoir des thèmes récurrents ?
En commençant à passer en revue les résultats de l'évaluation de ce client, j'ai relevé quelques thèmes clés. Dans ce cas précis, plus de la moitié… LA MOITIÉ !!! … des problèmes étaient liés au nom, au rôle et à la valeur. Ça m’est venu comme un coup de foudre : « Commençons par là ! » Bon, peut-être pas tout à fait un coup de foudre… mais c’était clairement le point de départ idéal pour réaliser rapidement des progrès significatifs.
Nom/Rôle/Valeur
Voyons ensemble certains points précis du critère de succès 4.1.2 des Directives pour l'accessibilité des contenus Web (WCAG)… [Lisez cela comme le ferait l'un de ces présentateurs de publicités télévisées qui lisent très, très vite ces passages un peu rébarbatifs à la fin.]
Les états et les propriétés sont des attributs utilisés pour transmettre des informations essentielles sur un élément aux lecteurs d'écran et autres technologies d'assistance. Certains rôles nécessitent des informations spécifiques sur l'état et les propriétés, comme par exemple l'état coché ou non coché d'une case à cocher. Ce code doit être valide pour qu'un lecteur d'écran puisse transmettre ces informations à l'utilisateur. Chaque contrôle d'interface utilisateur doit disposer d'un rôle ainsi que des états et propriétés applicables afin que les utilisateurs de lecteurs d'écran sachent comment interagir avec ce contrôle. Les développeurs doivent ajouter le ou les rôles pertinents, ainsi que les états et propriétés applicables et les interactions par balayage attendues.
Illustrons cela plus clairement à l'aide d'un exemple. Imaginons que nous souhaitions que l'utilisateur se désabonne de la newsletter (plutôt que de s'y abonner) lorsqu'il remplit un formulaire. Nous concevons donc une expérience utilisateur dans laquelle la case « S'abonner à la newsletter » est cochée par défaut ; le choix a déjà été fait pour l’utilisateur. Si l’utilisateur ne souhaite pas s’abonner à la newsletter, il doit désélectionner cette case avant de valider le formulaire. L’annotation dans le wireframe doit préciser au développeur que la case à cocher doit être activée lors de la mise en place du site afin qu’elle apparaisse cochée au chargement de la page. Cette annotation indique également au testeur de s’assurer que la case à cocher est bien cochée au chargement de la page dans le cadre de son processus de test. Bien entendu, il vérifiera également qu’il est possible de la cocher (ou de la décocher) et que le formulaire peut être validé correctement lorsque la case n’est pas cochée.
Le moment « Eurêka ! », suivi de réflexions et de prises de conscience
Examinons un peu plus en détail la dernière phrase de ce texte de présentation :
Les développeurs doivent ajouter le ou les rôles pertinents, ainsi que les états et propriétés applicables, sans oublier les interactions par glissement prévues.
En réfléchissant à cette affirmation, je commence à me demander comment les développeurs pourraient savoir qu’ils doivent ajouter ces rôles, ces états et ces propriétés. Plus important encore, je me demande où ces valeurs ont été documentées et comment elles sont définies.
Même avec un peu d'expérience dans le secteur, nous savons que si quelque chose n'est pas défini et documenté, les développeurs ont parfois avancent en se basant sur leurs propres définitions. Et oui, il leur arrive parfois de faire pression en prétextant qu’ils ne disposent pas de toutes les informations nécessaires pour coder efficacement. Tous les développeurs n’inventent pas n’importe quoi juste pour faire avancer le code en aval.
En y réfléchissant davantage, je m’interroge sur le rôle de l’analyste de parcours (que certaines entreprises appellent « analyste métier » ou « coach de stories Agile »). Quelles sont les attentes de ce client vis-à-vis de son analyste de parcours ? S’est-il rendu compte que cette information manquait lorsqu’il a rédigé la story Jira ou défini les exigences ? A-t-il les moyens de faire pression sur le concepteur pour qu’il la définisse ? Le client définit-il un tableau RACI avec ce niveau de détail ?
Cela nous amène à tirer quelques conclusions :
- Les équipes bien organisées ont défini des rôles qui précisent qui est responsable de quelle tâche. Dans ce cas précis, le concepteur d’expérience utilisateur doit préciser ces détails dans les annotations de son wireframe, et les responsables de la conception doivent s’assurer que ces détails sont bien présents et pertinents avant la revue de conception. Pour ceux qui disposent de bibliothèques de composants, ces informations doivent être clairement définies dans la documentation associée à chaque composant.
- Les organisations performantes disposent d’un système de contrôles croisés : chaque intervenant dans la chaîne de travail vérifie minutieusement le travail effectué à l’étape précédente du processus. Si un élément ne répond pas aux normes ou ne respecte pas les spécifications, le travail est renvoyé à l’étape où l’erreur s’est produite afin d’y remédier. Cela est possible en grande partie parce que chaque membre de l’équipe comprend les rôles et les responsabilités de chacun. Cette connaissance leur permet de savoir immédiatement à qui s’adresser pour corriger le problème. Non seulement cette approche est plus efficace, mais elle contribue également à garantir la réussite de l’équipe dans son ensemble tout en renforçant la cohésion du groupe.
- REMARQUE : Vous voulez voir cela en pratique ? Observez le personnel de votre chaîne de cafés préférée à l’œuvre la prochaine fois que vous attendrez votre délicieuse boisson à base de café. Chacun comprend le rôle de chaque poste et l’importance de mettre la main à la pâte de manière proactive pour que tout fonctionne efficacement.
- Les membres de l’équipe doivent être responsabilisés et encouragés à s’exprimer au moment même. Lorsqu’ils constatent qu’il manque quelque chose ou que quelque chose ne va pas tout à fait, ils le signalent. Ils comprennent les gains de temps et d’efforts que permet la résolution rapide des problèmes. Dans ce cas précis, le problème aurait pu être évité par le responsable de la conception ou par un expert en accessibilité (SME) dès la phase de conception. Il aurait pu être détecté par l’analyste de parcours, dans le cadre de sa mission visant à s’assurer que le développeur dispose de toutes les informations nécessaires pour coder correctement. Le développeur aurait pu signaler plus tôt dans le processus que cette information manquait. Le testeur aurait pu repérer ce problème lors de l’élaboration de son script de test et de l’examen des maquettes fonctionnelles. Il y a eu plusieurs occasions d’empêcher ce problème d’atteindre la phase de production.
- Des tests d'accessibilité rigoureux auraient dû permettre d'identifier ce problème avant la mise en production, moment où sa correction aurait été moins coûteuse que s'il avait été détecté une fois en production.
- Le niveau de risque (et le coût également) s'aggrave lorsque l'on tient compte, outre le non-respect des WCAG, des défaillances des processus.
Que pourrions-nous faire de ces informations ?
Il y a ici beaucoup de matière pour générer des améliorations, des gains d'efficacité et des méthodologies solides. Travaillez efficacement, mais prenez également le temps de mettre en œuvre des techniques de « design thinking » pour comprendre vos problèmes et les solutions possibles. (Au final, cela améliore en réalité l'efficacité.) Planifiez de manière stratégique l'enchaînement des changements et des ajustements de processus afin qu'ils soient à la fois mesurés (pour faciliter leur adoption par vos équipes) et hiérarchisés (pour apporter le plus de valeur possible à votre organisation dans les meilleurs délais).
Quelques éléments à prendre en compte :
- Utilisez les tendances qui se dégagent de vos données pour résoudre vos problèmes en fonction de la quantité, de la facilité de réparation ou de la possibilité de réparation.
- Élaborez des matrices de rôles afin de vous assurer que tous les éléments nécessaires sont identifiés et attribués à un rôle. Dans ce cas, les éléments « Rôle / Nom / Valeur » doivent être documentés par un concepteur d'expérience utilisateur. Le responsable de la conception doit être chargé de vérifier leur présence et leur exactitude.
- Veillez à ce que tous les membres de l'équipe comprennent les contributions – ainsi que leur importance – pour les rôles et les activités qui les précèdent. Assurez-vous qu'ils comprennent l'importance de leurs contributions pour ceux qui les suivent dans le processus.
- Aidez les membres de votre équipe à prendre conscience de l'intérêt de prendre le temps de corriger un problème dès qu'il se présente, plutôt que d'avoir à faire face à l'effort et aux coûts que cela impliquerait si ces problèmes réapparaissaient plus tard sous forme de tickets ou de défauts.
- Aidez vos équipes à comprendre l'intérêt de vérifier mutuellement leur travail et à prendre conscience que signaler des erreurs ou des problèmes est une bonne chose. Les réclamations sont un atout si elles surviennent suffisamment tôt. (Il existe de nombreux ouvrages traitant des réclamations en tant que source d’informations précieuse ; je vous encourage à les consulter ultérieurement.)
- Veillez à ce que vos processus du cycle de développement logiciel (SDLC) intègrent l'analyse et les tests d'accessibilité à chaque étape du processus, et ce, de manière régulière au sein de chacune de ces étapes.
- Utilisez les rétrospectives agiles pour analyser les tendances en matière de défauts et vous efforcez activement de trouver des solutions s'attaquant aux causes profondes, afin de garantir qu'aucune erreur de ce type ne se reproduise à l'avenir.
- Recherchez des occasions de micro-formation qui permettront d’éviter ces problèmes. Créez les supports pédagogiques et diffusez-les lors de déjeuners-conférences, sur le portail de votre programme d’accessibilité ou sur votre intranet, dans des lettres d’information et/ou via votre outil de gestion de la formation. Dans ce cas précis, mettez en place une formation destinée à tous les postes sur la notion de « Nom/Rôle/Valeur », la manière dont elle doit être documentée, les normes de codage et les méthodes de test à appliquer.
- Pour ceux qui viennent de lancer leur programme d’accessibilité, concentrez-vous sur la correction des défauts en demandant à vos équipes de s’attacher en priorité à éliminer les obstacles et les erreurs critiques. Au fur et à mesure que vos sprints ou vos épopées avancent, ajoutez progressivement des niveaux de défauts supplémentaires jusqu’à ce que tout le code nouvellement développé soit exempt de tout problème d’accessibilité. Demandez ensuite à vos équipes de s’attacher en priorité à résorber la dette technique liée à l’accessibilité dans votre produit (de bout en bout) jusqu’à ce que les tests ne révèlent plus aucun problème.
Pourquoi j'apprécie cette approche pour résoudre les problèmes de conception à grande échelle
N’importe quelle équipe et n’importe quel membre de l’équipe peuvent examiner un défaut et dresser rapidement une longue liste d’améliorations potentielles. Mais explorer toutes les options possibles prend beaucoup de temps et s’avère inefficace. La clé est de continuer à poser des questions pour aller au fond du problème. (Si vous vous souvenez bien, nous avons mis en avant la technique de l’arête de poisson il y a quelques articles.) Lorsqu’un problème est bien défini, il est plus facile (et plus rapide) de trouver la bonne solution.
Revenons au cas de ce client dont la moitié des problèmes était liée aux éléments « Nom/Rôle/Valeur ». J’espère que vous comprenez que j’utilise cet exemple comme une allégorie pour vous aider à saisir que, à mesure que vous analysez ce problème, vous commencez à vous rendre compte qu’il va bien au-delà de la simple définition des rôles. Il y a des problèmes liés à la dynamique d’équipe, mais aussi un problème culturel qui consiste à autoriser la création de maquettes fonctionnelles mal documentées.
Tout le monde se précipite pour coder ça et le mettre en production. Je comprends. Crois-moi, je suis déjà passé par là. Mais si tu ne le construis pas correctement dès le départ et que vous ne concevez pas le parcours utilisateur de manière à ce que celui-ci ne rencontre aucun problème, vous vous vous retrouverez à corriger les écrans lorsque le produit n'apportera aucune valeur ajoutée à l'utilisateur ou à l'entreprise.
Pour moi, en tant que stratège et concepteur de services, améliorer les mécanismes opérationnels et l’efficacité des processus est plus important pour l’ensemble de vos opérations que presque tout le reste. S’attaquer à ces aspects peut amplifier les avantages positifs que peuvent apporter les solutions s’attaquant aux causes profondes. Ne vous contentez pas de corriger le bug. Apprenez à résoudre les problèmes de manière à les régler à grande échelle.
Avant de conclure, voici la fin heureuse… Dans le cas de cette histoire, l’équipe a réussi à résoudre rapidement la moitié de ses problèmes connus en un seul sprint et a identifié la personne chargée de documenter dès le départ le nom, le rôle et la valeur de chaque élément. Elle travaille activement au renforcement de la cohésion d’équipe pour s’assurer que chacun se sente libre de signaler les problèmes, sachant que cela permet en réalité de réduire la charge de travail à long terme. Bravo à toute l’équipe !
