Verschachtelte Ordner coden, erstellen und gestalten

Heute stellen wir euch die verschachtelten Ordner vor – eine Funktion, die schon lange gewünscht wurde und wachsenden Teams dabei hilft, ihre Dateien übersichtlich zu organisieren, während sie ihren Inhalt erweitern und komplexe Projekte in Angriff nehmen. „Verschachtelte Ordner“ – das klingt vielleicht nach einer einfachen Verbesserung der Benutzerfreundlichkeit, aber um sie zu entwickeln, musste das zugrunde liegende Inhalts- und Berechtigungsmodell von Figma von Grund auf neu überdacht werden – vom Dateibrowser über die Verwaltungsfunktionen bis hin zur Freigabe, den Berechtigungen und der Kerninfrastruktur.

Als wir das Projekt vor einem Jahr gestartet haben, sind wir einem traditionellen Produktentwicklungsprozess gefolgt: Das Produktteam hat die Anforderungen durchgearbeitet, das Designteam hat die Benutzererfahrung entworfen, und die Entwickler*innen haben mit der Umsetzung begonnen, sobald die konzeptionellen Fragen geklärt waren. Mitten im Projekt änderte sich der Kontext. Auf der einen Seite verfolgte unser Team neue KI-native Funktionen, die unsere Ressourcen aufteilten. Auf der anderen Seite machten es Tools wie Figma Make, der Figma MCP-Server, Agent_skills, Codebase-Prototyp erstellen und kontextbewusste Agenten viel schneller, eine Idee in etwas Greifbares umzusetzen. Wir konnten überall anfangen zu bauen: mit einem Prototyp, beim Coden oder sogar etwas, das in Slack gekritzelt wurde.

Um diesen Veränderungen gerecht zu werden und verschachtelte Ordner herauszubringen, haben wir uns auf eine neue Arbeitsweise umgestellt:

• Mit Code vorangehen: Als die Entwicklung von Code kostengünstiger wurde, kamen wir schneller voran, indem wir Pull-Requests (PRs) erstellt haben, um unsere Ideen zu testen, anstatt uns in theoretischen Diskussionen zu verlieren.
• Veränderte Zuständigkeiten: Wir sind flexibel an jedes Problem herangegangen, sodass die Entwickler*innen Designentscheidungen trafen, unsere Designer*innen Code hochgeladen haben und unsere Produktmanager*innen die tägliche Umsetzung gegen die Bearbeitung größerer strategischer Fragen eingetauscht haben.
• Handoffs durch Unterhaltungen ersetzt: Durch das Verwischen der Rollen wurden wir abwechselnd zu Studierenden und Lehrenden, und indem wir die Aspekte unseres Handwerks teilten, die wir früher geheim gehalten hatten, schufen wir das Vertrauen, das für die Arbeit nötig war.

So sahen diese Änderungen aus drei Perspektiven – aus den Bereichen Technik, Design und Produkt – aus. Zusammen zeigen sie, wie unser Team Wege gefunden hat, die Beziehungen zu stärken, die unsere Arbeit unterstützen, unsere Kompetenzen gebündelt hat und sich darauf konzentriert hat, das richtige Erlebnis oder die richtige Lösung auf den Markt zu bringen.

Software-Ingenieur Ethan Adams über das Erreichen neuer Geschwindigkeit mit Coden

Nach ein paar Monaten in diesem Projekt wurde mir klar, dass der übliche Produktentwicklungsprozess zu lange dauern würde. Es war, als wäre man mitten in einer Abschlussprüfung, würde aufschauen und feststellen, dass nur noch fünf Minuten übrig waren – wir mussten uns beeilen.

Anstatt Produktanforderungen („Wer soll Zugriff auf X haben?“) in endlosen Slack-Threads oder Meetings zu diskutieren, haben wir den Code als Vorschlag vorgelegt. Diese Diskussionen waren einst wertvolle Voraussetzungen, als das Schreiben von Code noch aufwendig und zeitraubend war, aber wir befinden uns mittlerweile im Zeitalter der Agenten. Anstatt zu raten, ob eine Idee funktionieren würde, haben wir einfach ein PR erstellt, um es zu beweisen.

Wir haben Code zusammengeführt, solange dadurch nichts kaputtging. Dadurch konnten wir Ideen schnell skizzieren und sie unseren Partner*innen aus verschiedenen Abteilungen in einer realen, lebendigen Testumgebung präsentieren. Nicht perfekt? Kein Problem. Fehlende Funktionalität? Das war in Ordnung. Logische Lücken? Könnten wir später beheben! In der Praxis war dies ein großer Impuls für unsere Geschwindigkeit und schuf Vertrauen in die Vorschläge, die wir letztlich auswählten. Ein funktionierendes Demo direkt in eurem Code schlägt jedes Mal ein Product Requirements Document (PRD).

