Si vous trouvez que le bon design est cher, regardez le coût d’un mauvais design.
Dr. Ralf Speth, PDG, Jaguar Land Rover
Au cours de la dernière décennie, l’expérience utilisateur est devenue le véritable facteur de différenciation entre de bonnes et d’excellentes applications.
Le côté technique de la création de logiciels est en quelque sorte un problème résolu. Les véritables opportunités de succès démesuré avec les produits logiciels résident dans l’UX. La prochaine application révolutionnaire offrira une interface immédiatement utilisable. Cela a conduit à une approche centrée sur l’UX et basée sur la recherche lors du développement de produit.
Les résultats de cette focalisation parlent d’eux-mêmes.
Par exemple, chaque dollar investi dans l’UX génère 100 $ de retour sur investissement, selon un rapport de Forrester Research. De plus, sur une période de 10 ans, une étude montre que les performances financières des entreprises axées sur le design surpassent le S&P de 219 %.
Il existe également l’histoire légendaire de cette entreprise e-commerce qui a, en changeant simplement le texte d’un bouton, ajouté 300 millions de dollars en ventes en une seule année !
Cependant, malgré tout le battage médiatique, pour chaque application offrant une excellente expérience utilisateur, il y en a plusieurs qui sont insuffisantes, voire très insuffisantes sur ce point. Les pires sont faciles à repérer, elles vous donnent envie de passer votre poing à travers l’écran ou de jeter votre appareil par la fenêtre. Darwin s’occupe de ces applications.
Le vrai défi concerne les applications avec une UX simplement correcte. Ce sont celles qui provoquent cette “écharde dans l’esprit”, où vous ne parvenez pas à comprendre pourquoi elles vous déplaisent !

Je vous entends dire : “Nous savons tout cela ; je lis The QA Lead, alors quel est le rapport avec moi ?” J’y viens.
L’importance de l’UX
Au début de ma gestion d’équipes d’ingénierie, nous travaillions sur un gros projet de solution logicielle pour l’un de nos clients. Cela faisait partie d’une stratégie plus large de transformation digitale en cours de déploiement pour ce client. Nous avions une équipe typique, composée principalement de développeurs logiciels et d’ingénieurs QA, utilisant Scrum avec des sprints de deux semaines.
Il y avait une petite équipe UX mais, la plupart du temps, elle était partagée entre plusieurs projets. En général, les spécialistes UX participaient aux réunions debout de l’équipe au début des projets mais, une fois la conception visuelle validée par le client, ils remettaient tous les modèles de design ainsi que les parcours utilisateur, puis partaient travailler sur d’autres projets.
Lors de la première démonstration de sprint, le client semblait surtout préoccupé par le fait que le design visuel et l’interface utilisateur ne correspondaient pas exactement aux maquettes. Il y avait également un écart entre la fonctionnalité proposée et ce qui avait effectivement été livré.
Certes, l’écart n’était pas énorme mais, quels que soient nos efforts pour rassurer le client que l’aspect UX serait amélioré durant l’un des prochains sprints, son langage corporel montrait clairement qu’il n’était pas content.
Heureusement, la responsable QA de notre équipe a pris la parole, affirmant qu’il s’agissait d’une anomalie et que cela ne se reproduirait plus. Et ensuite, elle a fait quelque chose d’incroyable. Voici ce qu’elle a mis en place :
- Elle a pris sur elle de perfectionner ses connaissances en UX en faisant des lectures approfondies.
- Ensuite, elle a elle-même réalisé une évaluation heuristique basique de l’UX des fonctionnalités livrées, a discuté avec l’équipe UX et obtenu leur aide si nécessaire.
- Elle a créé de nouvelles tâches dans JIRA pour corriger l’écart entre ce qui était promis et ce qui avait été livré — d’un point de vue UX.
- Elle a organisé un appel avec notre responsable UX et obtenu son accord pour instaurer un nouveau processus, garantissant que les aspects visuels de l’application seraient corrigés à chaque sprint et non seulement à la fin.
- Enfin, elle a aussi initié l’équipe QA aux bases de l’UX afin qu’ils puissent détecter les problèmes flagrants et aider le groupe à les traiter dès le début du projet.
La cerise sur le gâteau ? Lors de la présentation du sprint suivant, le client/propriétaire du produit était tout sourire, et après quelques mois, notre responsable QA était promue au poste de QA Manager ! 😉
Perspectives romantiques versus classiques de la réalité
Tout cet épisode m’a fait réfléchir à l’énorme écart entre la façon dont nous, en ingénierie, percevons une application et la façon dont les clients et utilisateurs la perçoivent. Robert Pirsig, dans son livre de référence Zen, l’art et l’entretien des motocyclettes, parle de deux perspectives sur la réalité : l’approche classique et l’approche romantique.
Selon Pirsig, ceux dont la perspective dominante est romantique voient les choses et les jugent en fonction de leur apparence. Ils s’intéressent avant tout à l’aspect des choses et se soucient peu de la façon dont elles fonctionnent — de l’ordre sous-jacent. C’est la composante artistique de la division entre art et science.
À l’inverse, nous, ingénieurs et scientifiques, adhérons à la vision classique dans laquelle la beauté réside dans les mécanismes qui sous-tendent la forme extérieure. Les ingénieurs peuvent voir la beauté dans un code python, ou sous le capot d’une voiture, ce qui paraît laid à ceux du côté romantique.


