Product Designer

Posture de partenariat plutôt que d'opposition : capacité à écouter le point de vue PM ou eng avant de défendre, à proposer des alternatives, à reconnaître les contraintes techniques ou business. Bonus : la·le candidat·e cite la suite (la décision a été tenue, infléchie, ou abandonnée après nouveau signal). Les candidat·e·s qui décrivent les PMs ou ingénieur·e·s comme « ne comprenant pas le design » révèlent une faiblesse de jeu d'équipe qui plombera la vélocité.

Maturité réflexive sur le métier : capacité à nommer un apprentissage concret avec un changement de comportement à l'appui. Bonus : la·le candidat·e identifie ce qu'il·elle aurait fait différemment dès le départ. Les candidat·e·s qui décrivent leurs projets comme « toujours réussis » révèlent une faiblesse de coachabilité.

Capacité à arbitrer contre des coûts irrécupérables. Méthode de décision : signaux qui ont déclenché la remise en cause (tests utilisateur·rice, feedback eng sur la faisabilité, données quantitatives), validation avec les parties prenantes, communication à l'équipe. Les candidat·e·s qui ne peuvent citer aucune direction abandonnée ont probablement vécu uniquement de la livraison sous brief, pas du design produit.

Cadrage avant escalade : (1) clarifier le coût exact et l'origine (complexité d'un composant, contrainte d'accessibilité, état non prévu), (2) évaluer le risque utilisateur si on simplifie l'interaction, (3) proposer 2-3 alternatives chiffrées (version simplifiée, découpe en 2 étapes, accepter le retard). Les candidat·e·s qui maintiennent leur design en bloc ou abandonnent en bloc sans cadrage révèlent une faiblesse d'arbitrage.

Distinction entre maquette d'exploration et maquette de validation : capacité à livrer rapidement de l'exploration tout en signalant les hypothèses non validées et les zones à risque. Proposition d'un protocole léger (5 user interviews en parallèle des maquettes, ou test rapide sur les maquettes mêmes). Les candidat·e·s qui refusent en bloc « parce qu'il faut faire de la recherche » sont aussi mal-fittés que ceux·celles qui exécutent sans rien dire.

Approche progressive : (1) audit des composants existants et identification des duplications les plus coûteuses, (2) extraction d'un noyau de tokens (couleur, typo, espacement) sans bloquer la livraison, (3) bibliothèque de 5-10 composants prioritaires avec gouvernance légère (qui peut ajouter, comment), (4) plan de rénovation incrémentale sur les écrans existants. Les candidat·e·s qui veulent geler la livraison pour refaire un design system de zéro manquent de pragmatisme.

Démarche structurée : (1) instrumenter le funnel pour identifier les étapes coûteuses, (2) lire les sessions enregistrées et lire 5-10 transcriptions de support pour comprendre les blocages, (3) interviews avec utilisateur·rice·s ayant abandonné si possible, (4) hypothèses ordonnées (champ trop tôt, confiance pas établie, valeur pas claire), (5) prototypes A/B sur les 2 étapes les plus coûteuses. Les candidat·e·s qui plongent dans une refonte complète sans cadrer le funnel révèlent une faiblesse de méthode.

Clarifications avant maquettes : volume attendu, typologies (informationnel vs actionnable), persistance des notifs vues, priorité visuelle entre types. Architecture cohérente : pattern unifié (un seul composant qui s'adapte) vs patterns multiples (popover vs centre dédié vs toast), accessibilité (focus management, lecteurs d'écran), états vides et états saturés. Bonus : reconnaissance des zones d'incertitude (« je ferais un test utilisateur·rice rapide sur 2 variantes avant de m'engager »). Les candidat·e·s qui plongent dans Figma sans clarifier révèlent une faiblesse de design système.

Démarche : (1) interviews avec 5-8 utilisateur·rice·s clé·e·s pour comprendre ce qu'ils·elles cherchent réellement à savoir et quelle décision ils·elles veulent prendre, (2) regroupement des indicateurs en 3-5 questions métier, (3) hiérarchie visuelle qui répond à la question dominante en premier coup d'œil, (4) prototype testé sur 5 utilisateur·rice·s avant développement. Bonus : la·le candidat·e propose de retirer des indicateurs plutôt que d'en ajouter une vue secondaire. Les candidat·e·s qui restructurent visuellement sans comprendre l'usage métier livreront un tableau de bord plus joli mais aussi peu utile.

Compréhension des couches : tokens primitifs (couleur brute, espacement de base) vs tokens sémantiques (background-primary, spacing-comfortable) vs composants. Pragmatisme sur le niveau de formalisation : trop léger = duplication ; trop lourd = friction de livraison. Gouvernance proportionnée : qui peut ajouter un composant, processus de revue, versionning. Les candidat·e·s qui décrivent une gouvernance lourde type Material Design pour une équipe de 6 manquent de pragmatisme ; ceux·celles qui n'ont aucune structure révèlent un manque de rigueur.

Connaissance des critères WCAG 2.1 niveau AA (contrastes, navigation clavier, lecteurs d'écran, labels de formulaire, ordre de focus). Capacité à citer 3-5 pièges concrets : contraste insuffisant sur du texte placeholder, états de focus invisibles, modales sans trap de focus, vidéos auto-play sans contrôle, icônes-only sans label accessible. Bonus : la·le candidat·e a déjà testé son design avec VoiceOver ou NVDA. Les candidat·e·s qui répondent « j'utilise les outils Figma » sans citer de critère ou de piège n'ont pas la pratique.

Méthode d'interview ouverte : questions qui cherchent les comportements passés plutôt que les opinions futures (« décrivez la dernière fois où... » plutôt que « accepteriez-vous... »), absence de questions biaisées, prise de notes ou enregistrement pour relire à froid. Bonus : la·le candidat·e cite un apprentissage qui a changé sa direction design. Les candidat·e·s qui n'ont pas fait de recherche récente (< 1 mois) ou qui ne décrivent que des surveys sont déconnecté·e·s de leurs utilisateur·rice·s.

Maturité réflexive sur le métier. Capacité à nommer une qualité ET une difficulté révèle un cadre qui sait observer ses propres modèles. Les candidat·e·s qui ne peuvent que louer ou que critiquer leur ancien·ne lead sont rarement de bon·ne·s designers eux·elles-mêmes.

Curiosité produit authentique : capacité à citer 3-5 produits récents (pas seulement Apple, Notion, Linear par réflexe), avec une analyse précise de ce qui fonctionne ou pas (interaction, hiérarchie, ton, performance perçue). Les candidat·e·s qui répondent par des généralités (« j'aime quand c'est simple ») ou par des produits évidents sans analyse révèlent un manque de regard critique entraîné. Bonus : la·le candidat·e cite un produit que personne ne cite et explique pourquoi.

Ouverture : capacité à dissocier le design de l'ego, à creuser le « pourquoi » derrière la critique (souvent un blocage fonctionnel exprimé en termes esthétiques), à rentrer dans la phénoménologie de l'utilisateur·rice. Bonus : la·le candidat·e cite une fois où une critique utilisateur·rice a changé sa direction. Les candidat·e·s qui décrivent avoir « expliqué leur design » à l'utilisateur·rice révèlent une faiblesse de coachabilité critique pour le métier.