Auch wenn ich als Ingenieur freie Hand bei Produktentscheidungen hatte, habe ich mich dennoch auf unsere Produktmanagerin Sachi Shah als Ideengeberin verlassen, um die Verantwortung gemeinsam zu tragen. Unsere Zusammenarbeit sah früher aus wie ein Wasserfall: Sie entschied über eine Anforderung, und ich setzte sie um. Diesmal sah es eher nach einem Verifizierungszyklus aus: Ich habe einen Vorschlag gemacht, Prototypen in die Staging-Umgebung übernommen, Sachi um Feedback gebeten, die Ecken und Kanten geglättet und schließlich das fertige Produkt bereitgestellt.

Produktdesignerin Cai Charniga über den Weg von Pixeln zu Pull Requests

Ich muss was gestehen: Meine PR-Zahl ist bei diesem Projekt ziemlich niedrig. Zwei, vielleicht drei. Ich bin nicht einfach so wie durch Zauberhand zur Ingenieurin geworden, aber wir alle haben angefangen, Aufgaben zu übernehmen, die früher ausschließlich anderen vorbehalten waren.

Bei diesem Projekt hatten die Ingenieure ein ausgeprägtes Gespür für Strukturen und ein tiefes Verständnis dafür, wie komplexe Unternehmensberechtigungen in einem Tool wie Figma funktionieren, sodass sie regelmäßig mit Arbeitsabläufen und Designanpassungen zu mir kamen. Wenn du ein starkes Designsystem hast, das den Leuten Leitplanken bietet, und genug Vertrauen, dass sie sich frei fühlen, Entscheidungen zu treffen, können sich Entwickler*innen intensiv mit einem Designmerkmal auseinandersetzen und es wirklich ausgereift gestalten. Das bedeutete, dass, wenn jemand ausgelastet war, die Arbeit nicht ins Stocken geriet, während auf die richtige Person gewartet wurde, um sie aufzunehmen.

Wir haben uns zum Beispiel mit unseren Abläufen zur Ordnerfreigabe beschäftigt: Wie das Freigabe-Modalfenster die Vererbung für Benutzer*innen mit Lese- oder Bearbeitungszugriff darstellen sollte und wie man mit den kniffligeren Fällen umgeht, in denen die Vererbung nicht funktioniert. Die Softwareentwicklerin Jenny Yu sprang ein und erstellte ein paar Entwürfe. Danach habe ich unsere UX-Autorin, Molly Rosen Marriner, hinzugezogen, und zu dritt haben wir auf Jennys Ansätzen auf der Figma-Design-Leinwand aufgebaut: Jenny sorgte dafür, dass der Ablauf technisch einwandfrei war, Molly verfeinerte die Formulierungen zu den Berechtigungen und ich gestaltete die visuelle Hierarchie.

Das galt auch umgekehrt. Es gab Zeiten, in denen ich eine Änderung übernommen habe, mich in den Code eingearbeitet habe und mir klar wurde, wie viel da hinter den Kulissen ablief – so viel, dass ich zum Team zurückging und sagte: „Ehrlich gesagt, das hier sollte nicht meine Aufgabe sein.“ Zu wissen, wo die eigene Expertise an ihre Grenzen stößt, ist eine Kunst für sich. Trotzdem finde ich, dass alle Designer*innen versuchen sollten, ein PR zu veröffentlichen. Als Ethan mir CoderBox eingerichtet hat – unsere Sandbox zum Einrichten von Code-Umgebungen –, habe ich hautnah gespürt, wie lange es dauerte, bis bestimmte Änderungen kompiliert waren, bevor ich sie überhaupt in der Vorschau ansehen konnte, und das hat mein Einfühlungsvermögen mehr gefördert als jede Aufgabenübergabe zuvor.

Ingenieur*innen könnten Designarbeit übernehmen, und ich könnte selbst coden. Das gab mir Raum, in die Tiefe zu gehen, wo es zählte, und durch mehr Versionen der Ordner-UI zu laufen, als das alte Übergabemodell je erlaubt hätte.

Produktmanagerin Sachi Shah über den Tausch von Kontrolle gegen Überzeugung

Bei dieser neuen Arbeitsweise musste ich als Erstes die Annahme loslassen, dass gutes Produktdenken ausschließlich von Produktmanager*innen kommen müsse. Meine Aufgabe bestand darin, die richtigen Leute für die richtigen Probleme zu finden, ihnen Freiraum zu geben und zu wissen, wann ich wieder eingreifen musste.

Jenny Yu wurde zu einer meiner engsten Ideengeberinnen bei wichtigen Themen rund um die Arbeit mit Inhalten, zum Beispiel wie man Ordner in Figma verschiebt, dupliziert und überträgt. Ricky Zein, ebenfalls Softwareentwickler, war für die Benutzererfahrung von Einzelanwendern und kleineren Teams zuständig, deren Anforderungen sich oft von denen von Unternehmenskunden unterscheiden. Und die Datenwissenschaftler Patrick Kehinde Jr. und Eric Aberbook haben aufgezeigt, wie sich das neue Berechtigungsmodell auf die einzelnen Kohorten auswirken würde, was mir dabei half, unsere Annahmen auf Herz und Nieren zu prüfen und mich auf die größten Risiken zu konzentrieren.