Comme pour tout, il ne s'agit évidemment pas d'une classification binaire mais d’un continuum, la plupart d’entre nous préférant majoritairement une perspective.
Cela entraîne quelques implications intéressantes dans la manière de classer le monde :
1. La perspective dominante de la plupart des gens est par défaut soit classique soit romantique, rarement les deux à la fois.
2. Les personnes — pensez aux clients, internes comme externes — ayant une perspective romantique sont bien plus nombreuses que celles ayant une perspective classique. Si vous avez déjà joué le rôle de support technique pour la famille ou les amis, vous voyez de quoi je parle !

3. Très peu savent changer de mode, et même pour ceux-là, cela demande des efforts.
4. Réalité = classique + romantique. Ils ne sont pas mutuellement exclusifs. Les deux sont des aspects essentiels de la totalité. La beauté est fonctionnelle. La fonction peut être belle.
Prenez les fleurs, par exemple. Elles présentent des motifs magnifiques qui semblent dépourvus de fonction. Pourtant, la beauté que nous percevons dans les fleurs possède une structure sous-jacente ancrée dans les mathématiques : la suite de Fibonacci régit la structure et les motifs que nous retrouvons dans les fleurs. Structure et beauté éthérée vont de pair dans la nature.
Et il ne s’agit pas seulement de beauté ! L’arrangement des graines dans un tournesol suit la suite de Fibonacci et le nombre d’or afin de placer le plus grand nombre possible de graines dans la fleur. Ces mêmes principes s’appliquent à l’ingénierie et à l’expérience utilisateur.

