Une question d'entrevue UX courante et classique
On m'a demandé: "Si vous voulez reconcevoir une partie de l'application mais que les ingénieurs ont dit que cela prendrait trop de temps et ne veulent pas la changer, que diriez-vous?"
Je pense que c'est une question d'entrevue très courante et classique qui a été beaucoup posée. Que pensez-vous que c'est une meilleure façon de l'aborder?
J'ai fait face à ce défi à plusieurs reprises et j'ai trouvé que la meilleure façon de gérer ce problème serait d'utiliser les méthodes décrites ci-dessous ou d'utiliser une combinaison d'entre elles:
- Mener des tests d'utilisabilité et obtenir des données sur les points douloureux rencontrés par les utilisateurs utilisant ce module spécifique: J'ai généralement constaté que les équipes d'ingénierie sont plus réceptives si on leur présente des données concrètes sur les problèmes que rencontrent les utilisateurs face plutôt que de simplement présenter un changement de conception. Une façon de procéder consiste à enregistrer les tests d'utilisabilité et à montrer aux utilisateurs réels qui passent par l'interface.
- Créer un prototype avec la conception mise à jour et tester les utilisateurs avec lui pour déterminer les taux de réussite relatifs: Je choisis généralement cette approche lorsque je peux créer un prototype rapide et tester les utilisateurs pour déterminer le succès de la refonte et quels seraient les avantages relatifs de la refonte. Ces données complétées par les données de la méthode précédente sont généralement très bénéfiques pour convaincre la direction, sinon les développeurs
- Briser la refonte proposée en petites étapes itératives qui amélioreraient progressivement l'expérience utilisateur: Cette approche fonctionne vraiment bien lorsque la refonte entière prendrait beaucoup de temps et qu'il existe un certain nombre de petites modifications qui peuvent être apportées pour améliorer l'expérience utilisateur globale. Ces changements peuvent être aussi modestes que la modification du contenu utilisé pour communiquer le processus jusqu'à l'introduction d'un nouveau bouton d'appel à l'action pour piloter le processus.
- Parlez à la direction en termes dans leur langue, c'est-à-dire conversion ou génération de leads ou bénéfices: J'essaie généralement cette approche à la fin lorsque mes efforts n'ont pas vraiment réussi à convaincre les développeurs d'envisager une refonte. Dans ce cas, la meilleure façon serait de parler à la direction des points de douleur potentiels et de la façon dont l'élimination de ces points de douleur entraînerait des conversions ou augmenterait les ventes. Bien que le problème demeure qu'il pourrait s'agir d'une refonte considérable, vous pouvez parfois obtenir des ressources supplémentaires allouées, ce qui rendrait la refonte beaucoup plus rapide.
J'ai également trouvé pratique de proposer de participer et d'aider avec toutes les mises à jour/modifications, si vous êtes à l'aise de vous salir les mains avec le code. Lorsque je propose d'écrire le HTML/CSS/JS nécessaire pour mettre en œuvre le changement, j'ai constaté que nos développeurs sont souvent réceptifs à apporter les changements (cela fonctionne toujours de leur côté, mais offrir de l'aide montre également que vous pensez c'est une mise à jour qui vaut la peine d'être consacrée, plutôt que "quelque chose que le designer veut être plus joli").
Je demanderais pourquoi je voulais le repenser. Je souhaiterais uniquement reconcevoir certaines parties d'une application à condition qu'elle réponde à divers critères:
- les utilisateurs en bénéficieraient
- l'entreprise, à son tour, bénéficierait
À condition que ces critères soient remplis, je serais obligé de présenter une proposition convaincante.
À ce stade, cela devient une question de budget et de ressources et s'il y a un retour sur investissement.
Si ce n'est pas une réponse facile aux chiffres, je chercherais à travailler avec l'équipe technique pour voir si des compromis/alternatives plus réalisables pour tout le monde et produisant toujours un retour sur investissement sont viables.
La première chose que je ferais serait d'essayer de comprendre pourquoi les changements prendraient trop de temps. Le système est-il obsolète? Y a-t-il des améliorations à la conception technique de l'application qu'ils aimeraient accomplir mais qui n'ont pas retenu l'attention ni priorisé? Ont-ils d'autres priorités qui sont plus importantes pour eux et pourquoi? Est-il possible que nous puissions trouver un gagnant-gagnant qui a soutenu les changements d'expérience client nécessaires ainsi que les objectifs des ingénieurs.