Que testent vraiment les entretiens UX designer ?

Face à qui vous vous retrouverez vraiment

Un entretien pour un poste de UX designer est rarement une seule conversation. C'est généralement une séquence : un échange avec un recruteur, puis une revue de portfolio avec un ou deux designers, puis un exercice de design ou un défi au tableau blanc, puis un tour avec les personnes avec qui vous travailleriez réellement — un chef de produit, un ingénieur, parfois un chercheur — et souvent une discussion finale avec le responsable du recrutement ou le lead design. Les petites entreprises compressent cela en deux ou trois sessions ; les plus grandes l'étalent sur des semaines avec un débriefing formel entre les tours où les intervieweurs comparent leurs notes sur une grille d'évaluation.

La revue de portfolio est la partie qui pèse le plus lourd, et elle est généralement menée par un designer en activité, pas par les RH. C'est important parce qu'ils ont construit ce que vous décrivez et connaissent les points de friction. Ils n'évaluent pas vos slides. Ils écoutent si vous pouvez expliquer une décision sous une légère pression, et si la décision était vraiment la vôtre.

La revue de portfolio : ce qu'ils font vraiment

Le format standard est « présentez-moi un projet ». Ça ressemble à une conversation informelle. Ça ne l'est pas. Un designer qui mène cette revue vérifie quelques éléments précis pendant que vous parlez :

• D'où vient le problème. Un décideur vous a-t-il donné une solution déguisée en brief (« nous avons besoin d'un tableau de bord »), ou avez-vous accédé au besoin sous-jacent ? Si vous dites « le PM a demandé X » puis décrivez la construction de X, c'est un signal d'alarme. Si vous dites « le PM a demandé X, mais quand j'ai regardé les tickets de support et fait trois entretiens utilisateurs, j'ai découvert que le vrai point de friction était Y », c'est la réponse qu'ils attendent.
• Ce que vous avez réellement fait versus ce que l'équipe a fait. Les études de cas rédigées pour un portfolio tendent à utiliser « nous » partout. Un bon intervieweur interrompra et demandera « quelle a été votre contribution spécifique à ce flux ? » Si vous ne pouvez pas séparer votre travail de celui de l'équipe, ils supposent que vous avez juste suivi le mouvement.
• Les compromis que vous avez faits et pourquoi. Pas « nous avons envisagé quelques options et choisi la meilleure » — quelle option, qu'aurait-on perdu dans chaque cas, et quelle donnée ou contrainte a fait pencher la balance. Délai d'ingénierie, dette technique, directives de marque, exigences d'accessibilité, un décideur qui ne bougerait pas — nommez la contrainte réelle.
• Ce qui s'est passé après le lancement. Avez-vous regardé les chiffres, mené un test d'utilisabilité de suivi, obtenu le volume de tickets de support, ou le projet s'est-il terminé à la remise à l'ingénierie ? Beaucoup de candidats n'ont pas de réponse ici parce que l'organisation n'a jamais bouclé la boucle, et un intervieweur décent le notera sans vous le reprocher — mais il vous le reprochera si vous revendiquez un résultat que vous n'avez jamais mesuré.

Une réponse superficielle dans une revue de portfolio semble fluide et ne dit rien de vérifiable : « nous avons redessiné le flux d'onboarding et ça a vraiment amélioré l'expérience utilisateur ». Pas de base de référence, pas de métrique, pas de contrainte nommée, pas de distinction entre votre contribution et celle de l'équipe. Quelqu'un qui évalue des portfolios pour gagner sa vie entend cela constamment et arrête d'écouter en une phrase.

L'exercice de design ou défi au tableau blanc

C'est l'évaluation pratique, et son format varie beaucoup selon l'entreprise, donc soyez précis sur le type qu'on vous demande de faire :

• Exercice en direct au tableau blanc/Figma. On vous donne une consigne sur le moment — « redesigner le flux de paiement pour une application d'épicerie » ou « concevoir un moyen pour deux personnes de partager une addition » — et on vous demande d'esquisser, de structurer votre réflexion, et d'en parler en temps réel, souvent dans Figma ou FigJam ou littéralement un tableau blanc. Ce n'est pas évalué sur le polish visuel. C'est évalué sur si vous posez des questions de clarification avant de dessiner quoi que ce soit (qui est l'utilisateur, quel appareil, quelle est la contrainte métier), si vous envisagez plus d'une structure, et si vous pouvez défendre une décision quand l'intervieweur conteste — parce qu'il contestera, délibérément, pour voir si vous cédez ou raisonnez.
• Exercice à emporter. Un brief sur lequel vous travaillez pendant quelques jours et que vous présentez. Ici, ce qui est testé se rapproche du vrai travail : pouvez-vous cadrer un brief véritablement ambigu, et pouvez-vous présenter une justification à une salle, pas juste remettre des écrans. Si le brief ne spécifie pas de méthode de recherche, en utiliser une quand même (même un test guérilla léger avec cinq personnes) et le mentionner est généralement remarqué.
• Exercice de critique. On vous montre un écran ou flux existant — parfois le propre produit de l'entreprise — et on vous demande ce que vous changeriez. Cela teste le jugement plus que l'exécution : pouvez-vous identifier le vrai problème d'utilisabilité (une hiérarchie d'information confuse, une convention de plateforme violée, un échec d'accessibilité comme un contraste insuffisant ou des états de focus manquants) plutôt que de faire des suggestions cosmétiques sur la couleur et la police.