Cela nous amène enfin au cœur de cet article : les experts en qualité sont idéalement placés pour tirer parti de ces deux perspectives apparemment concurrentes.
Le rôle de l’assurance qualité logicielle dans l’UX / l’utilisabilité
En tant que professionnel du test, vous avez beaucoup plus d’expérience avec les interfaces que le développeur ou utilisateur moyen.
Vous avez testé de façon rigoureuse et répétée (jusqu’à l’épuisement !) tellement d’applications que vous avez peut-être atteint le niveau de pensée de haut niveau ou « 4D » concernant l’expérience utilisateur, à l’image du joueur d’échecs de haut niveau qui raisonne en positions plutôt que comme moi, qui peine à choisir la pièce à jouer ! ;-)
C’est pourquoi, malgré l’immense avancée vers l’automatisation – une excellente évolution, sans aucun doute – il y a toujours une vraie valeur à conserver une part de test manuel. Après tout, si des humains vont utiliser une application, il est logique d’intégrer leur point de vue dans les tests.
Comment réaliser une revue UX / utilisabilité en tant qu’ingénieur de test
Si l’assurance qualité doit intégrer l’expérience utilisateur, cela doit commencer dès la phase de conception, c’est-à-dire au début du cycle de vie. Voici les étapes à suivre pour inclure la revue UX dans vos tests et devenir un polymathe du QA !
Heuristiques d’utilisabilité pour la conception d’interfaces utilisateurs
Familiarisez-vous avec les 10 principes généraux de conception d’interaction de Jakob Nielsen. Ce référentiel constitue une excellente base pour toute évaluation d’utilisabilité. Prenez ces principes en compte lors de vos échanges avec l’équipe UX ainsi que dans votre plan de test. Vous pouvez également suivre divers cours de base sur l’utilisabilité et la conception UX.
Apprendre les principes de l’accessibilité
Vous avez peut-être déjà effectué des tests d’accessibilité dans le cadre de votre plan de test, mais comprendre les principes qui sous-tendent l’accessibilité — perceptible, exploitable, compréhensible, robuste — vous donnera la capacité de repérer ce que d’autres pourraient manquer.
L’équipe UX, votre nouveau repaire
Ne restez pas à l’écart : apprenez à connaître l’équipe UX du projet. Collaborez avec eux. Partagez votre plan de test avec eux et recueillez leurs retours sur ce que vous pouvez intégrer sous l’angle UX.
Les avantages de cette interaction sont réciproques : votre plan de test donnera à l’équipe design un aperçu de la faisabilité des fonctionnalités de conception qu’ils souhaitent proposer. En tant que responsable QA, vos échanges avec l’équipe UX doivent être aussi étroits qu’avec les développeurs.
Inclure les analytics dans votre plan de test
Les analyses d’utilisateurs sur le produit que vous testez sont une mine d’or d’informations pour les testeurs. Les analytics peuvent vous aider à identifier les zones à risque et les comportements utilisateur. Ceux-ci, à leur tour, permettent de repérer et de prioriser les corrections le plus tôt possible dans le cycle de vie du produit.
Déplacez-vous « à gauche » aussi tôt que possible
Le produit que vous testez est comme un bébé. Il faut vous assurer qu’il reçoit l’accompagnement dont il a besoin dès la conception du produit. Remontez jusqu’au tout début.
Avant le développement
Testez dès l’étape de conception, dès qu’un prototype est prêt. Utilisez votre expérience avec les applications et votre connaissance des principes d’utilisabilité et des recommandations d’accessibilité pour vérifier si des modifications sont nécessaires AVANT que le produit ne passe en phase de développement.
Si la QA n’est pas encore impliquée lors de la phase de design, faites en sorte que cela change, si possible.
Tests manuels ciblés
Parcourez toute l’expérience d’utilisation du produit du début à la fin lors de vos tests manuels. Prenez le temps de vous poser les bonnes questions, de réfléchir à la fois comme un utilisateur et comme un ingénieur QA.
Commencez par prendre du recul pour avoir une vision globale du produit. Appréciez-vous l’expérience ?
Puis examinez de plus près. Est-ce facile à utiliser ? Les parcours sont-ils évidents et intuitifs ? Sont-ils fastidieux ou lents ? Y a-t-il des redondances ou des actions dupliquées qui pourraient devenir agaçantes pour l’utilisateur ? Le design est-il utilisable sur différentes tailles d’écran ?
Pour conclure
L’avenir du travail appartient à ceux possédant plusieurs ensembles de compétences complémentaires, quasiment impossibles à automatiser (mais consultez mon article sur l’IA dans l’automatisation des tests pour avoir une idée de ce que ces outils peuvent déjà accomplir).
Devenir un(e) polymathe QA avec des compétences UX pourrait être une excellente façon de valoriser vos aptitudes naturelles et votre expérience, d’apporter une grande valeur ajoutée sans trop d’efforts ou sans vous éloigner de votre cœur de métier.
Est-ce un sujet qui vous enthousiasme ? Ou pensez-vous que l’UX n’est que marginale pour ce domaine ? Donnez-moi votre avis dans les commentaires ci-dessous.
Si vous souhaitez approfondir, voici un podcast que vous pouvez lire/écouter : COMMENT LE LOGICIEL OPEN SOURCE SIMPLIFIE L’INTÉGRATION EN INGÉNIERIE DE L’AUTOMATISATION (AVEC JAMES WALKER ET SANJAY KUMAR)
