Arthur est Staff Designer chez Lovable. Designer self-taught passé par une école de commerce, dix ans à Londres, Head of Design chez Anchor Store, puis freelance avant de rejoindre Lovable en décembre. Dans ce live, il ouvre son Figma, son GitHub et son terminal pour montrer concrètement comment un designer ship du code dans une startup qui tourne à 400 commits par jour. Lovable génère vingt millions d'utilisateurs actifs par jour sur l'ensemble de ses applications. À ce rythme, faire du design "traditionnel" n'est pas une option. Arthur gère en solo toute l'expérience Connectors la partie qui permet de connecter Lovable à Gmail, WhatsApp et d'autres outils ainsi que les applications iOS, Android et Desktop. Ce live est un retour terrain brut sur ce que ce mode de travail change concrètement pour un designer.
1. Une valeur, pas un slogan
Une valeur interne qui définit le rôle
Chez Lovable, une des valeurs internes s'appelle "driver not passenger". Elle résume l'attente : les designers ne sont pas des exécutants. Ils définissent des features, mesurent ce qui se passe et sont à l'aise à le faire. "Tu es au volant. C'est toi un peu l'entrepreneur."
Les designers pushent du code
En pratique : les designers pushent du code. Pour certains, c'est du changement de texte. Pour Arthur, ça va jusqu'à des PR complets sur la partie front, incluant les animations. "Quand je dis équipe design system ici, c'est quasiment uniquement côté code. On ne maintient quasiment rien dans Figma, parce que dès qu'on crée quelque chose dans Figma, ça va être rapidement dépassé par la code base."
La code base comme source de vérité
La conséquence : la code base est la source de vérité, pas le fichier de design. Ce qui rend possible une approche comme Penpot Snapshot récupérer directement un composant de la production pour l'itérer.
Équipes autonomes
Côté organisation : les équipes sont relativement autonomes, souvent composées d'un dev et d'un designer qui travaillent ensemble, sans PM à plein temps. "On n'avait pas beaucoup de PM pendant très longtemps. Il y a pas mal d'équipes qui sont autonomes."
Charge cognitive
Sur la charge cognitive : "Il y a une charge cognitive beaucoup plus élevée qu'avant. Ce n'est pas facile à gérer. Mais le principal, c'est d'être confortable avec le changement de sujet."
2. Prototyper dans Lovable, polir dans Cursor, reviewer en draft PR
Étape 1 : prototypage dans Lovable
Pour explorer une idée de feature, Arthur commence dans Lovable. Il prototypait notamment une bannière promotionnelle pour les Connectors. "J'utilise l'application Desktop Lovable avec le MCP local. Ça me permet de rajouter du contexte il va lire les fichiers. Je commence avec quelque chose de basique, je polis les trucs." Le niveau de fidélité visé à cette étape est délibérément bas : "Je suis dans un niveau de fidélité où je me dis c'est pas grave. Ce que j'essaie de faire, c'est trouver un concept aligné à la marque qui fonctionne."
Étape 2 : itération dans Paper avec Penpot Snapshot
Penpot Snapshot est une extension Chrome qui permet de capturer un composant directement depuis le DOM du site en production et de le coller dans Paper. "Ça me permet de travailler sur un composant qui est aligné à la production sans aller chercher dans Figma. Tout est vectorisé, tout est aligné à la production." Utilisation typique : quand un dev fait un PR et demande une review, Arthur snapshot l'état actuel, itère dans Paper et lui renvoie le lien ou pousse lui-même un commit.
Étape 3 : nettoyage dans Cursor
Avant de créer un vrai PR, Arthur passe dans Cursor pour s'assurer que le code est propre. "Je veux passer le moins de temps possible à avoir des retours de CI ou de bots. J'essaie de faire un maximum de travail dans Cursor avant de commettre." Une étape fréquente : demander à Cursor comment une partie du back-end fonctionne, pour ne pas designer dans l'ignorance. "Je commence un nouveau chat et je dis : je vais bosser sur cette feature. Dis-moi comment ça fonctionne aujourd'hui dans le back-end, avec les différents plans du produit, pour admin ou utilisateur classique." La réponse est collée dans Paper pour une lecture plus visuelle.
Étape 4 : draft PR pour communiquer l'idée
Pour les changements complexes, Arthur ne pousse pas directement. "Je fais un gros draft PR. Je ne suis pas à l'aise à mettre 600 ou 700 lignes de code dans ma code base sans aide. Le draft PR me permet de communiquer l'idée à un ingénieur, qui va la reprendre et implémenter les parties plus complexes." Pour les petits changements styling, animations , il pousse lui-même après review.
"Mon idée, c'est de sortir un truc le plus clean possible pour le dev. Qu'il n'ait pas besoin de refaire un paquet de travail là-dessus."
3. Une animation documentée au frame près
L'animation de la bannière Connectors
Arthur cite l'animation de la bannière Connectors comme exemple de la valeur ajoutée d'un designer qui va au bout du craft.
Une séquence documentée dans le PR
L'objectif : montrer rapidement une succession de logos de connecteurs en une seconde environ, avec une mécanique d'accélération. La séquence documentée dans le PR : "On a 250ms où c'est relativement statique, presque linéaire, pas vraiment de courbe de Bézier. Et ensuite, on vient accélérer et on passe en mode turbo. On accélère toute la séquence. Ça permettait de montrer quinze à vingt logos en une seconde."
Review, merge et feature flag
Le PR a été reviewed par des développeurs, mergé, sorti en feature flag d'abord en interne, puis pour les utilisateurs avec un slider progressif. La mesure de l'impact a suivi.
Goût et craft comme différenciation
"On est en train de se dire, tiens, l'IA peut sortir une interface qui est correcte, qui fonctionne, qui est relativement réfléchie. C'est là-dessus qu'il faudra faire la différence. En termes de goût et de craft."
4. Ne pas partir dans la complexité technique, partir du mental model
Une journée test de huit heures
La journée test de recrutement chez Lovable durait huit heures. Sujet : concevoir l'expérience de branching permettre aux utilisateurs de créer une version staging de leur application sans toucher la production. Un problème complexe : les utilisateurs ne comprennent pas ce qu'on fait avec la base de données quand on branch.
Commencer par du texte, pas des wireframes
La méthode d'Arthur : commencer par du texte, pas des wireframes. Comprendre comment d'autres produits approchent des problèmes similaires (Figma multiplayer, FigJam, un outil de gestion de projets 3D). Regarder l'inspiration visuelle "J'avais pas envie de faire du diff comme sur GitHub. Les gens n'ont pas envie de regarder une tree." Explorer des analogies lointaines : listes de courses, Mario Kart, calendriers.
S'inspirer du modèle thread de Slack
Le concept retenu : s'inspirer du modèle thread de Slack. Une "nouvelle session" plutôt qu'une "branche". "C'est beaucoup plus friendly. Tu n'utilises pas le mot branching ou quelque chose comme ça. Tu fais une nouvelle session. Et il y a un peu de texte pour expliquer."
Le checkpoint à midi
Un checkpoint à midi avec le Head of Design et un autre designer a permis de valider la direction. "Ce checkpoint est hyper utile. Ça te permet de comprendre comment tu vas bosser avec quelqu'un et d'avoir un peu plus de direction." La présentation finale a eu lieu à 18h.
Le piège classique
"Le piège classique dans cette tâche, c'est de partir assez rapidement dans la complexité et de se dire OK, branching, ce n'est pas compliqué, je vais faire une liste. En fait, non."
"Ce qui est important, c'est de faire de la conception intentionnelle. Tout le monde avec un compte Claude ou Codex peut sortir une interface qui est correcte. C'est là-dessus qu'il faudra faire la différence."
5. Premium Real Estate, Pax Bot, et le piège de la feature factory
Premium Real Estate : des espaces protégés
À 400 commits par jour, maintenir la cohérence produit est un enjeu structurel. Certains espaces de l'interface la home, le chat sont protégés. "On ne va pas mettre n'importe quoi. C'est une équipe unique qui contrôle ce qui se passe là-dedans." Ces espaces ont une équipe dédiée, et personne d'autre ne peut les modifier librement.
Pax Bot : un bot Slack connecté à la code base
"Je mets un screenshot et Pax sait exactement qui a shippé ça, me donne le lien du PR. On ne fait rien." Si quelque chose ne correspond pas aux standards de qualité interne ce qu'ils appellent "loveable" le problème est identifié et souvent corrigé en urgence.
Le problème de la surcharge
Arthur reconnaît la réalité d'une croissance rapide : "La partie settings du produit, c'est vraiment plus possible. On a vingt-cinq liens uniques. C'est là qu'on vient grouper." Le principe de base qu'il utilise : compter les boutons sur un écran. "Ça donne une bonne indication de la charge cognitive."
Culture de release
Les release notes sont quasi-entièrement automatisées via des bots Slack. Tout le monde sait ce qui a été shippé. Effectif design en décembre à son arrivée : cinq ou six personnes. Au moment du live : quatorze, en combinant designers et design engineers.
6. Chaque personne choisit ses outils, y compris le tableau blanc
Aucun outil n'est imposé
Chez Lovable, personne n'est forcé d'utiliser un outil spécifique. Cursor, Claude Code, Codex, Paper, Figma chaque personne choisit selon le problème. "Il y a des gens qui utilisent le papier physique pour faire des trucs. Moi, j'aime bien un whiteboard et y aller à l'ancienne."
Quand utiliser Figma plutôt que Paper
Pour l'app iOS (accès à l'UI kit natif Apple), pour les gradients et détails visuels, pour tout ce qui demande un contrôle précis des vecteurs. "Paper, c'est vraiment plutôt pour de l'itération rapide, quand il faut restructurer des choses. Figma est beaucoup meilleur pour penser un design system."
Lovable en interne, illimité
"C'est très compliqué le jour où je vais quitter cette boîte et je vais devoir payer mes propres crédits. Je ne pense pas que j'aurais le même comportement."
Rythme de travail
"Lovable, c'est une histoire de passion. Il faut bosser les horaires qu'il faut." Arthur est remote, basé hors de Stockholm, et se déplace une fois par mois. La boîte est en présentiel à Stockholm. "Ce que je fais souvent, c'est varier le travail. Hier, j'étais sur un bug pendant deux heures dans Cursor. Au bout de deux heures, je suis cuit. Dans ces cas-là, je switche sur du travail visuel là, je bosse sur un logo pour l'équipe."
"J'ai la chance d'être dans un taf où je ne me sens pas vraiment travailler. Mais c'est important de quand même trouver cet équilibre."