Code, savoir-faire et création de dossiers imbriqués

Aujourd'hui, nous sommes ravis de vous présenter les dossiers imbriqués, une fonctionnalité très demandée aidant les équipes qui grandissent à garder leurs fichiers organisés au fur et à mesure qu'elles développent leur contenu et s'attaquent à des projets complexes. Les dossiers imbriqués peuvent sembler ne faire qu'améliorer le confort de vie, mais leur création a nécessité de repenser en profondeur le modèle de contenu et d'autorisations sous-jacent de Figma – tout, du navigateur de fichiers et des contrôles administrateur au partage, aux autorisations et à l'infrastructure centrale.

Lorsque nous avons commencé le projet il y a un an, nous avons suivi un processus de développement de produit traditionnel : l'équipe produit s'est chargée des exigences, l'équipe design a cartographié l'expérience et l'ingénierie a commencé à concevoir une fois la réflexion finalisée. À mi-parcours du projet, le contexte a changé. D'une part, notre équipe poursuivait de nouvelles fonctionnalités natives de l'IA qui ont divisé nos ressources. D'autre part, des outils comme Figma Make, le serveur MCP de Figma, les compétences des agents, le prototypage de base de code et les agents contextuels permettaient de transformer une idée en quelque chose de tangible beaucoup plus rapidement. Nous pouvions commencer à concevoir n'importe où : avec un prototype, du code ou même un contenu esquissé dans Slack.

Pour s'adapter à ces changements et livrer des dossiers imbriqués, nous avons adopté une nouvelle méthode de travail :

• Orientation sur le code : alors que le code devenait moins coûteux à produire, nous avons accéléré le rythme en lançant des demandes d'extraction pour tester nos idées au lieu de nous perdre dans des discussions théoriques.
• Responsabilités redéfinies : nous avons travaillé de manière flexible pour aborder chaque problème : ainsi, les ingénieurs ont pris les décisions liées à la conception, notre designer a transféré le code et notre product manager, au lieu de l'exécution au quotidien, s'est penché sur les aspects stratégiques plus vastes.
• Des conversations à la place des transferts : le flou des rôles a fait de nous des étudiants et des enseignants tour à tour, et partager les aspects de notre métier que nous nous réservions autrefois a permis d'établir la confiance nécessaire dans le travail.

Voici comment ces changements ont été perçus selon trois perspectives : ingénierie, conception et produit. Ensemble, ces services montrent comment notre équipe a trouvé des moyens de renforcer les relations soutenant le travail, a combiné les compétences et est restée concentrée sur la livraison de l'expérience ou de la solution appropriée.

Ethan Adams, ingénieur logiciel, à propos de l'atteinte d'une nouvelle vélocité grâce au code

Au bout de quelques mois dans ce projet, j'ai réalisé que le processus de développement de produit standard prendrait trop de temps. C'était comme être à mi-chemin d'un examen final, lever les yeux et découvrir qu'il ne restait que cinq minutes sur l'horloge – nous devions avancer plus rapidement.

Plutôt que de débattre des exigences du produit (« Qui devrait avoir accès à X ? ») dans des fils Slack sans fin ou des réunions, nous avons proposé de coder. Ces discussions avaient été des prérequis précieux lorsque coder était coûteux et chronophage, mais nous sommes à l'ère des agents. Au lieu de deviner si une idée fonctionnerait, nous avons simplement lancé une demande d'extraction pour le prouver.

Nous avons fusionné le code dans la mesure où cela n'endommageait rien. Cela nous a permis d'esquisser rapidement des idées et de les montrer à nos partenaires transversaux sur un terrain d'essai réel et vivant. Le texte n'est pas parfait ? Pas de souci. Il manque des fonctionnalités ? C'était correct. Des lacunes logiques ? Nous pourrions les corriger plus tard ! En pratique, cela nous a fait gagner un vrai palier en termes de vélocité et nous a permis d'instaurer une confiance dans les propositions que nous avons finalement sélectionnées. Une démonstration fonctionnelle dans votre base de code vaut systématiquement mieux qu'une fiche technique produit.

