Workflow-Lab: Designs direkt mit Figma Make bereitstellen

Willkommen im Workflow-Lab, wo wir einen Beispiel-Workflow mit Figma-Produkten und -Tools präsentieren.

Traditionell verläuft der Weg von „Ich habe eine Kleinigkeit bemerkt“ bis „Es wurde veröffentlicht“ über ein Ticket. Die Designerin schreibt es auf, es landet im Backlog und wird dann unter allem begraben, was das Ingenieurteam bereits zugesagt hat. Für kleine, hochqualitative Korrekturen ist diese Warteschlange der Ort, an dem gute Absichten sterben. Die Arbeit ist zu detailliert, um priorisiert zu werden, und zu wichtig, um fallen gelassen zu werden, also verweilt sie in der Warteschlange.

Es gibt auch einen zweiten Kostenpunkt. Wenn Designer*innen eine schriftliche Beschreibung übergeben, gehen die Nuancen verloren. „Mache die Abstände etwas enger“ oder „Der Screenreader kündigt dies falsch an“ verwandelt sich in ein Hin und Her von Screenshots und Klarstellungen und Ingenieur*innen werden zu Übersetzer*innen von Entscheidungen, die Designer*innen direkt hätten treffen können. Aber was, wenn es einen anderen Weg gibt, diesen Workflow anzugehen?

Das Problem

Nehmen wir das Museum of Speculative Futures (MOSF) als Beispiel, ein fiktives Museum, das erforscht, wie die Kultur sich vorstellt, was als Nächstes kommt. Sie verbessern die Barrierefreiheit ihrer Webseite zeitgleich zu einer vollständigen Architekturüberarbeitung. Mit verschiedenen konkurrierenden Prioritäten ist die Ressourcenzuteilung für dieses Projekt eine große Herausforderung. Eine Designerin möchte die Barrierefreiheitslücken schließen, während ein Ingenieur sich auf die ebenso wichtige Überarbeitung konzentrieren muss. Um beide Ziele zu erreichen, schlägt die PM einen anderen Weg vor: Die Hauptlast bleibt bei dem Ingenieur, während die Designerin die kleinen, handwerklichen Änderungen von Anfang bis Ende übernehmen, indem sie Figma Make mit ihrem Produktionscode verwenden. Die letzten 20 % sind genau das, was eine Website, die technisch funktioniert, von einer wirklich zugänglichen trennt, daher stimmt das Team diesem Plan zu. Verfolge mit, wie eine Designerin dieses Skript umwerfen und ihre Arbeit von der Arbeitsfläche durch die Überprüfung und bis hin zu einem zusammengeführten Pull-Request bringen – alles, ohne ein einziges Ticket zu erstellen.

Feedback auf der Arbeitsfläche sammeln

Bevor sie irgendetwas anfasst, möchte die Designerin die aktuelle Erfahrung einem Drucktest unterziehen. Sie verwenden den Agentenin Figma Design, um eine Reihe synthetischer Personas zu erstellen – eine Erstbesucherin, die eine Reise plant, ein zurückkehrendes Mitglied, jemand, der mit einem Screenreader navigiert – und lassen jede von ihnen die Seite navigieren, um Feedback zu sammeln.

Das Feedback kommt spezifisch und meist in geringem Umfang zurück: ein verwirrendes Label auf der Ausstellungsseite, ein leicht zu übersehender Call-to-Action, ein Datumsauswahlwerkzeug, das auf den ersten Blick schwer zu erfassen ist, und eine Suche, die auf einem leeren Bildschirm endet, wenn bei einer Collection keine Ergebnisse vorliegen. Keine dieser Änderungen ist groß, aber zusammen sind es Details, die die Website benutzerfreundlicher machen.

Die Designerin geht auf das Feedback ein und bringt die Designänderungen dann für eine finale Überprüfung zurück zum Team. Gemeinsam gehen die Designerin, der Ingenieur und die PM jeden Punkt durch: ein klareres Label auf der Besuchsseite, ein besser sichtbarer Call-to-Action und ein nutzerfreundlicheres Datumsauswahlwerkzeug. Sie stimmen darin überein, dass diese dem gemeinsamen Ziel dienen – einer Website, die jeder navigieren und genießen kann, unabhängig davon, wie er das Web erlebt.

Direktes Arbeiten mit Code, um den Rückstand zu überspringen

Die vereinbarten Änderungen sind klein und gut verständlich, also fragt die Designerin den Ingenieur nach Zugang zum Code-Repository, nicht um die Überarbeitung zu übernehmen, sondern um diese spezifischen Korrekturen direkt zu bearbeiten.

Der Ingenieur gewährt den Zugriff und die Designerin verbindet das GitHub-Repository des Projekts mit Make. Da der Produktionscode nun innerhalb von Figma live ist, erstellt die Designerin einen neuen Zweig von der aktuellen Site und beginnt mit dem, was wie die einfachste Korrektur auf der Liste aussieht: dem Datumsauswahlwerkzeug auf der Ausstellungsseite, den die Personas des Figma-Agenten schwer zu interpretieren fanden.

