Product Designer

Je considère un design system comme un produit à part entière, avec ses propres utilisateurs : les designers et les développeurs qui s'en servent au quotidien. Avant d'ajouter un nouveau composant, je vérifie si un pattern existant peut résoudre le problème avec une simple variante. Chaque composant est livré avec des règles d'usage claires, des notes d'accessibilité, et une implémentation cohérente entre Figma et le code, pour que les deux ne divergent jamais. J'organise une permanence toutes les deux semaines où n'importe quel designer ou développeur peut signaler une lacune qu'il a repérée dans le système, et je maintiens un backlog de propositions revu chaque mois plutôt qu'ajouté au fil de l'eau. Quand un composant change, j'audite tous les écrans qui l'utilisent avant de livrer la mise à jour, car une régression silencieuse sur un composant partagé a un impact bien plus large qu'un bug isolé. Je surveille aussi l'adoption : si un nouveau pattern reste inutilisé après un trimestre, je me demande s'il répondait à un vrai besoin ou s'il semblait juste être une bonne pratique sur le moment.

Je commence par écrire un petit nombre de tâches précises liées au parcours que je teste, en général trois à cinq, formulées comme des objectifs plutôt que des instructions pour ne pas orienter le participant. Je recrute cinq à huit utilisateurs correspondant au profil cible plutôt que des collègues disponibles, car les testeurs internes en savent déjà trop sur le produit. Pendant la session, je demande aux participants de réfléchir à voix haute et je résiste à l'envie d'expliquer ou de défendre le design quand ils rencontrent une difficulté. Je note les moments d'hésitation, pas seulement les échecs complets, car l'hésitation révèle souvent la même confusion à une échelle plus discrète. Ensuite, je regroupe les observations par tendance plutôt que de traiter chaque commentaire comme un bug isolé, et je distingue la sévérité de la fréquence : un problème rare qui bloque une tâche essentielle passe avant un problème fréquent qui coûte quelques secondes. J'apporte l'extrait du moment le plus révélateur en restitution, car une courte vidéo fait avancer une discussion avec les parties prenantes plus vite qu'une diapositive de résultats.

J'implique les deux avant d'avoir une solution, pas après. Avec le product manager, je veux une clarté partagée sur le problème et la métrique de succès avant d'ouvrir Figma, pour ne pas négocier le périmètre une fois le design déjà produit. Avec les développeurs, je partage des explorations volontairement brutes plutôt qu'une maquette finalisée, car une version brute invite à un vrai retour sur la faisabilité, alors qu'une version polie invite surtout à des hochements de tête silencieux. Je demande directement aux développeurs ce qui serait coûteux à construire, et je traite cette information comme un vrai input de conception plutôt que comme une contrainte à combattre. Pendant l'implémentation, je garde un rôle actif grâce à une passe de QA design légère sur l'environnement de recette, en vérifiant les espacements, les états et les cas limites comme les états vides ou d'erreur, souvent relégués au second plan sous la pression des délais. Quand les priorités entrent en conflit, j'essaie de recentrer la discussion sur le problème utilisateur validé au départ, ce qui ramène généralement le débat vers les preuves plutôt que vers les préférences personnelles.

L'IA intervient à plusieurs étapes de mon travail aujourd'hui. En amont, je l'utilise pour générer rapidement des variations sur une idée de mise en page, ce qui me donne plus de points de départ avant de m'engager sur une direction, bien plus vite que d'esquisser six versions à la main. Pour la recherche, je m'en sers pour résumer des réponses ouvertes d'enquêtes ou des notes d'interviews en grandes thématiques, mais je vérifie toujours ce résumé par rapport aux transcriptions brutes, car il arrive qu'il lisse une contradiction importante. Pour le microcopy dans les interfaces, je l'utilise pour proposer des options de texte pour les boutons, les états vides et les messages d'erreur, puis je retravaille moi-même le ton et la concision. Là où je ne l'utilise pas, ce sont les arbitrages de fond : ce que le design doit communiquer, quel compromis compte le plus pour cet utilisateur précis, et comment un parcours doit se ressentir. Ces décisions ont besoin d'un contexte sur le produit et l'utilisateur que l'outil n'a pas, donc je considère l'IA comme un moyen d'arriver plus vite à un premier jet, pas comme un substitut à la réflexion qui suit.

J'ai présenté une refonte du parcours de paiement en revue devant notre head of design et deux product designers seniors, et les retours ont été bien plus durs que prévu : plusieurs personnes estimaient que le nouveau parcours ajoutait une étape à un problème qui n'en avait pas besoin. Mon premier réflexe a été d'expliquer mon raisonnement, mais je me suis arrêté et j'ai plutôt demandé quelle preuve précise pourrait changer leur avis, car défendre le travail dans la salle n'allait rien résoudre. Nous avons convenu d'un test non modéré rapide avec huit utilisateurs comparant l'ancien et le nouveau parcours sur le temps de complétion et la confusion rapportée. Le test a montré que ma version était en fait plus rapide, mais moins bien notée sur la confiance : les gens n'étaient pas sûrs que leur commande était passée. J'ai utilisé ce résultat pour garder le changement structurel tout en ajoutant un état de confirmation plus clair, ce qui répondait à la vraie inquiétude derrière la critique plutôt qu'à la critique telle qu'elle avait été formulée. La version révisée a été livrée et les tickets de confusion au paiement ont baissé d'environ 18 % le mois suivant.