Indem ich die tägliche Umsetzung aus der Hand gab, hatte ich mehr Zeit, mich auf die strategische Frage zu konzentrieren, die hinter dem Projekt stand: Spielte eine bessere Dateiorganisation in einer „AI-first“-Welt überhaupt noch eine Rolle, oder wurden Ordner mit der Verbesserung der KI-Suche langsam überflüssig? Wir haben Tools entwickelt, die uns gezeigt haben, wie Ordner mit zunehmendem Arbeitsaufkommen an Bedeutung gewinnen können – und damit der zukünftigen KI-Suche eine reichhaltigere Struktur und mehr Kontext für das Abrufen von Informationen bieten. Am meisten geholfen hat mir aber, mal einen Schritt zurückzutreten, um ein ausgewogenes Portfolio an Investitionen aufzubauen. Neben den verschachtelten Ordnern hat unser Team mit Hochdruck daran gearbeitet, die Funktionen im Figma-Agenten einzuführen – ein weiterer Baustein von Figmas KI-orientierter Strategie. Es mag vielleicht überraschend klingen, aber dadurch, dass ich weniger Zeit damit verbracht habe, jedes Detail im Projektmanagement zu regeln, hatte ich mehr Spielraum, um eine Roadmap zu entwickeln, bei der grundlegende Kundenbedürfnisse und neue KI-native Erlebnisse Hand in Hand vorankommen konnten.

Innerhalb des Projekts selbst war es für mich am wichtigsten, meine Aufmerksamkeit auf die Kund*innen zu richten. Ich übernahm die Leitung des Early-Access-Programms (EAP) und wir arbeiteten wirklich improvisiert. Bei Config habe ich zusammen mit Ayush Mehra, dem Engineering Manager unseres Teams, an Happy Hours teilgenommen, um Kund*innen spontan unser Dateiverwaltungssystem vorzustellen, an dem wir gerade arbeiteten. Wir haben gleich vor Ort mehrere Leute davon überzeugt, beim EAP mitzumachen. Von da an sind wir weiter gewachsen. Die „Friends of Figma“-Communities in Jaipur, Barcelona, Mumbai und Lahore gehörten zu den ersten, die das Konzept aufgegriffen haben. Außerdem habe ich mich an Community-Leader auf der ganzen Welt und an Leute auf X gewandt, die sich besonders intensiv mit dem Thema Dateiorganisation beschäftigt haben – darunter auch Ilya Miskov​, ein Designer, der an einem unserer ersten Sondierungsgespräche teilgenommen hatte.

Das Kundenfeedback hat uns gezeigt, wie sich verschachtelte Ordner in realen Unternehmen verhalten – mit unübersichtlichen Dateien und festgefahrenen Gewohnheiten. Das hat uns geholfen, Fehler zu finden, die Benutzererfahrung zu optimieren und das Risiko zu verringern, das mit der Umstellung der Kunden auf ein völlig neues Inhaltsmodell verbunden ist.

Die Zeit, die ich mit den Kund*innen vor Ort verbracht habe, hat mir eine Art von Produktverständnis vermittelt, das ich allein durch die Ausarbeitung von Spezifikationen nicht hätte erlangen können. Um Kontrolle gegen Überzeugung einzutauschen, musste ich mich auf die Aufgaben konzentrieren, für die ich am besten geeignet war, und gleichzeitig darauf vertrauen, dass andere das Gleiche tun.

Diese Arbeitsweise funktioniert nur, wenn das Team einander vertraut. Ehrlich gesagt war es etwas unangenehm, die Rollen zu vermischen: Es gab Momente, in denen wir uns gegenseitig auf die Füße getreten sind, ungeschickt eine Grenze überschritten haben oder etwas ausprobiert haben, was wir noch nie zuvor gemacht hatten. Dieses Unbehagen gehörte dazu, eine neue Normalität zu finden, und wir konnten es nur überwinden, weil wir in die Beziehungen investiert hatten, die hinter der Arbeit standen. Mit der Zeit legten wir weniger Wert auf unsere jeweiligen Fachgebiete und fingen an, uns gegenseitig aktiv die Aspekte unseres Handwerks beizubringen, die wir zuvor am strengsten für uns behalten hatten.

Durch gemeinsame Rituale haben wir das Vertrauen und den Zusammenhang aufrechterhalten: wöchentliche Bug-Bashes, funktionsübergreifende Abstimmungen, Live-Pairing zwischen Design und Entwicklung sowie Feiern zu wichtigen Meilensteinen – darunter auch die interne Einführung bei Figma. Dank dieser Arbeitsrhythmen haben wir unser Ziel nie aus den Augen verloren und konnten ein mit Spannung erwartetes Kundenversprechen einlösen, ohne dabei Abstriche bei der Qualität zu machen.

Es wird ein paar Wochen dauern, bis die verschachtelten Ordner für alle Benutzer*innen verfügbar sind. Besuche unser Hilfecenter, um mehr darüber zu erfahren, wie du anfangen kannst.