Questions d'entretien UX Designer

Mon processus commence par comprendre le problème avant de toucher à un outil de design. Je démarre par une phase de découverte : examen des recherches existantes, interviews des parties prenantes pour aligner les objectifs et les contraintes, et analyse concurrentielle si le temps le permet. J'enchaîne avec la recherche utilisateur, qu'il s'agisse d'interviews, d'observation ou d'analyse des données, pour comprendre qui je conçois et ce dont les utilisateurs ont réellement besoin. Je définis ensuite le problème clairement, souvent avec une formulation "Comment pourrions-nous", avant de passer à l'idéation. Je sketche largement, puis converge vers les directions les plus prometteuses pour prototyper. Je teste les prototypes avec de vrais utilisateurs le plus tôt possible, même sur papier, pour ne pas découvrir les problèmes après que l'ingénierie a investi. La transmission comprend des spécifications annotées, les cas limites documentés, et je reste impliqué pendant l'implémentation.

Je traite les objections comme des informations, pas comme de l'opposition. Ma première étape est de comprendre ce qui motive la préoccupation : parfois c'est une contrainte légitime dont je n'avais pas connaissance, parfois c'est de l'aversion au risque, et parfois c'est une préférence personnelle habillée en logique business. Je fais la distinction. Pour les contraintes réelles, j'adapte le design. Pour l'aversion au risque, je propose un test léger pour réduire l'incertitude. Pour les conflits de préférence personnelle, je ramène la décision à la recherche utilisateur ou aux données. J'ai appris à présenter les décisions de design avec la justification dès le départ, ce qui réduit la fréquence des objections. Quand une partie prenante écarte une décision que je pense mauvaise pour les utilisateurs, je documente ma préoccupation et demande une métrique de suivi.

Le succès dépend de ce que le design devait accomplir, donc je commence par m'accorder sur des métriques avant de commencer à concevoir. Pour les flux basés sur des tâches, je suis le taux de complétion et le taux d'erreur, d'abord via les tests d'utilisabilité puis via les analytics en production. Pour les objectifs produit plus larges, je relie mon travail à des métriques business comme la conversion, la rétention ou la réduction des tickets support. Je suis aussi des signaux qualitatifs : les utilisateurs peuvent-ils décrire ce que fait une fonctionnalité sans aide ? Je suis sceptique quant aux métriques proxy comme le "temps sur la page" qui peut signaler autant l'engagement que la confusion. Après le lancement, je fais un bilan structuré à 30 et 90 jours.

Dans une entreprise précédente, on m'a demandé de refondre un parcours d'onboarding mobile avec deux semaines de délai et sans budget pour de la recherche utilisateur supplémentaire. Plutôt que de repartir de zéro, j'ai extrait les données analytics pour identifier les trois étapes avec le plus fort taux d'abandon et comparé le flux existant à des benchmarks concurrents. J'ai réalisé cinq tests guerrilla au bureau avec des collègues correspondant à notre profil utilisateur pour une validation directionnelle. J'ai focalisé ma refonte sur ces trois zones problématiques plutôt que de tout revoir, ce qui a rendu le périmètre gérable et le travail technique faisable dans les délais. Le taux d'abandon à l'étape critique a baissé de 18% le premier mois.

J'ai conçu une nouvelle structure de navigation pour une application B2C sur laquelle j'avais confiance après les tests internes. Après le lancement, les tickets support sur l'incapacité à trouver des fonctionnalités clés ont augmenté de 30% la première semaine. Je n'avais pas testé suffisamment avec des utilisateurs ne connaissant pas l'ancienne navigation : nos testeurs internes avaient une mémoire musculaire qui masquait le problème. J'ai alerté l'équipe immédiatement. Nous avons réalisé un test d'utilisabilité d'urgence avec cinq utilisateurs externes dans les 48 heures, qui a confirmé le problème et identifié deux points de défaillance précis. Nous avons livré un correctif ciblé en une semaine. J'inclus désormais systématiquement des utilisateurs sans exposition préalable dans les tests de navigation.

J'essaie de comprendre la préoccupation avant de défendre le design. Les objections des développeurs viennent généralement de trois endroits : infaisabilité technique, effort disproportionné par rapport à la valeur perçue, ou préférence pour une solution plus simple déjà imaginée. Les deux premiers sont des inputs légitimes que j'intègre. Pour les problèmes de faisabilité, je demande ce qui est possible et je recouvre dans cette contrainte. Pour les préoccupations d'effort, je demande une estimation et j'utilise cela pour décider de simplifier ou de maintenir ma position. J'ai constaté qu'impliquer les développeurs plus tôt dans le processus, partager les résultats de recherche et les inviter dans la définition du problème, réduit considérablement les frictions par la suite.

Je traite l'accessibilité comme une contrainte de design dès le départ, pas comme une checklist en fin de projet. En pratique, cela signifie choisir des combinaisons de couleurs qui respectent les ratios de contraste WCAG AA pendant la phase de design, dimensionner les zones tactiles à au moins 44px et concevoir la navigation au clavier en parallèle de la souris. J'utilise une structure sémantique dans mes specs pour que les développeurs sachent quels éléments correspondent à des titres, boutons ou landmarks. Je conçois aussi pour différents modes d'entrée, y compris les lecteurs d'écran. Dans les tests d'utilisabilité, j'essaie d'inclure au moins une session avec un utilisateur qui dépend d'une technologie d'assistance. J'ai constaté que concevoir de manière accessible produit généralement une UX plus propre pour tout le monde.

Je commence par définir la question à laquelle le test doit répondre, car la méthode suit la question. Pour un test évaluatif d'un flux spécifique, j'utilise des tests basés sur des tâches modérés avec cinq à huit participants : suffisant pour faire émerger des patterns sans sur-investir. J'écris les tâches en termes de résultats, pas d'instructions : "Vous voulez retrouver l'historique de vos commandes" plutôt que "cliquez sur le menu compte". J'utilise le protocole de pensée à voix haute pour capturer le raisonnement. Je note les hésitations, erreurs et parcours inattendus. J'analyse en regroupant les observations par participants, cherchant des patterns plutôt que des préférences individuelles. Je présente les résultats avec des niveaux de sévérité et des recommandations priorisées.

La fidélité doit correspondre à la question que j'essaie de répondre. Pour explorer si un concept a du sens structurellement, un sketch rapide ou un prototype papier est plus rapide et évite que les gens réagissent au polissage visuel plutôt qu'à l'interaction. Pour tester du microcopy spécifique ou la hiérarchie visuelle, j'ai besoin de suffisamment de fidélité pour que le wording et la mise en page soient proches du final. Pour les présentations aux parties prenantes où l'adhésion dépend de leur vision du produit fini, une haute fidélité réduit l'effort cognitif. L'erreur la plus fréquente est d'investir dans la haute fidélité trop tôt, avant que la structure soit validée, puis de devoir jeter du travail soigné.