Même si j'avais le feu vert pour prendre des décisions liées au produit en tant qu'ingénieur, je comptais toujours sur notre product manager Sachi Shah comme partenaire de réflexion pour partager la responsabilité. Notre collaboration ressemblait à une cascade : elle décidait d'une exigence, et je la mettais en œuvre. Cette fois, cela ressemblait plus à une boucle de vérification : j'ai commencé par une proposition, j'ai fusionné des prototypes en préproduction, j'ai sollicité le feedback de Sachi, j'ai lissé les aspérités, et enfin j'ai déployé le produit fini.

Le designer produit Cai Charniga à propos du passage des pixels aux demandes d'extraction

J'ai une confession à faire : j'ai très peu de demandes d'extraction pour ce projet. Deux, peut-être trois. Je ne suis pas devenu ingénieur du jour au lendemain par magie, mais nous avons tous commencé à assumer des rôles qui appartenaient auparavant exclusivement à quelqu'un d'autre.

Sur ce projet, les ingénieurs avaient une solide intuition pour la structure et une compréhension approfondie du fonctionnement des autorisations d'entreprise complexes dans un outil comme Figma, et venaient donc régulièrement me voir avec des flux et des ajustements de design. Quand vous avez un design system solide qui donne aux utilisateurs des garde-fous, et suffisamment confiance pour qu'ils se sentent libres de prendre des décisions, un ingénieur peut approfondir une fonctionnalité de conception et la mener à un état vraiment solide. Cela signifiait que lorsqu'un utilisateur était à pleine capacité, le travail ne s'arrêtait pas en attendant que la bonne personne s'en charge.

Par exemple, nous travaillions sur nos flux de partage de dossiers : comment la fenêtre modale de partage devait communiquer les héritages pour les utilisateurs disposant d'un accès en lecture et en édition, et comment gérer les cas plus compliqués où l'héritage est rompu. L'ingénieur logiciel Jenny Yu est intervenue et a esquissé quelques options. À partir de là, j'ai fait appel à notre rédactrice UX, Molly Rosen Marriner, et nous avons tous les trois conçu sur la base des approches du canvas Figma Design par Jenny, cette dernière s'assurant de la solidité technique du flux, Molly affinant le langage des autorisations et moi-même façonnant la hiérarchie visuelle.

Cela a fonctionné dans l'autre sens aussi. À certains moments, j'ai pris un changement, je me suis mis à coder, et j'ai réalisé à quel point il se passait beaucoup de choses en coulisses – suffisamment pour que je retourne vers l'équipe et dise « Honnêtement, celui-ci ne devrait pas être de mon ressort ». Savoir où vos compétences s'arrêtent est une sorte de savoir-faire en soi. Même ainsi, je pense que chaque designer devrait essayer de transmettre une demande d'extraction. Quand Ethan m'a configuré CoderBox, notre sandbox pour déployer des environnements de code, j'ai ressenti le temps que certaines modifications prenaient à être créées avant de pouvoir même être prévisualisées, et cela m'a apporté plus d'empathie que n'importe quel transfert.

Les ingénieurs pouvaient réaliser les travaux de design, et moi je pouvais coder moi-même. Cela m'a donné la marge pour aller en profondeur là où c’était important, parcourant plus de versions de l'UI des dossiers que l'ancien modèle de transfert n'aurait jamais permis.

Sachi Shah, product manager, à propos du remplacement du contrôle par la conviction

Avec cette nouvelle méthode de travail, la première chose que j'ai dû abandonner, c'est l'idée que la bonne réflexion sur un produit devait venir exclusivement du PM. Mon travail a alors été de faire correspondre les bonnes personnes aux bons problèmes, de donner à ces personnes le champ libre, et de savoir quand intervenir de nouveau.

Jenny Yu est devenue l'une de mes partenaires de réflexion les plus proches sur des opérations de contenu critiques telles que le déplacement, la duplication et le transfert de dossiers à travers Figma. Ricky Zein, également ingénieur logiciel, s'est occupé de l'expérience des utilisateurs individuels et des petites équipes, dont les besoins sont souvent différents de ceux des clients entreprise. Les data scientists Patrick Kehinde Jr. et Eric Aberbook ont cartographié la manière dont le nouveau modèle d'autorisations affecterait chaque groupe, m'aidant à tester nos hypothèses à l'extrême et à me concentrer sur les risques majeurs.

