Acquérir des connaissances techniques n’est pas chose aisée pour un designer qui n’a pas la possibilité d’être au contact de développeurs au quotidien.
Chez BlaBlaCar et même tout au long de mon parcours, c'est cette proximité qui a le plus accéléré ma compréhension des contraintes produit et tech. Pas grâce à des réunions de synchronisation hebdomadaire mais par une vraie proximité, physique et quotidienne. Celle qui fait comprendre les contraintes avant qu’on y soit confronté, des fois dans la douleur. Celle aussi qui aide à ce que les questions viennent naturellement, dans les deux sens. C’est dans ces conditions que le design devient quelque chose qu'on construit ensemble plutôt qu'une spec (les instructions qui détaillent le comportement attendu) qu'on envoie de l'autre côté d'un couloir.
Par exemple, savoir “ce qui est disponible dans l'API et sous quel format”, de façon à créer des designs qui ne sont pas en complète rupture avec la réalité technique fait gagner un temps précieux à toute une équipe.
Voilà donc quelques notions de base. Pas pour faire de toi un développeur en herbe mais pour mieux comprendre l'environnement dans lequel ton travail prend vie.
Front-end, back-end : qui fait quoi
Quand tu utilises une application, tu interagis avec ce qu'on appelle le front-end : l'interface visible, les boutons, les formulaires, les animations, les textes. C'est la partie que tu conçois dans Figma en général. Elle est rendue par un navigateur ou une application mobile, et elle est généralement gérée par des développeurs front-end.
Le back-end, c'est tout ce qui se passe derrière. Les bases de données, les calculs, la logique métier, l'authentification, la gestion des comptes. Quand tu te connectes à une appli et que ton nom s'affiche dans le coin, c'est le back-end qui a retrouvé ton profil, et le front-end qui l'affiche.
Pourquoi c'est intéressant ? Parce que selon où se situe une fonctionnalité, la complexité d'implémentation n'est pas du tout la même. Afficher un bouton de partage, c'est du front. Mais si ce bouton envoie un email personnalisé à dix contacts, récupère leurs profils, et enregistre l'action dans un historique, ça touche au back et ça se conçoit différemment (avec des schémas, des specs, etc…).
Comment une information voyage
Tu remplis un formulaire et tu cliques sur "Envoyer". Qu'est-ce qu'il se passe ?
Ton navigateur (ou l'app) envoie une requête à un serveur. Cette requête contient les données que tu viens de saisir, avec quelques informations sur qui tu es et ce que tu demandes. Le serveur reçoit la requête, fait ce qu'il a à faire (vérifier tes données, les enregistrer, appeler d'autres services...), puis renvoie une réponse : un message de confirmation, un contenu à afficher, ou… une erreur.
Tout ça prend entre quelques millisecondes et quelques secondes. Et tout ce temps d'attente, c'est le Product Designer qui le conçoit : les états de chargement, les messages d'erreur, les feedbacks visuels. Si tu ne sais pas qu'il y a un aller-retour, tu oublies de concevoir les états intermédiaires. Et l'utilisateur se retrouve devant un écran qui ne lui dit rien.
Comment sont construites les pages web
Une page web, c'est une combinaison de trois choses :
- La structure (HTML) : le squelette. Les titres, les paragraphes, les images, les boutons. Ce qui existe sur la page.
- Le style (CSS) : l'apparence. Les couleurs, la typographie, les marges, la mise en page. Ce qui ressemble à quelque chose.
- Le comportement (JavaScript) : l'interactivité. Les animations, les menus déroulants, les formulaires dynamiques, tout ce qui réagit aux actions de l'utilisateur.
Ce que livre le Product Designer dans Figma va être traduit dans ces trois langages. Et certaines choses qu’il conçoit sont plus ou moins complexes à implémenter. Une mise en page qui paraît simple visuellement peut être un casse-tête en CSS selon le contexte technique. Avoir conscience de ça ne veut pas dire renoncer à ses ambitions de design. Ça veut dire les défendre avec les bons arguments, et savoir quand explorer une alternative. C’est pour cela qu’il est recommandé d’intégrer les développeurs assez tôt dans le process de design : pour s’assurer d’être sur la bonne voie le plus rapidement possible.
C'est quoi une API
Une API (Application Programming Interface), c'est une interface entre deux systèmes. Un contrat qui dit : "si tu me demandes telle chose dans tel format, je te réponds avec telle chose dans tel autre format."
Il en existe deux grandes familles. Les API externes, d'abord : quand une appli de transport affiche le temps de trajet entre deux adresses, elle appelle l'API de Google Maps plutôt que de recalculer elle-même les itinéraires. Elle délègue à un service spécialisé. Et puis il y a les API internes, propres à chaque entreprise, qui exposent les données et la logique métier maison. C'est via cette API que ton appli récupère le profil d'un utilisateur, l'historique de ses commandes, ou le statut d’un code promo.
Pour toi, designer, ça veut dire une chose concrète : les données que tu peux afficher dans ton interface ne sont pas magiques. Elles existent quelque part, dans un format précis, avec des contraintes. Un champ texte limité à 80 caractères, ce n'est pas un caprice : c'est peut-être la taille définie dans la base de données, parce que les systèmes en aval ne sont pas prévus pour gérer plus. Une image qui ne peut être affichée qu'en carré, c'est peut-être parce que c'est le seul format proposé par l'API. Comprendre ce que l'API fournit, et sous quelle forme, c'est ce qui permet de créer des designs qui tiennent à l’implémentation. Et d'avoir les bonnes discussions avec les développeurs quand il faut décider si l'API doit évoluer ou pas.
Ce n’est que rarement “un p’tit changement”
Avant même de parler de ce qui se passe techniquement, il y a une attitude à adopter : celle de montrer de l'empathie vis à vis des développeurs avec qui on travaille.
Quand on arrive avec une demande en présumant que "c'est simple, c'est pas grand chose", on part souvent du mauvais pied. Non pas parce que les développeurs cherchent à compliquer les choses, mais parce que ce qui paraît anodin côté design déclenche presque toujours une cascade de questions côté implémentation. Et si on ne le sait pas, on a tendance à sous-estimer et parfois à mettre la pression là où elle n'a pas lieu d'être.
Prenons un exemple concret : tu décides d'ajouter une fonctionnalité qui permet à un utilisateur de laisser un avis sur une commande. "C'est juste un champ texte et une étoile hein ?". Et bien pas vraiment…
Première question : ce champ texte, il a une limite de caractères ? Si oui, laquelle ? Qu'est-ce qu'on affiche quand l'utilisateur dépasse cette limite ? Un message d'erreur ? Il apparaît où, sous quel format, avec quel wording ?
Ensuite : la validation se fait côté front-end, côté back-end, ou les deux ? Si on fait les deux, est-ce que les comportements sont cohérents ? Est-ce que l'interface réagit en temps réel pendant que l'utilisateur tape, ou seulement après avoir soumis le formulaire ?
On continue. Les avis sont-ils modérables ? Visibles par tous immédiatement, ou après validation ? Est-ce qu'ils sont liés au compte utilisateur ? Qu'est-ce qu'on fait si le compte est supprimé ? Est-ce que l'API interne expose déjà ce type de données, ou faut-il la faire évoluer ?
Un designer qui ne comprend pas cet environnement verra un champ texte et une étoile. Un designer qui le comprend verra toutes ces questions avant même d'ouvrir Figma, et arrivera en discussion avec une vision claire de ce qui est essentiel, de ce qui peut attendre, et des compromis acceptables. C'est ça qui change la dynamique d'une équipe.
Ton rôle dans la delivery
En product design, on travaille jamais en solo jusqu'à la mise en production. On travaille en équipe, souvent selon une méthode qu'on appelle Scrum, organisée en sprints : des cycles courts de développement, souvent deux semaines, avec un objectif défini.
Le backlog, c'est la liste priorisée de tout ce qu'il y a à construire. Les fonctionnalités, les correctifs, les améliorations. C'est là que vivent les "tickets" sur lesquels les développeurs vont travailler.
La QA (Quality Assurance), c'est la phase de vérification avant qu'une fonctionnalité parte en production. Et c'est souvent là que le designer a le plus à perdre s'il est absent : parce que c'est à ce moment qu'on découvre que le design n'a pas été implémenté comme prévu, que certains états n'ont pas été traités, qu'un composant se comporte bizarrement sur mobile.
Être impliqué dans la delivery, ce n’est pas juste livrer des maquettes et attendre. C'est faire la revue des développements, pointer les écarts, distinguer ce qui est bloquant de ce qui peut attendre, et travailler avec les développeurs pour prendre les meilleures décisions compte tenu de leurs contraintes et des objectifs de l'équipe. Le but n'est pas d'avoir raison et de faire implémenter le design tel qu'on l'a conçu, c'est de produire rapidement de la valeur, ensemble.
La culture technique, c'est ce qui te permet de sortir du rôle de gardien des maquettes pour entrer dans celui de quelqu'un qui cherche des solutions. Pas "c'est pas ce que j'ai dessiné", mais "voilà ce que j'essaie d'accomplir pour l'utilisateur, comment est-ce qu'on peut y arriver ?
En résumé
Aucune de ces notions n'est insurmontable, même pour quelqu’un qui n’a aucune notion technique préalable. Elles demandent juste du temps, de la curiosité, et surtout de l'exposition.
Poser des questions aux développeurs de ton équipe et comprendre pourquoi telle contrainte existe plutôt que de la subir. Participer aux rituels de delivery même quand ta partie semble "terminée".
Les meilleurs designers ne sont pas forcément ceux qui savent coder, ce sont ceux qui comprennent suffisamment leur environnement pour concevoir des solutions réalistes, défendre leurs choix avec les bons arguments, et collaborer sans friction avec les équipes qui vont construire ce qu'ils ont imaginé.
