Table des matières
Le marché SaaS est saturé. La plupart des produits font à peu près la même chose que leurs concurrents, et les utilisateurs s'en aperçoivent en quinze minutes d'essai. La différence, c'est le design, au sens large. Pas juste le visuel. La façon dont le produit structure ses données, dont il s'explique, la friction qu'il enlève des workflows les plus courants.
Un concepteur de produits dans une entreprise SaaS, c'est la personne responsable de cet écart. Pas du site marketing, pas de la marque. De l'interface que quelqu'un utilise pour faire son travail huit heures par jour, parfois pendant des années. Le designer qui voit ça comme une suite d'écrans isolés perdra contre celui qui le voit comme un système qui doit tenir dans le temps.
Concepteur de produits vs UX/UI designer
Ces titres s'utilisent comme synonymes et ils ne devraient pas. Un UX/UI designer se spécialise dans les interfaces : recherche, mise en page, navigation, interaction, design visuel. Un concepteur de produits couvre le même terrain et ajoute la stratégie produit, les objectifs business, et le cycle complet du concept à la livraison. Les deux rôles se chevauchent à l'écran. Ils divergent sur ce qui vient avant l'écran et ce qui vient après.
Dans une petite boîte SaaS, la distinction est académique. Une seule personne fait les deux jobs et quelques autres. Dans une boîte plus grande, le concepteur de produits est plus proche du PM et le UX designer est plus proche de l'utilisateur. Le concepteur de produits est dans la pièce quand la roadmap se débat. Le UX designer est dans la pièce quand un flow précis se teste. Les bons font les deux régulièrement. Les équipes qui marchent le mieux traitent la frontière entre les deux comme une habitude, pas une hiérarchie.
Un troisième titre commence à apparaître : design engineer. Ils sont plus proches du développeur et livrent du code. Certaines boîtes le replient dans le rôle de concepteur de produits, surtout depuis que l'IA a aminci la frontière entre design et code. Si tu vois une offre qui demande de la maîtrise Figma plus de la maîtrise React plus du jugement produit, c'est un concepteur de produits version 2024 qu'elle cherche, même si le titre dit autre chose.
Ce que le rôle implique vraiment
Six choses, dans l'ordre approximatif où elles prennent ton temps.
La première, c'est la recherche utilisateur. Parler aux gens qui utilisent le produit. Cinq entretiens t'apprennent plus que n'importe quel dashboard d'analytics. Le difficile, c'est de poser des questions qui font remonter ce que les gens font, pas ce qu'ils disent qu'ils font. La plupart te raconteront une histoire bien rangée sur leur usage d'une fonctionnalité. En les regardant, tu vois le vrai workflow : les onglets qu'ils gardent ouverts, le tableur dans lequel ils collent, l'étape manuelle qu'ils n'ont pas mentionnée parce qu'elle leur semble trop honteuse à admettre. Cette dernière, c'est souvent là que vit la prochaine fonctionnalité du produit.
La deuxième, c'est les wireframes et les prototypes. Basse fidélité pour réfléchir à la structure. Plus haute fidélité seulement quand la structure est figée et qu'il faut tester les interactions. La plupart des équipes sur-investissent dans de jolis fichiers Figma sur lesquels personne ne clique. Le coût des beaux prototypes, ce n'est pas le temps de les construire. C'est la fausse confiance qu'ils créent. Une maquette polie a l'air décidée. Un croquis brut invite la pousse-back. Tu veux la pousse-back tôt, pas tard.
La troisième, c'est la collaboration interdisciplinaire avec les développeurs, les PMs, le marketing, le support, parfois le légal. Le job, c'est surtout de la traduction : transformer les contraintes d'une équipe en décisions de design que les autres équipes peuvent livrer. Un designer qui refuse d'apprendre le côté ingénierie ou business se fait mettre de côté. Le mode d'échec le plus courant, c'est le designer qui traite le brief comme figé et les contraintes ingénierie comme des obstacles. Le brief, c'est la première intuition de l'équipe. Les contraintes ingénierie, c'est la physique du produit. Respecte les deux et tu trouveras des solutions que les autres ratent.
La quatrième, c'est le design d'interface lui-même. Mises en page, typographie, navigation, états d'erreur, états vides. Les écrans qu'on voit dans les portfolios. C'est la plus petite partie du job en temps passé et la plus grande par ce que le monde en voit. Le piège, c'est d'en faire la seule chose. Un designer brillant en interface mais nul sur les cinq autres trucs finit par rendre des comptes à un designer qui est compétent sur les six.
La cinquième, c'est le design system. Une façon de mettre les décisions d'interface à l'échelle sur beaucoup de surfaces. Construis-en un quand tu as plusieurs produits ou plusieurs designers ; sinon c'est de la dette. Le maintenir, c'est la partie dont personne ne parle et où la plupart échouent. Le pattern : l'équipe construit un système en un trimestre d'effort concentré, livre quelques produits par-dessus, et plus personne n'a le temps de le garder synchro. Au mois neuf, la moitié des composants sont dépréciés, la doc est périmée, et les gens designent à côté du système plutôt qu'avec. Un design system a besoin d'un propriétaire avec du temps alloué, pas d'une intention partagée et noble.
La sixième, c'est l'itération sur le produit livré. Lire les analytics. Lire les tickets de support. Regarder des enregistrements de session. Puis décider quoi changer. La plupart des gains produit viennent de cette étape, pas du design de nouvelles fonctionnalités. Le piège, c'est l'équipe qui livre une feature, déclare ça fini, et ne regarde plus la donnée. La moitié des features SaaS que j'ai construites ont dû être redesignées deux fois après le lancement parce que la première version reposait sur des hypothèses qui n'ont pas survécu au contact des utilisateurs.
Travailler avec le PO et le PM
En SaaS, le product owner fixe les priorités et le product manager les livre. Le designer traduit les deux en quelque chose qu'un utilisateur peut comprendre et utiliser. Dans les petites boîtes, ces rôles sont fusionnés en une seule personne. Dans les grandes, ils sont coupés encore plus. Le job du designer reste le même, peu importe comment l'équipe est nommée.
La recette qui marche pour moi : le PM possède le quoi et le pourquoi. Le designer possède le comment l'utilisateur le vit. Le PO arbitre quand les deux entrent en conflit, ce qui arrive. Traiter ces zones comme des couloirs fixes économise beaucoup de réunions. Les PMs qui marchent le mieux avec les designers sont ceux qui comprennent qu'ils ont une hypothèse sur l'expérience utilisateur, le designer en a une autre, et la réponse n'est pas « compromettons » mais « testons ».
Les standups quotidiens, ce n'est pas de la collaboration. C'est du statut. La vraie collaboration se passe dans des conversations longues et non structurées tôt dans la vie d'une fonctionnalité, avant que quiconque ait ouvert Figma ou Jira. Si ton équipe n'a pas ces conversations-là, tu designes dans le vide. Le standup ne fait que dire à tout le monde ce qui a déjà été décidé.
Quand le PM et le designer ne sont pas d'accord sur un flow, la résolution passe presque toujours par plus de recherche utilisateur. Pas une réunion, pas un fil Slack. Montre deux prototypes à cinq utilisateurs et regarde ce qui se passe. Le nombre de débats que j'ai vus s'évaporer après vingt minutes à regarder de vrais utilisateurs est significatif. Les deux personnes ressortent en voyant quelque chose qu'aucune des deux n'avait prédit.
Ce qui est dur en SaaS spécifiquement
Les utilisateurs SaaS ne choisissent pas le produit. Leur boîte l'a choisi. Ils l'utilisent parce qu'ils n'ont pas le choix, souvent à contrecœur. Ça change le problème de design. Tu n'optimises pas pour l'enchantement. Tu optimises pour moins de friction dans un workflow que quelqu'un préfèrerait ne pas avoir. L'« onboarding enchanteur » qui marche pour une app grand public rate sa cible en SaaS B2B, parce que l'utilisateur est dans une réunion du mardi en train de se faire montrer l'outil par l'IT et veut juste se connecter et trouver le bouton d'export.
Ça veut aussi dire que le churn est invisible jusqu'à ce qu'il explose. Le temps qu'un utilisateur se plaigne, il a déjà mentalement décroché. Designer pour la rétention en SaaS, c'est guetter les petits signaux : la fonctionnalité que les gens arrêtent d'utiliser, le dashboard qu'ils mettent en favori et où ils ne retournent plus, le ticket de support sur un truc qui aurait dû être évident. Les boîtes qui attrapent le churn tôt sont celles dont les designers passent du temps dans l'outil de support chaque semaine, pas seulement dans Figma.
L'autre chose dure, c'est l'échelle des utilisateurs. Le design d'une app grand public doit bien marcher pour un persona. Le design d'un SaaS B2B doit marcher pour l'acheteur qui a payé, l'admin qui l'a configuré, le power user qui vit dedans, et le nouveau qui vient d'hériter du compte de quelqu'un qui est parti. Ces quatre personnes veulent des choses différentes. Designer un écran qui marche pour les quatre, c'est ça le vrai job.
Un exemple précis : l'admin veut un panneau de réglages avec tout configurable. Le nouveau veut que le produit marche avec des valeurs par défaut sensées pour ne pas avoir à réfléchir. Les deux ont raison. Le job du concepteur de produits, c'est de trouver les bons défauts pour que l'admin puisse les changer et que le nouveau n'ait jamais à le faire. Ce n'est pas un problème de design system. C'est un jugement sur ce dont la majorité des utilisateurs a vraiment besoin par rapport à ce que certains disent vouloir.
Ce qui change
Les outils d'IA absorbent la couche de production du design. Générer des maquettes, explorer des options de layout, produire des variantes de copie, ébaucher des états vides. Ça prend des minutes maintenant, pas des heures. La compétence qui compte plus, c'est celle qui vient avant : savoir quels écrans construire, et quelles fonctionnalités couper. La compétence qui compte après, c'est de reconnaître quand l'IA a produit quelque chose de compétent-mais-faux et d'être prêt à le jeter.
Le même déplacement est arrivé aux développeurs quand les générateurs de boilerplate sont sortis. Le travail est monté dans le stack. Pour les designers, le stack inclut maintenant la stratégie produit, le design d'agents, et de plus en plus du code. Si tu ne connais que Figma, ton job rétrécit. Si tu peux esquisser un modèle de données, écrire un brief sur lequel une IA peut utilement travailler, et éditer la copie de production dans le codebase, ton job s'élargit.
La question à moyen terme pour n'importe quel designer SaaS, c'est quel type de designer il veut être dans trois ans. Le job de « production designer » est en cours de commodification, vite. Le job de « strategic designer » est plus dur à enseigner et plus dur à recruter, ce qui explique pourquoi les salaires de senior product designer ont continué à monter en 2024 même quand le marché junior s'est durci. Choisis pour lequel tu t'entraînes, et entraîne-toi délibérément. Le terrain du milieu, c'est le terrain dangereux.