Renoncer à l'exécution au quotidien m'a donné plus de temps pour me concentrer sur la question stratégique sous-jacente au projet : une meilleure organisation des fichiers importait-elle encore dans un monde orienté sur l'IA, ou les dossiers devenaient-ils archaïques à mesure que la recherche par IA s'améliorait ? Nous avons conçu des artefacts qui nous ont aidés à voir comment les dossiers pourraient avoir encore plus d'importance alors que les utilisateurs créaient plus de travail, offrant à la future recherche IA une structure et un contexte plus riches à exploiter. Mais c'est prendre du recul pour concevoir un portefeuille de paris équilibré qui a le plus aidé. Aux côtés des dossiers imbriqués, notre équipe a sprinté pour lancer des compétences dans l'agent Figma, un autre aspect de la stratégie native de l'IA de Figma. Paradoxalement, passer moins de temps à gérer chaque détail m'a donné plus de marge pour concevoir une roadmap où les besoins fondamentaux des clients et les nouvelles expériences natives de l'IA pouvaient progresser ensemble.

Au sein même du projet, l'endroit le plus important où réorienter mon attention, c'était vers les clients. J'ai pris en charge le programme d'accès anticipé (EAP), et nous sommes devenus très débrouillards. À Config, j'ai infiltré les happy hours avec le directeur technique de notre équipe, Ayush Mehra, pour aborder directement les clients à propos du système d'organisation de fichiers que nous concevions. Nous avons convaincu plusieurs personnes de rejoindre l'EAP sur place. De là, nous avons continué notre essor. Les communautés Friends of Figma à Jaipur, Barcelone, Mumbai et Lahore ont été pionnières. J'ai également contacté les leaders de la communauté dans le monde entier et les personnes sur X qui s'étaient beaucoup exprimées sur l'organisation des fichiers – y compris Ilya Miskov​, un designer qui avait participé à l'une de nos premières discussions de découverte.

Le feedback des clients nous a montré comment les dossiers imbriqués se comportaient au sein des organisations en conditions réelles, avec des fichiers désordonnés et des habitudes bien ancrées. Cela nous a aidés à identifier les bugs, à optimiser l'expérience et à réduire les risques liés à la migration de clients vers un modèle de contenu entièrement nouveau.

Le temps passé avec les clients m'a donné une certaine clarté sur le produit que je n'aurais jamais obtenue en rédigeant des spécifications seul. Remplacer le contrôle par la conviction m'a obligé à m'engager dans le travail que j'étais le mieux placé pour effectuer, tout en faisant confiance aux autres pour en faire de même.

Cette méthode de travail ne fonctionne que s'il existe une confiance mutuelle parmi les membres de l'équipe. Pour être honnête, brouiller les rôles a été compliqué : il y a eu des moments où nous nous sommes marchés sur les pieds, où nous avons dépassé les limites un peu maladroitement, ou encore où nous avons tenté des choses que nous n'avions jamais faites. Cette difficulté a fait partie de la recherche d'une nouvelle normalité, et nous avons pu la surmonter uniquement parce que nous avions investi dans les relations sous-jacentes au travail. Avec le temps, nous nous sommes moins accrochés à nos périmètres respectifs et nous avons commencé à nous transmettre activement les uns les autres les aspects de notre métier que nous gardions jusque-là pour nous-mêmes.

Nous avons préservé la confiance et le contexte grâce à des rituels partagés : des sessions de correction de bugs hebdomadaires, des synchronisations transversales, des séances de travail en direct entre la conception et l'ingénierie et des célébrations des jalons majeurs, y compris le lancement interne dans tout Figma. Ces rythmes nous ont tenus ancrés sur le même objectif, en répondant à une promesse client très attendue sans compromettre la qualité.

Les dossiers imbriqués mettront quelques semaines à être déployés vers tous les utilisateurs. Visitez notre centre d'aide pour en savoir plus sur la façon de démarrer.