Identifier, gérer et résorber la dette UX
Zoom sur le parent pauvre de la dette technique.
A l’origine: la dette technique
Cette dernière, inventée par Ward Cunningham en 1992, s’inspire du contexte de financement des entreprise, appliqué au développement logiciel puis web.
En codant au plus vite, sans optimisation, avec une documentation insuffisante, on va créer une dette qu’il faudra rembourser tout au long de la vie du produit.
La dette technique existe toujours sur un projet: c’est son volume qui doit être au coeur des préoccupations et la manière de la gérer au quotidien.
Soit on accepte de payer les intérêts, qui deviennent de plus en plus lourds:
- De plus en plus de bugs et d’incidents prioritaires.
- Un ratio exponentiel entre durée de livraison et complexité d’une tâche
- Une pression qui s’accroit et un plaisir de travailler sur le produit à la baisse pour les différentes parties prenantes
Soit on convertit cette dette:
- Par exemple en remplaçant la stack technique par une nouvelle, meilleure mais imparfaite, avec un taux d’interêt inférieur.
Soit on accepte de rembourser cette dette avant qu’elle ne soit ingérable
- Refactoriser ou remplacer le code, le framework, la stack technique …
Une dette pour l’eXpérience Utilisateur ?
Cette idée de dette UX est évidemment héritée de la dette technique. Ces deux types de dettes ont en effet des similitudes:
- Elles ne peuvent pratiquement pas être évitées
- Elles sont difficiles à qualifier, quantifier
- Elles peuvent ralentir ou anéantir un projet
La dette UX a ses propres particularités et provient
- de contraintes de planning, de budget et de ressources humaines
- de décisions (nouvelle features par exemple) prises sans comprendre ou anticiper l’impact causé sur l’expérience …
Pour mieux comprendre l’origine de cette dette UX, utilisons la pyramide des besoins de l’utilisateur comme théorisé par Aarron Walter (sur le modèle de Maslow).
La dette UX peut donc être définie comme la différence entre la qualité actuelle du produit et celle souhaitée ou recherchée initialement.
Un intervenant UX cherchera toujours à atteindre le sommet de la pyramide, du moins en théorie. En pratique, le résultat dépendra du contexte et des objectifs. Par exemple, dans le cas d’un MVP (minimum viable product) atteindre le niveau fonctionnel sera suffisant.
La dette UX est un phénomène beaucoup moins reconnu que la dette technique notamment à cause du niveau de menace qui en résulte. Une dette technique élevée peut se traduire par un produit qui cesse de fonctionner. Dans le cas de la dette UX, ce sera un peu plus insidieux.
Avant de gérer cette dette, il va donc falloir l’identifier.
Identifier la dette UX
- “On testera ça plus tard”
- “On l’améliora dans une prochaine version”
- “On a revu les priorités, on va plutôt faire une nouvelle feature.”
- “On a pas le temps”
- “L’utilisateur apprendra/comprendra”
Si vous entendez ce genre de phrases au quotidien, la dette UX est déjà dans vos murs et prend essentiellement deux formes.
Une dette intentionnelle
- La résistance au changement ou l’inertie de certaines organisations. Qui peut se traduire comme cela m’est encore arrivé récemment par un “l’UX c’est du bon sens” où comment nier l’importance d’une stratégie user/customer centric. L’UX est évidemment l’affaire de tous mais c’est avant tout la responsabilité d’experts qui en sont les garants.
- La gestion du produit et la stratégie mise en oeuvre. Exemples: concentrer les efforts uniquement sur de nouvelles fonctionnalités (On parle alors de “feature factory”, phénomène qui fera l’objet de mon prochain article Medium), sur des demandes clients, des périmètres “flottants” …
- Par manque de temps, de budget, de ressources humaines, de tests ou tout simplement par manque de volonté.
Une dette involontaire
- Une connaissance utilisateur/client insuffisante. Les besoins ou les attentes des utilisateurs évoluent dans le temps.
- Le cloisonnement des équipes design & dev
- (…)
Gérer la dette UX
Pour moi, la dette doit être prise en main par un UX, idéalement par un profil lead ou architecte. Il faudra alors:
- Récolter, documenter et classifier les éléments qui composent la dette
Utilisez le produit ainsi qu’une grille d’évaluation heuristique. Si c’est possible, soyez plusieurs à participer à cet inventaire.
Vous utiliserez une classification pour pouvoir distinguer les éléments entre eux et pouvoir les attribuer aux bons interlocuteurs: technique (Back End ou Front End), fonctionnel (architecture de l’information, priorisation des fonctionnalités…), comportemental (modèle ergonomique), visuel (DA et UI, consistance graphique et éditoriale…).
Evidemment, il faudra une phase d’observation et d’interview auprès d’utilisateurs pour valider cet inventaire.
- Comparer et prioriser les améliorations envisagées
Pour établir un ordre d’importance, il va falloir déterminer le degré de sévérité de l'élément, la priorité donnée pour le traiter, un ETA (Estimated Time to Adress) et enfin le responsable opérationnel qui sera en mesure d’intervenir.
- Mesurer l’impact de ces améliorations
Dans votre inventaire, vous pourrez suivre ce qui est fait et qui reste à faire. Vous allez ainsi pouvoir mesure l’impact des modifications avec des données et indicateurs (NPS par exemple), avec des tests utilisateurs …
Limiter la dette
La dette UX est une responsabilité collective. Pour la réduire, il faut que chaque partie prenante du projet en ait conscience et :
- Mesurer l’utilisabilité du produit et tester auprès d’utilisateurs le plus souvent possible
- Rechercher un niveau de qualité élevé dans les équipes: UX, UI, Dev Front & Back, PO …
- Documenter le produit tout au long de sa vie
Sources
