De l’inventaire de la dette à la roadmap UX
Sur des produits existants, positionner l’UX à l’état de l’art requiert des efforts mesurés en années de travail et une progression à travers différents stades de maturité. Pour y parvenir, mesurer la dette UX est le moyen de dresser un état des lieux. En identifiant les faiblesses, il devient possible de planifier les améliorations, à travers la roadmap UX.
Aux sources de la dette UX
Au début des années 1990, Ward Cunningham a formalisé le concept de la dette technique (technical debt). Elle comprend les coûts induits par le choix d’une solution de développement rapide mais imparfaite au lieu d’une approche optimale mais plus longue. La dette technique est similaire à une dette financière. Pour reprendre Cunningham, “Un peu de dette accélère le développement du moment qu’elle est remboursée rapidement par une réécriture”. Mais, d’après la notice Wikipedia, “quand on code au plus vite et de manière non optimale, on contracte une dette technique que l’on rembourse tout au long de la vie du produit sous forme de temps de développement de plus en plus long et de bugs de plus en plus fréquents”.
Pour Jack Moffett, La dette technique peut être décomposée en dette back-end et front-end. Côté back-end, 4 enjeux s’entrelacent : la performance, le hardware, la base de données et la sécurité. Côté front-end : la compatibilité navigateur, l’obsolescence du code HTML, l’emploi d’un framework non responsive, les mauvaises pratiques de code.
Il existe aussi une dette fonctionnelle liée à l’évolutivité, l’obsolescence, la priorisation, l’architecture de l’information.
Cette métaphore s’applique aussi bien au design d’expérience utilisateur.
La dette UX est l’accumulation de décisions de design et de développement qui engendrent un impact négatif sur les utilisateurs d’un produit ou d’un service.
Cette dette peut être délibérée mais elle est bien souvent involontaire. La dette délibérée trouve de nombreuses sources : le temps de mise sur le marché, le développement de nouvelles fonctionnalités pour atteindre une taille critique, la mauvaise communication des équipes UX et de développement, l’absence de feedback utilisateur direct…
Joshua Kerievsky explique que, comme la dette technique, la dette UX doit être remboursée, généralement sous la forme d’une satisfaction moindre et d’une perte de clientèle.
Identifier la dette UX
Dans un retour d’expérience publié en 2015, Kimberly Dunwoody et Susan Teague Rector abordent la corrélation entre la dette UX et le niveau de maturité UX. En mesurant la facilité d’usage et la satisfaction utilisateur d’un produit, on obtient un score de dette UX, duquel découle la maturité UX de chaque produit. Lorsque le niveau de la dette atteint zéro, l’entreprise est prête à adopter une démarche UX volontaire et à tendre vers une approche user-centric.
Pour dresser l’état des lieux, elles proposent de calculer la dette UX à partir d’un tableur qui “score” des critères fondés sur les heuristiques de Nielsen. Ce tableur peut être d’ailleurs transposé avec les 8 critères de Bastien et Scapin : guidage, charge de travail, contrôle explicite, adaptabilité, gestion des erreurs, homogénéité/cohérence, signifiance des codes et dénomination, compatibilité. Comme dans une analyse experte, on dresse un inventaire des problèmes rencontrés.
Pour chaque critère, on indique un niveau de sévérité :
Inutilisable : résolution indispensable —
Problème majeur : haute priorité — Critique
Problème mineur : basse priorité — Modéré
Problème cosmétique — Mineur
Critère rempli (valeur par défaut)
En découle un tableau de bord qui détaille produit par produit la dette UX. Celui-ci peut être communiqué ensuite auprès de la direction de l’entreprise. L’évaluation du score peut s’effectuer à partir des enseignements de précédents tests utilisateurs (de préférence) ou d’une analyse experte. La démarche permet de commencer à travailler à partir de données utilisateurs et de les intégrer dans la culture des produits. L’exercice s’effectue régulièrement dans le temps (chaque trimestre), afin de mesurer les progrès, mais n’est pas une fin en soi. On peut l’utiliser pour établir une roadmap UX par produit et alimenter une UX Scorecard.
Etablir une roadmap et résorber la dette UX
Une fois la dette UX inventoriée et classée selon ses niveaux de sévérité, il est intéressant d’organiser un atelier pour partager les points relevés entre l’équipe UX, les product managers (PM) et les développeurs. On ne se contente pas de passer en revue les principaux problèmes UX identifiés, on liste également les nouveautés qui pourraient être apportées. Les échanges peuvent être organisés sous la forme d’un tableau Kanban dans Trello (ou sur un mur avec des post-it), en fonction des activités UX à conduire :
- Correction
- Amélioration
- Nouveauté
- Recherche utilisateur (insight nécessaire)
Le kanban permet de hiérarchiser et d’étiquetter facilement les éléments de la future roadmap avec
Les thématiques, par exemple :
- Architecture de l’information
- User flow
- Gestion des erreurs
- Facilité d’usage
- Mise en cohérence
- Branding
- etc.
L’horizon dans lequel on pense pouvoir apporter une résolution : 1er trimestre, 2e trimestre, etc.
Les points d’effort estimés pour accomplir le travail, par exemple avec un planning poker (à faire par l’équipe UX). Cette estimation permettra ensuite d’embarquer la résolution de la dette UX dans les sprints.
Une fois que les points de vue ont convergé et que le tableau est consolidé avec toutes ses données, on formalise la roadmap avec un outil comme RoadMunk ou ProductPlan :
L’avantage de cet effort de roadmapping est qu’il s’appuie d’une part sur des données utilisateurs factuelles et que le point de vue l’équipe est également intégré. En co-construisant la roadmap UX, on s’assure que chacun est aligné avec la vision et on améliore sa pertinence car la faisabilité technique est prise en compte.
