Que fera Figma ensuite ?

• En résolvant le problème qui a fait du design une collaboration multijoueur, Figma s’est imposé comme l’un des outils produit les plus importants de la dernière décennie, mais se heurte désormais au problème d’une imagination stratégique attachée au canvas, alors que le centre de gravité se déplace du canvas vers le code
• Figma a transformé les fichiers de design en espaces partagés basés sur le navigateur, rendant possibles collaboration, critique, exploration et handoff sur un même écran, et faisant rapidement paraître Sketch dépassé
• Le canvas est une abstraction qui traite le problème de traduction entre l’intention visuelle et le logiciel fonctionnel, mais à mesure que l’IA réduit cet écart, on passe à des systèmes d’exécution qui interprètent directement en code les design systems, API et patterns
• À mesure que l’IA rend l’exécution moins coûteuse, le facteur limitant n’est plus « peut-on créer l’interface ? », mais un problème de coordination : « peut-on créer la bonne interface d’une manière dans laquelle l’organisation peut avoir confiance ? »
• Alors que le centre de gravité se déplace à nouveau, la tentative de Figma d’étendre le canvas pour y faire tenir la prochaine ère relève du dilemme de l’innovateur ; l’enjeu est de savoir s’il saura devenir une interface de collaboration orientée vers la vérité (incumbent trap)

---

Comment Figma a gagné au départ

• Le premier accomplissement de Figma a été technique : rendre le navigateur important pour le design à un degré que personne ne pensait possible
  • L’accessibilité multiplateforme, les performances et le multijoueur ont tous joué un rôle clé
• Le changement le plus profond a toutefois été culturel
  • Avant Figma, la collaboration était fragmentée entre fichiers locaux, redlines, PDF et réunions où l’on demandait « est-ce la bonne version ? »
  • Figma a fait disparaître cette distance, en proposant non pas simplement un meilleur canvas, mais un meilleur modèle de coordination (coordination model)
• Mais une abstraction reste une abstraction : le canvas n’est pas le produit, seulement une représentation (representation), tandis que le produit réel existe dans le code
  • Le canvas était un outil pour réfléchir avant que le coût de l’implémentation ne devienne élevé, mais il dépendait d’un monde où l’écart entre intention visuelle et logiciel fonctionnel était important
  • L’IA est en train de réduire cet écart

Le canvas est une réponse à un problème de traduction

• Le modèle du canvas repose sur une répartition claire des rôles
  • Les designers expriment l’intention, les ingénieurs traduisent cette intention en code, les product managers arbitrent les priorités et le périmètre
  • On utilise ce qui a été imaginé pour construire ce qui sera réellement lancé
• Ce modèle ne disparaîtra pas de sitôt, et de nombreuses organisations continueront probablement à travailler ainsi pendant des années
• Mais la direction change
  • Le design-to-code est devenu plus rapide, mais cela ne fait que compresser plus vite le mode de travail existant : handoff et traduction
  • La vraie différence est que le design structuré, le contexte produit, le code des composants et les règles sont directement interprétés comme des interfaces fonctionnelles codées
  • Lorsqu’un prompt a accès au design system, aux API, aux patterns et aux contraintes d’ingénierie, il n’est plus nécessaire de partir d’une page blanche
• À ce moment-là, le design devient le contexte (context) utilisé par les systèmes d’exécution IA
  • Les équipes ont toujours besoin d’un espace partagé pour la comparaison visuelle, la critique et les décisions business
  • Une fenêtre de terminal ou un IDE n’est pas un lieu où de multiples parties prenantes peuvent participer
  • Pour autant, cela ne place pas le canvas au centre

Retour au canvas

• Les mouvements récents de Figma sont compréhensibles : ils s’appuient sur ses forces actuelles
  • Davantage de travail doit se faire dans Figma, davantage de livrables doivent sortir de Figma, les workflows doivent revenir vers Figma et le développement produit doit avoir lieu dans l’écosystème Figma
• En simplifiant à l’extrême, la stratégie semble être : « tout ramener au canvas, à notre canvas »
  • Mais la prochaine ère ne s’organise pas autour de cet axe
• Le « code-to-canvas » le montre bien : produire un résultat réel, puis le ramener dans Figma sous forme de frames éditables
  • Cela peut résoudre des problèmes de collaboration à court terme, mais c’est étrange en termes de direction, et faux pour l’avenir
  • Figma semble davantage soucieux de ramener les utilisateurs dans la pièce où il sait comment fonctionne la collaboration que de se demander si c’est le bon modèle de collaboration pour l’avenir

Le canvas n’est pas la source de vérité

• Figma pourrait aussi se diriger vers un avenir plus convaincant en tant qu’interface de collaboration reflétant la réalité, c’est-à-dire comme lentille (lens)
  • Il pourrait devenir un lieu où inspecter les systèmes en fonctionnement, comparer des variations, annoter l’objet réel, détecter la dérive du design system, orienter et contrôler
• Mais cela implique d’accepter que le canvas ne soit plus le centre
  • Pour rester important, le canvas ne peut l’être que comme interface vers la vérité
  • Ici, la vérité, c’est le code, le runtime, ce qui existe réellement et ce qui est effectivement lancé
• Le risque pour Figma est de tenter de préserver sa centralité en faisant tout passer par l’ancien modèle : c’est l’incumbent trap (piège de l’acteur établi)
  • Regarder ce qui a créé la domination initiale et ne faire que l’améliorer ; cela reste juste seulement jusqu’au moment où les critères de concurrence changent
  • Figma a battu Sketch parce qu’il a compris que le centre de gravité pouvait changer, mais ce centre change à nouveau et Figma se retrouve désormais de l’autre côté du dilemme de l’innovateur