In einem statischen Mock ist dies eine fünfminütige Änderung. Aber beim Arbeiten am Code zeigt Make etwas, das die Arbeitsfläche nicht kann: Das Datumsauswahlwerkzeug ist kein Einzelfall. Es ist eine gemeinsame Komponente – dieselbe, die im Veranstaltungskalender und im Anmelde-Flow für die Mitgliedschaft verwendet wird. Was nach einer einzigen Anpassung aussah, ist tatsächlich eine Änderung, die an drei Stellen gleichzeitig vorgenommen werden muss.

Ein ticketbasierter Workflow hätte vielleicht allein das Datumsauswahlwerkzeug auf der Ausstellungsseite behoben und den Veranstaltungskalender sowie den Mitglieds-Flow in der alten Version gelassen – eine Inkonsistenz, die niemand bemerken würde, bis viel später, wenn überhaupt. Da die Designerin im Code arbeitet, ist die gemeinsame Abhängigkeit jetzt sichtbar, und die Korrektur kann einmal, an der richtigen Stelle, durchgeführt werden.

Sobald dies erledigt ist, arbeitet die Designerin die restliche Liste ab: das klarere Label, der auffälligere Call-to-Action, die freundlicheren leeren Zustände. Jeder für sich genommen geringfügig, aber zusammen sind sie das, was eine Website, die nur funktioniert, in eine verwandelt, die durchdacht wirkt – die letzten 20 %, die normalerweise nie aus dem Backlog herauskommen.

Überprüfung mit dem gesamten Team

Mit den vorgenommenen Änderungen schickt die Designerin die Arbeit an das Team zur endgültigen Überprüfung. Hier wird das Ziel der Barrierefreiheit spezifisch. Die sichtbaren Korrekturen sind abgeschlossen. Jetzt annotiert das Team , wie jedes von ihnen für assistierende Technologien funktionieren sollte, genau dort, wo es sich befindet. Dazu gehört: das aria-label, das das gemeinsame Datumsauswahlwerkzeug ankündigen sollte, damit es nicht nur lesbar, sondern auch laut vorlesbar ist, ein Bildschirmleserlabel, das dem entspricht, was auf dem Bildschirm angezeigt wird, eine Fokusreihenfolge, die den Aufruf zum Handeln erreicht, anstatt daran vorbeizugehen, und ein leeres Feld mit einer Nachricht, die ein Bildschirmleser ankündigen kann, damit eine Suche ohne Ergebnisse keine stille Antwort ist.

Die PM bestätigt, dass alles weiterhin zum Barrierefreiheitsziel beiträgt, der Ingenieur wägt ab, was im Code behandelt werden muss, und die Designer*in fügt die letzten Anpassungen hinzu.

Die Pressearbeit vorantreiben

Sobald die letzten Annotationen berücksichtigt sind, pusht die Designerin direkt von Make aus einen Pull-Request in die Codebase. Der Ingenieur überprüft den Code (jetzt mit der aktualisierten Design-Absicht, den Kommentaren des Teams und den Barrierefreiheitsanmerkungen, die alle an dieselbe Änderung angehängt sind), genehmigt ihn und führt den Zweig zusammen. Die Korrekturen, die ein Quartal im Backlog verbracht hätten, wurden an einem Tag ausgeliefert.

Diese Arbeitsweise ist eine einfache Änderung mit langfristigem Nutzen. Ein Ticket schließt sich und verschwindet, und die Entscheidungen, die darin lebten, verschwinden mit ihm. Die zusammengeführte Änderung bewahrt sie: die Kommentare, die Barrierefreiheitsanmerkungen, die Begründung, warum das Datumsauswahlwerkzeug geteilt wird. Wenn in sechs Monaten jemand das Datumsauswahlwerkzeug erneut aufruft, ist der Weg bis zu diesem Punkt sofort in der gemeinsamen Historie des Teams zu finden.

Weg zur Produktion: eine andere Art der Übergabe

Das traditionelle Übergabemodell behandelt Designer*innen und Ingenieur*innen als zwei Stationen in einer Fertigungslinie. Das funktioniert gut für große, klar definierte Funktionen. Aber feinere Details, Verbesserungen der Barrierefreiheit und der Feinschliff, der die gesamte Produkterfahrung definiert, erfordern eine andere Art von Übergabe, bei der die Designer*innen direkt im Code arbeiten.

Diese Arbeitsweise verlangt nicht, dass die Designer*innen zu Ingenenieur*innen werden oder umgekehrt. Sie ermöglicht es, in den Bereichen Urteilsvermögen anzuwenden, in denen es am wichtigsten ist: Die Ingenieur*innen blieben beim Architekturumbau, die Designer*innen übernahmen die Verfeinerungen bis ins kleinste Detail und die oder der PM hielt das gesamte Projekt auf Kurs. Der Zweig trug den Beitrag aller – sichtbares Design, schriftliches Feedback und die Beschriftungen, die ein Bildschirmleser laut vorlesen wird – von der Arbeitsfläche zu einem zusammengeführten PR.

Mit diesem Workflow wurden die letzten 20 % nicht herausgeschnitten. Sie wurden geliefert.

Erfahre mehr darüber, wie du deine Make-Projekte direkt auf GitHub pushen kannst, in unserem Hilfe-Center oder betrachte unsere neuesten Config-Vorträge zu Im Code entwickeln und Arbeiten mit dem Figma Design-Agenten.