Une réponse superficielle dans n'importe lequel de ces cas ressemble à une opinion de design sans utilisateur dedans : « j'agrandirais le bouton et changerais la couleur pour le faire ressortir ». Un designer qui vous interviewe veut entendre quel problème spécifique le changement résout — découvrabilité, ratio de contraste, taille de cible tactile, compétition avec un élément visuel plus fort à proximité — et idéalement un moyen de vérifier si le changement a fonctionné.

Les questions qui ne portent pas vraiment sur le design

Quelques questions reviennent précisément parce qu'elles sont difficiles à simuler, et elles méritent d'être nommées parce qu'elles ne ressemblent pas à des questions techniques en surface.

« Racontez-moi une fois où un décideur n'était pas d'accord avec votre design. » C'est une question de collaboration déguisée en histoire de conflit. Une réponse faible se termine par « et finalement ils ont vu les choses à ma façon » ou, pire, « j'ai juste fait ce qu'ils voulaient ». Une réponse forte décrit un désaccord spécifique, quelle preuve ou raisonnement chaque partie avait, et une résolution qui a impliqué de vraiment changer quelque chose — soit votre design, soit votre propre point de vue, sur la base de quelque chose que vous avez appris. Si rien ne bouge jamais dans vos histoires, c'est un signal que vous ne négociez pas réellement, vous ne faites que raconter.

« Comment savez-vous quand un design est terminé ? » ou « Comment gérez-vous une fonctionnalité sans temps pour la recherche ? » Ces questions sondent si vous avez un processus fonctionnel sous des contraintes réelles, pas le double diamant du manuel. Une réponse superficielle récite un framework par son nom — « je commence toujours par une carte d'empathie, puis l'idéation, puis le prototypage » — sans jamais le relier à une contrainte. Un designer expérimenté décrit ce qu'il a coupé et pourquoi : « il n'y avait pas de temps pour une étude complète, donc j'ai mené un test non modéré de cinq minutes sur les deux écrans les plus risqués et utilisé ça pour décider entre deux directions ».

« Comment travaillez-vous avec l'ingénierie ? » Cela vérifie si vous comprenez ce que vous remettez réellement — les états des composants, les cas limites, les états vides, les états d'erreur, pas juste le parcours heureux — et si vous avez déjà eu un design qui a changé à cause d'une vraie contrainte technique que vous n'aviez pas anticipée. Si votre réponse implique que les ingénieurs construisent juste ce que vous leur envoyez, cela se lit comme de l'inexpérience, pas de la confiance.

Les questions de métriques et business — « comment mesureriez-vous le succès de cette fonctionnalité », ou « comment décidez-vous quoi prioriser » — vérifient si vous pouvez relier une décision de design à un chiffre qui compte pour l'entreprise (conversion, temps d'achèvement de tâche, volume de tickets de support, rétention) plutôt que seulement à un langage esthétique ou d'utilisabilité. Vous n'avez pas besoin d'être analyste de données, mais nommer une métrique que vous suivriez réellement, même approximativement, vous sépare de quelqu'un qui n'a jamais eu à justifier une place dans la roadmap.

Que faire de tout ça

Avant tout entretien, choisissez deux ou trois projets et reconstruisez l'histoire de chacun autour de : le problème réel derrière le brief, un compromis difficile, votre contribution spécifique versus celle de l'équipe, et ce qui s'est passé après le lancement, même si la réponse est « nous ne l'avons pas mesuré et voici ce que je suivrais la prochaine fois ». Cette dernière honnêteté fonctionne mieux qu'une vague affirmation de succès.

Si vous faites un exercice de design en direct, pratiquez les quatre-vingt-dix premières secondes — les questions de clarification — plus que le dessin. La plupart des performances faibles ne sont pas de mauvaises idées, c'est un candidat qui commence à esquisser avant de savoir qui est l'utilisateur ou quelle est la contrainte.

Et si le problème auquel vous faites réellement face est antérieur à tout cela — des candidatures qui ne mènent nulle part et aucun entretien à préparer — c'est un problème différent avec un mécanisme différent, qui mérite d'être résolu avant de peaufiner les réponses d'entretien pour un appel qui ne vient jamais. jobmarket.pro lit l'annonce en entier, la met en correspondance avec un profil de votre expérience réelle, et prépare la candidature à partir de ça, sans inventer quoi que ce soit que vous n'avez pas fait.