Présentez-moi votre processus de design, du brief à la livraison.

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.

Comment gérez-vous les situations où les parties prenantes remettent en question vos décisions de design ?

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.

Comment mesurez-vous si un design est réussi ?

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.

Parlez-moi d'un moment où vous avez dû concevoir avec des contraintes importantes.

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.

Décrivez un moment où votre design était erroné et comment vous avez géré cela.

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.

Comment collaborez-vous avec des développeurs qui contestent vos designs ?

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.

Comment abordez-vous l'accessibilité dans votre travail de design ?

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.

Comment aborderiez-vous un test d'utilisabilité de zéro ?

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.

Comment décidez-vous entre prototypes haute et basse fidélité ?

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é.

UX Designer

Les entretiens pour un poste d'UX Designer évaluent votre processus de design thinking, votre capacité à défendre les intérêts des utilisateurs et votre collaboration avec les équipes produit et technique. Les recruteurs veulent voir des projets de portfolio qui démontrent une vraie résolution de problèmes, pas seulement des maquettes soignées. Ce guide couvre les questions les plus fréquentes et les réponses qui distinguent les designers qui livrent de vrais produits de ceux qui produisent uniquement de beaux écrans.

Pour des conseils généraux de préparation aux entretiens, consultez notre guide sur les questions d'entretien courantes.

Questions d'entretien courantes pour UX Designer

Questions comportementales pour les postes UX Designer

Questions techniques pour les candidats UX Designer

Ce que les recruteurs recherchent pour un poste UX Designer

Ce que les recruteurs cherchent vraiment chez les candidats UX Designer :

Le processus avant le portfolio. Une étude de cas soignée sans justification est moins impressionnante qu'un processus moins parfait qui montre une pensée claire. Guidez-les à travers le problème, pas seulement la solution.
Une vraie empathie utilisateur. Pouvez-vous décrire des utilisateurs réels avec précision ? Les designers qui parlent des "utilisateurs" comme d'un groupe abstrait n'ont souvent pas fait assez de recherche.
L'instinct collaboratif. Les UX designers qui travaillent bien avec l'ingénierie et le produit voient leurs designs construits. Ceux qui traitent la collaboration comme un compromis créent des frictions.
L'aisance dans l'ambiguïté. Les meilleurs designers peuvent opérer quand le brief est vague ou les données minces. Montrez comment vous créez de la structure dans des conditions incertaines.
La conscience business. Savoir pourquoi le produit existe commercialement, et concevoir avec cela en tête, est ce qui sépare les designers seniors des juniors.

Questions à poser à votre interlocuteur

→Comment l'équipe design collabore-t-elle avec le produit et l'ingénierie au quotidien ?
→À quoi ressemble le processus de recherche ici, et combien de temps les designers ont-ils pour la découverte ?
→Comment les décisions de design sont-elles documentées et communiquées à l'ingénierie ?
→À quoi ressemble le succès pour un UX designer dans les six premiers mois ?
→Comment l'entreprise collecte-t-elle et agit-elle sur les retours utilisateurs après le lancement ?

Entrainez-vous sur ces questions avant votre entretien

Le simulateur d'entretien construit une session de pratique autour d'une offre d'emploi spécifique et de votre parcours, pour que vous répétiez les questions les plus susceptibles d'être posées.

Commencer l'entrainement

Gratuit pendant la beta. Sans engagement.

Métiers similaires