Pennylane est une plateforme SaaS B2B de comptabilité et gestion financière conçue pour faciliter la collaboration entre entreprises et experts-comptables. La boîte a six ans, plus de mille salariés, trente-cinq squads, et une équipe design d'une cinquantaine de personnes organisée en tracks. Le live donne à voir ce qu'on évalue vraiment dans un case study — et comment passer de "candidat qui présente une solution" à "designer qui pense comme un senior".
1. Candidate, intervieweuse, voix off
Yasmina joue l'intervieweuse, Alice joue la candidate. Le faux brief porte sur AstraShield, une plateforme fictive de gestion des accès aux outils internes (Jira, GitHub, Salesforce). Le problème : des délais d'attente de plusieurs jours côté demandeur, et des approbations prises sans compréhension des permissions côté approbateur.
Tout au long du roleplay, Yasmina commente en voix off : pourquoi tel élément est intéressant, ce qu'il dit sur le niveau de séniorité, ce que les intervieweurs cherchent vraiment.
Le brief est envoyé une semaine avant l'entretien, par mail, avec des données qualitatives, des verbatims, des écrans Figma initiaux et un accès au design system. Il n'y a pas de "travail caché" : le sujet est entièrement inventé, pas un vrai sujet en cours chez Pennylane.
2. La solution compte peu. Le raisonnement compte beaucoup.
Yasmina le pose d'emblée : "Ce qu'on va vraiment chercher à comprendre, c'est votre raisonnement, la méthodologie, la façon dont vous prenez les décisions — beaucoup plus que la solution finale qui va être proposée."
Les dimensions évaluées : Hard skills — cadrage du problème, usage des données quali et quanti, argumentation des choix, priorisation entre solutions, craft Figma (organisation du fichier, UX writing, qualité des composants).
Soft skills — clarté de communication, storytelling, capacité à embarquer l'audience, posture de collaboration avec PM, designers, engineering manager.
Posture face au feedback : "On va regarder comment vous réagissez au feedback. Est-ce que vous êtes dans une posture de construction ou un peu plus de posture défensive ?"
"Ce qu'on va vraiment chercher à comprendre, c'est votre raisonnement, la méthodologie, la façon dont vous prenez les décisions, beaucoup plus que la solution finale."
3. Montrer sa posture dès la première minute
Alice ouvre son case study en posant l'angle : réduire les frictions des accès aux outils. Elle rappelle le contexte d'AstraShield, les deux problèmes identifiés (délais côté demandeur, validation sans contexte côté approbateur), et — point clé — elle dit d'emblée ce qu'elle n'a pas : pas d'accès aux utilisateurs, pas d'analytics. Elle explique comment elle contourne.
Commentaire de Yasmina : "Elle dit qu'il lui manque des données, elle nous explique comment elle les contourne. Ça donne tout de suite une posture senior. Dans la vraie vie, on peut avoir des difficultés d'accès aux users, un tracking qui n'est pas en place. Expliquer comment on va contourner ces contraintes montre qu'on sait que c'est possible et qu'on ne se contente pas de dire 'je n'ai pas fait de recherche quali parce que je n'avais pas accès aux users'."
Sur l'usage de l'IA : Alice mentionne l'utiliser "comme partenaire de ping-pong pour traiter des cas à la marge, des hypothèses de solutions, du copywriting."
4. Redonner les chiffres du brief sans les interpréter
Alice part d'un verbatim d'approbateur qui dit qu'il reçoit dix à quinze demandes par jour, qu'elles se ressemblent toutes, et qu'il les approuve "pour vider la file". Son interprétation : "Le problème, ce n'est pas le volume. C'est le mot 'vider'. Ça laisse entendre qu'il y a une charge mentale, que l'approbateur ne cherche plus à prendre la meilleure décision. L'approbation par défaut, ça devient 'oui'."
Elle croise ensuite avec les chiffres du brief : vingt-huit pour cent d'abandon à l'étape de sélection du rôle, trente-trois pour cent de justifications vides ou d'un mot. "Ce ne sont pas des frictions cosmétiques. Ce sont des signaux forts que l'architecture du flux décourage sa propre complétion."
Commentaire de Yasmina : "L'erreur qu'on voit souvent, c'est de redonner les données du brief comme ça, sans apporter plus de profondeur. Montrer comment on fait le tri dans les différentes datas et comment on les met ensemble pour apporter une compréhension — c'est vraiment ce qu'on va rechercher dans l'usage de la data."
5. Ne pas s'arrêter au problème de surface
Après le benchmark (trois acteurs matures qui affichent systématiquement niveau de risque, recommandation de décision et explication en langage clair — rien de tout ça chez AstraShield), Alice recadre le problème.
"Optimiser ça, c'est optimiser le symptôme. La tâche réelle que l'utilisateur cherche à accomplir, ce n'est pas 'traiter une demande'. C'est 'prendre une décision fiable en très peu de temps'. Je vais donc designer pour le moment de la décision."
Elle pose deux hypothèses : un problème de contexte (solution : plus d'informations au moment pertinent, mesurée sur un time to decision) et un problème de justification de l'urgence (solution : score basé sur l'historique, mesurée sur les champs complétés).
Sur la priorisation : elle décide de livrer l'option A en V1 (contexte intégré, impact élevé, effort faible) et de reporter volontairement le score automatisé à la V2. "L'option B suppose un volume de données qualifiées qu'on n'a pas au départ. Le construire maintenant, ça reviendrait à surinvestir sur des choses sophistiquées avant même d'avoir validé le besoin."
Commentaire de Yasmina : "La priorisation est souvent zappée — soit parce que les candidats sont allés directement à la solution qui leur semble la plus intéressante, soit parce que c'est carrément oublié. C'est hyper clé chez nous d'être en capacité de démontrer qu'il y a plusieurs solutions à un même problème, et surtout, comment et pourquoi on va finalement choisir telle ou telle solution."
6. Définir l'échec en amont, pas seulement le succès
Alice décrit son plan de validation en deux phases. D'abord des tests utilisateurs non modérés (huit à dix participants). Critère de validation : quatre-vingts pour cent accomplissent l'approbation en moins de vingt-cinq secondes, sans aide, et la pastille de risque est remarquée spontanément. Critère d'invalidation : sous soixante pour cent de complétion ou confusion systématique. "J'insiste sur le 'sans aide' parce que sinon, on fausse complètement la mesure."
Ensuite, un A/B test en production. Validation : plus de dix points de complétion à l'étape deux sans régression du taux de soumission. Invalidation : régression de plus de deux points.
Sur la mesure de succès : elle reprend les données du brief (abandon étape 2 à vingt-huit pour cent, objectif moins de dix pour cent ; champs vides à trente-trois pour cent, objectif moins de dix pour cent) et ajoute une métrique absente du brief — le temps médian d'approbation, avec une cible de réduction de moitié à quatre-vingt-dix jours.
Commentaire de Yasmina : "Ça, ça montre un vrai niveau d'expérience et de séniorité. Elle va non seulement reprendre les données du brief, mais elle propose une mesure qu'elle considère importante et qui n'est pas dans le brief. Et ça, ça montre un niveau d'expérience qu'on voit assez rarement dans les case studies."
"Elle définit des métriques en amont qui permettraient de dire : est-ce que je valide cette solution ? Est-ce qu'il faut que je revienne travailler dessus ? Ça montre un niveau d'expérience assez fort qu'on voit assez rarement dans les case studies."
7. Projeter l'intervieweur dans votre quotidien
Alice décrit les rituels qu'elle mettrait en place : un point hebdomadaire avec le PM pour faire émerger les arbitrages tôt et les acter par écrit, des vidéos courtes en différé avec les développeurs pour documenter les flots utilisateurs, une vérification d'alignement avec le design system, un déploiement progressif avec des points de contrôle rapprochés.
Commentaire de Yasmina : "Ça permet de dérisquer la question du fit, qui est un sujet assez épineux parce que c'est beaucoup de feeling. Montrer la façon dont vous collaborez déjà avec vos principaux stakeholders, ça permet aux personnes qui interviewent de se projeter — si cette personne rejoignait l'équipe, ça pourrait ressembler à ça. Ça enlève du flou."
Ce que Pennylane recommande aux candidats
Aider les intervieweurs à se projeter dans votre raisonnement, même sans accès aux users — expliquer comment vous auriez fait. Justifier vos positions et montrer comment vous les argumentez. Le end-off est toujours sur Figma — la qualité des fichiers compte, y compris l'UX writing. Ne pas montrer trop de choses : "Ça peut vite donner la sensation qu'on a mal priorisé." Réagir au feedback de manière constructive, pas défensive.
Ce que Pennylane recommande aux hiring managers
Un brief clair avec des données concrètes pour éviter les directions hors sujet. Évaluer le process, pas la solution. Faire passer les entretiens à deux pour limiter les biais.
Sur l'IA dans le case study : "On voit de plus en plus de candidats qui construisent leur solution sur Claude. Ça nous a demandé de leur demander de produire quelques Figma en plus, parce que c'est comme ça qu'on travaille encore. Mais oui, la question de comment vous utilisez l'IA est tout le temps posée."