La direction voulait simplifier notre page tarifs en retirant le tableau comparatif des fonctionnalités, partant de l'idée qu'il submergeait les visiteurs. J'ai mené cinq sessions modérées avant que le changement ne soit livré, et j'ai trouvé l'inverse : les utilisateurs en phase de comparaison s'appuyaient précisément sur ce tableau pour justifier l'achat auprès d'eux-mêmes ou d'un manager, et le retirer les rendait moins confiants, pas plus. Plutôt que de simplement dire que les données contredisaient l'hypothèse, j'ai apporté des extraits de deux sessions où les participants remontaient explicitement vers le tableau après avoir lu les noms des offres, avec un résumé de ce à quoi ils disaient en avoir besoin. J'ai proposé une voie intermédiaire : garder le tableau mais le déplacer plus bas dans la page, et ajouter au-dessus un résumé condensé sur trois lignes pour les visiteurs qui voulaient la version courte. La direction a accepté de tester les deux versions en production. La version avec résumé condensé et tableau complet a mieux performé sur la conversion que la page simplifiée, et c'est celle que nous avons gardée.

J'avais conçu un centre de notifications avec des mises à jour en temps réel et des animations d'entrée fluides pour chaque nouvel élément, ce qui rendait très bien dans le prototype. L'engineering a signalé que la couche temps réel prévue introduirait un décalage perceptible sous forte charge, et que l'approche d'animation que j'avais choisie serait coûteuse à implémenter de façon cohérente entre nos bases web et natives dans le sprint dont nous disposions. Plutôt que d'insister pour garder la version d'origine, j'ai demandé ce qui était réalisable sans l'approche riche en animations, et à quoi ressemblerait un parcours de mise à jour légèrement retardé mais fiable. Nous avons opté pour une mise à jour par polling toutes les quelques secondes avec un fondu plus simple, moins spectaculaire mais livré à temps et sans bug. J'en ai retenu qu'il fallait impliquer l'engineering plus tôt, dès la phase de concept plutôt qu'à celle de la maquette finalisée, pour que ce type d'arbitrage apparaisse avant que je ne m'attache émotionnellement à une exécution précise. La version simplifiée a d'ailleurs bien fonctionné en test utilisateur, les gens se souciant plus de la fiabilité que du soin apporté aux animations.

Je commence en général une présentation de portfolio par le problème tel que l'équipe le comprenait au départ, y compris la contrainte qui le rendait difficile, pas seulement les écrans finaux aboutis. Pour un projet récent, un parcours d'inscription en plusieurs étapes avec un taux d'abandon de 40 %, j'explique comment nous avons d'abord confirmé où les utilisateurs partaient réellement grâce aux enregistrements de sessions et aux données de funnel, plutôt que de supposer en fonction de la longueur du parcours. Je présente deux ou trois premières directions, dont une que j'ai abandonnée et pourquoi, car montrer une fausse piste démontre un vrai raisonnement plutôt qu'un designer qui aurait tout trouvé du premier coup. Je montre le tour de tests d'utilisabilité qui a changé la direction du design final, puis la version livrée, puis le résultat : le taux d'abandon est passé de 40 % à 27 % le mois suivant. Je termine par ce que je referais différemment, ce qui est en général la partie la plus révélatrice de la présentation, car elle montre si un candidat continue d'apprendre de son propre travail.

Par défaut, j'utilise ce qui existe déjà, et je considère qu'un nouveau composant doit mériter sa place, pas l'inverse. Avant de proposer quelque chose de nouveau, je vérifie si le problème peut être résolu avec un composant existant, une variante, un agencement différent ou un changement de contenu, car la plupart des lacunes apparentes sont en réalité un problème de mise en page plutôt qu'un composant manquant. Si un vrai manque existe, je regarde s'il est susceptible de se répéter à travers le produit ou s'il est vraiment ponctuel : un cas isolé obtient généralement une solution locale plutôt qu'un nouveau composant système, car ajouter des composants peu utilisés à une librairie partagée alourdit la maintenance pour tout le monde. Quand je propose vraiment un nouveau composant, je le soumets à l'équipe design system ou à une session de travail collective plutôt que de le livrer discrètement dans une seule fonctionnalité, car un ajout non revu tend à fragmenter le système en quelques mois, les autres designers le copiant sans comprendre pourquoi il a été créé.

Je définis la métrique cible et la façon dont je vais la mesurer avant que le design ne soit livré, pas après, car construire un plan de mesure après coup tend à produire une métrique qui flatte ce qui s'est passé. Pour une récente refonte de l'onboarding visant le taux d'activation, je me suis mis d'accord avec l'équipe data sur l'événement d'activation exact, la fenêtre de comparaison, et le segment d'utilisateurs à considérer avant le lancement. Quand c'est possible, je livre derrière un test A/B plutôt qu'un déploiement complet, car une simple comparaison avant-après ne peut pas isoler le changement de design de la saisonnalité ou d'une campagne marketing lancée la même semaine sans lien avec le sujet. Je surveille aussi une métrique secondaire qui capterait un effet indésirable, pour un changement d'onboarding cela pourrait être le temps de complétion, au cas où une refonte qui augmente l'activation ralentirait aussi le parcours pour tous ceux qui vont jusqu'au bout. Une fois la fenêtre de test terminée, j'examine le résultat en parallèle des retours qualitatifs issus des tickets support ou des enregistrements de sessions, car une métrique peut bouger pour une raison différente de celle que j'avais supposée.