L’exécution est bon marché, la coordination ne l’est pas

• L’IA rend l’exécution moins chère — pas gratuite, mais elle peut en donner l’impression aux praticiens
  • L’IA génère à un rythme qui modifie les anciens goulets d’étranglement : elle échafaude des écrans, utilise des composants, les relie, refactorise et propose des variantes
• Le facteur limitant n’est donc plus « peut-on créer l’interface ? », mais « peut-on créer la bonne interface, selon les bons critères, pour les bons utilisateurs et avec la confiance de l’organisation ? »
  • La coordination assistée par IA n’est pas la même chose que la collaboration dans l’abstraction du canvas ; elle nécessite un contexte structuré et hiérarchisé
• Des questions de jugement demeurent
  • Quels composants ont été approuvés, quels patterns ont été abandonnés ?
  • Lorsque la documentation, le code et Figma divergent, quelle implémentation fait autorité ?
  • Quelles règles d’accessibilité s’appliquent, quelles contraintes réglementaires comptent, quelles normes d’ingénierie sont non négociables ?
  • Ce n’est pas un problème de canvas, mais un problème d’infrastructure
• Dans ce monde, les design systems deviennent encore plus importants
  • Non pas comme bibliothèques de composants, dépôts d’assets ou documents consultés manuellement par les humains, mais comme intelligence exécutable (executable intelligence) indiquant aux systèmes d’IA comment l’organisation construit
  • Le canvas peut organiser et susciter la critique, mais s’il n’est pas profondément relié à la couche de contrôle de la livraison produit, la réalité se trouve ailleurs et le canvas risque de n’être qu’une jolie image (problème stratégique)

Ce que Figma semble croire

• Vu de l’extérieur, Figma semble croire qu’il peut étendre le canvas pour y faire tenir la prochaine ère
  • Ce n’est peut-être qu’une interprétation externe ; Figma compte de nombreuses personnes intelligentes ayant intérêt à comprendre le changement, et cela peut aussi être une décision commercialement avisée
  • Mais cela ne signifie pas que ce soit le bon modèle produit pour le travail de la prochaine ère
• Une stratégie produit révèle une attitude, et celle de Figma semble centrée sur le retour au canvas
  • Ramener le travail généré, ramener les livrables de code, faire venir les développeurs dans Figma, faire venir l’IA dans le canvas
  • Faire entrer une plus grande part de l’organisation dans un lieu possédé par Figma
• Ce n’est pas nécessairement absurde
  • Les entreprises ont historiquement préféré la consolidation, les gens sont habitués à Figma, et la position dominante crée sa propre gravité
  • Figma peut continuer à ajouter des fonctionnalités utiles, mais la question est de savoir si ces fonctionnalités aident à s’adapter à un monde où les livrables fonctionnels et le contexte organisationnel deviennent plus importants que les fichiers de design
  • Le pari de Figma est : « oui, parce que tout cela finira par revenir dans Figma » ; c’est un pari sur le canvas comme élément central

Si l’espace où nous travaillons change

• Le prochain workspace produit dominant ne ressemblera probablement pas à Figma avec davantage de fonctions IA, ni à un outil de design traditionnel
  • La forme la plus probable est un IDE avec collaboration spatiale, ou un environnement produit basé sur le navigateur permettant d’éditer, d’inspecter et de déployer directement du logiciel vivant
  • Il faudra une couche d’orchestration IA traversant design systems, dépôts, documentation, analytics et outils de product management
  • Une forme intégrée combinant canvas, éditeur de code, environnement de staging, gouvernance et systèmes de règles
• Cette forme paraîtra mauvaise au début
  • Les premières versions de ce qui est juste semblent pires que les versions mûres du passé : maladroites, incomplètes et faciles à ignorer
  • Figma devrait le comprendre mieux que quiconque : il a gagné le dernier round non parce qu’il était un meilleur outil de design, mais parce qu’il était un environnement de travail différent
• Le canvas peut rester indispensable, mais pas le canvas en tant qu’abstraction
  • Le canvas ne doit pas être l’endroit où l’on aplatit la réalité, mais celui où l’on discute de la réalité — un problème difficile et intéressant

Que fait Figma ensuite ?

• Trois chemins existent

• La voie défensive

  • Continuer à étendre le canvas pour que de plus en plus de travail se fasse dans Figma
  • Cela peut produire des fonctionnalités utiles et de solides revenus, et rendre une position dominante plus adhérente et plus profondément installée

• La voie transitionnelle

  • Rendre le canvas plus conscient du code (code-aware) et interactif, avec de meilleures capacités de génération, de workflow, d’import et d’export
  • C’est là que semblent se situer les mouvements actuels de Figma : très utile, mais toujours organisé autour du canvas comme axe de l’environnement produit

• La voie du pivot

  • Accepter que le canvas et Figma ne soient pas le centre de la vérité, et construire l’une des meilleures interfaces de collaboration vers cette vérité
  • Traiter le code, le contexte produit, le design system et le comportement live comme le véritable travail, et faire du canvas une vue (view) parmi d’autres pour raisonner visuellement sur un système déjà vivant
  • Il n’est pas clair que Figma veuille ce pivot
• Le changement stratégique consiste moins à prédire l’avenir qu’à abandonner les hypothèses qui rendent l’activité actuelle possible
  • Le design multijoueur ne disparaîtra pas et restera important
  • La question est de savoir où ce travail existera lorsqu’il deviendra possible de générer, modifier, relire et lancer beaucoup plus près du code
  • Figma a compris le dernier déplacement du centre de gravité ; ce centre est désormais en train de se déplacer à nouveau

[shakespeares]

C’est triste de les voir avec trop d’options et perdre le fil.
C’est dire à quel point il est important de savoir anticiper l’avenir.