Handoffs zwischen Design und Entwicklung mit Figma und Jira integrieren und optimieren

Produktgeschwindigkeit – die Fähigkeit, die richtigen Features schnell bereitzustellen – ist das A und O guter Benutzererfahrungen. Mit zunehmender Größe können Unternehmen diese Geschwindigkeit jedoch meist nicht beibehalten. Die Fähigkeit, schnell zu liefern und zu testen, kommt nicht von ungefähr. Hinter jedem neuen Feature oder Produkt-Update stehen eine Reihe von Tools, Prozessen und Abläufen, die die Zusammenarbeit von Teams erleichtern. Dadurch lässt sich der schwer fassbare Flow-Zustand erreichen, in dem Teams so effizient wie möglich zusammenarbeiten, iterieren und ausliefern können.

Flow-Zustände werden normalweise mit einer Person assoziiert, die alleine und ohne Unterbrechung an einer bestimmten Aufgabe arbeitet. Aber so sieht die Realität selten aus, insbesondere in der heutigen hybriden Arbeitswelt, in der Kalender wie ein endloses Tetris-Spiel aussehen und sich Anforderungen ständig ändern. Ebenso wie gleichbleibende Geschwindigkeit Arbeit erfordert, musst du zuerst an deinen Grundlagen arbeiten, um in dieser Umgebung einen Flow-Zustand zu finden.

Wir bei Figma sind immer auf der Suche nach neuen Möglichkeiten, um Design- und Entwicklungs-Workflows näher zusammenzubringen, damit Teams inmitten der konstanten Nachrichtenflut, die unsere Produktivität gefährdet, einen Flow-Zustand erreichen können. Vor dem Launch der aktualisierten App Figma for Jira haben wir in verschiedenen Branchen nachgefragt, wie sie ihre Teams in den Flow bringen.

Mit Figma for Jira siehst den gesamten Kontext, wenn du Designs in Code umwandelst.

Ein Prototyp sagt mehr als tausend Worte

Mit wachsender Unternehmensgröße werden Prozesse immer langsamer. Größere Teams haben zur Folge, dass Mitarbeiter*innen und Arbeitsgruppen in Silos arbeiten, und hybride Arbeitsmodelle können die Koordination erschweren. Damit eine nahtlose Zusammenarbeit gewährleistet ist, müssen alle Teammitglieder wissen, welches Ziel sie verfolgen, und gemeinsam darauf hinarbeiten. Konstante Abstimmung, die besonders entscheidend ist für den Produktentwicklungsprozess, erfordert ständige Kommunikation.

Einander verstehen mit einem High-Fidelity-Prototyp

Ein- und dasselbe Wort kann für verschiedene Menschen unterschiedliche Bedeutungen haben. Designer*innen und Entwickler*innen verstehen sich besser, wenn sie einen Prototyp in Aktion sehen. Bei One.com trifft sich das Designteam in Dänemark regelmäßig mit dem Entwicklungsteam in Indien, um Anforderungen, Hindernisse und mögliche Probleme zu besprechen. Während eines kürzlichen Meetings stellte das Entwicklungsteam einen Prototyp für ein neues Text-Feature vor. Das Entwicklungsteam versammelte sich dabei um einen High-Fidelity-Prototyp in Figma, sodass alle den interaktiven Status mitverfolgen und überprüfen konnten. Ein statischer Low-Fidelity-Prototyp vermittelt einen guten Einblick in das Design. Ein interaktiver High-Fidelity-Prototyp hingegen gibt einen Überblick darüber, wie das Endprodukt funktionieren sollte: kritische Details wie die Entstehung von Nutzerflows, das Öffnen von Pop-up-Fenstern und die Funktionsweise von Dropdown-Menüs. Nick van der Meulen, Group Head of UX and Design, sagt: „Das ist ein großer Unterschied zu unserer Software in der Vergangenheit, bei der wir eine Million Seiten anklicken mussten, um sie miteinander zu verknüpfen. Jetzt haben wir interaktive Prototypen in einer einzigen Software.“

Ein High-Fidelity-Prototyp bietet außerdem Kontext, damit das größere Team asynchron und dezentral arbeiten kann. Denn das Geschehen während eines Meetings ermöglicht den Flow außerhalb des Meetings. Bei Condé Nast führt das Produktentwicklungsteam ein tägliches Stand-up durch, um Fortschritte und Prioritäten zu besprechen. Dank dieser Meetings bleiben alle im Team up to date, erkennen Hindernisse frühzeitig und können Fragen rechtzeitig klären. Bei einem dieser Meetings besprach das Team ein großes Projekt anhand eines interaktiven High-Fidelity-Prototyps in Figma. Tom Smith, Senior Director of Design, erinnert sich: „Dieser Prototyp diente als Brücke zwischen Design und Entwicklung. Damit waren unsere Entwickler*innen in der Lage, auf greifbare Weise mit dem Design zu interagieren, was unsere gemeinsame Vision festigte und das Team dazu motivierte, sie gemeinsam zum Leben zu erwecken.“

Zwischenergebnisse präsentieren

Die Designer*innen und Entwickler*innen im Designsystem-Team der Ingka-Gruppe teilen gerne ihre laufende Arbeit über Low-Fidelity-Prototypen. Zwar stellt das Team der Ingka-Gruppe seine ausgearbeiteten Prototypen jeden Monat vor, doch es führt auch wöchentliche interne Sitzungen durch. Diese ermutigen die Teammitglieder, ihre Erkenntnisse in einer entspannten, informellen Umgebung zu teilen. Henrik Wangström, ein Experience Design Operations Program Manager, sagt: „Du könntest sogar einfach ein Blatt Papier zeigen, wenn du möchtest.“

Die Teammitglieder ermutigen einander dazu, unvollständige Projekte vorzustellen, selbst wenn das verunsichernd sein kann. Nouman Tariq, ein Engineering Manager für das Designsystem erklärt: „Das Vorstellen unvollständiger Arbeit ist für viele Menschen ein Hindernis. Sie denken vielleicht ‚Es ist noch nicht abgeschlossen' oder ‚Ich bin damit noch nicht zufrieden'. Es geht darum, im Team eine Kultur zu schaffen, in der wir häufig und frühzeitig Feedback einholen, sodass wir sicher sein können, dass wir die richtigen Dinge bauen und sie in kurzen Abständen veröffentlichen.“ Durch das Vorstellen früher Arbeiten – ob in Form eines Prototyps, eines groben Sketches oder auch nur der Ergebnisse einer Brainstorming-Session – lässt sich schnell iterieren und testen.

Selbst kurzlebige Updates brauchen eine verlässliche Informationsquelle

In einer Welt, in der Remote- und Präsenzarbeit kombiniert werden, lässt sich inmitten des Lärms von Datei-Updates, Slack-Benachrichtigungen und neuen Deadlines leicht ein Update verpassen, sodass du plötzlich an einem Projekt arbeitest, das nicht mehr relevant ist. Entscheidungen, die in Meetings oder Slack getroffen werden, müssen auch an anderer Stelle übernommen werden. Hier wird eine zuverlässige Informationsquelle wichtig.

Verschiedene Quellen für verschiedene Informationen

Viele Teams streben noch immer eine einzige Informationsquelle an. Es ist jedoch nicht immer sinnvoll, einen Raum oder ein Forum für alle Teams zu haben. Jedes Team benötigt unterschiedliche Arten von Informationen, Tools und Methoden.

Während Figma DAS Tool für Designer*innen ist, benötigen Entwickler*innen viele verschiedene Tools für ihre Arbeit. „Wenn wir beispielsweise die technischen Details für ein Textfeld angeben müssen, müssen Entwickler*innen in der Lage sein, mehrere Typen, wie z. B. eine Zahl oder einen Textstring, im Web einzustellen“, so Carlos Báez, Design Systems Director bei Turo. Das Entwicklungsteam dokumentiert technische Details in seinen Produktanforderungsdokumenten (PRD), die Tabellen mit Komponenteneigenschaften und -dokumentation, Token-Abhängigkeiten, Benutzerinteraktion und Design enthalten. Carlos sagt: „Die Tabellen für diese Komponenten sind ziemlich kompliziert, in denen alles aufgelistet ist und die wir als Informationsquelle für die Komponenten-API verwenden.“

Experian organisiert Informationen nach ihrer strategischen oder taktischen Bedeutung. Design Systems Developer Shelby Foster sagt: „Figma ist perfekt für Situationen, in denen wir direkt mit der Designabteilung über eine bestimmte Komponente sprechen möchten, und Jira ermöglicht dem Team tiefergehende Diskussionen über spezifische Features oder Workflows.“

Die ideale Verwaltung dieser verschiedenen Informationsquellen erfolgt über ihre Integration. Design Systems Designer Keith Barney sagt: „Wir haben kürzlich damit begonnen, die App Figma for Jira zu verwenden, um alle projektbezogenen Informationen an einem Ort zu sammeln. Davon profitieren sowohl die Designer*innen als auch die Entwickler*innen, da wir alle auf dieselbe Informationsquelle zugreifen und weniger zwischen Aufgaben und Anwendungen wechseln müssen.“

Die Teams für Designsysteme und Front-End-Entwicklung von Experian nutzen auch den Dev Mode, den Figma-Arbeitsbereich für Entwickler*innen, in dem sie alles finden, um ihre Workflows zu verwalten. Shelby sagt: „Dadurch konnten wir all unsere Komponentendokumentation und -ressourcen an einem einzigen Ort konsolidieren, ohne dass wir uns auf mehrere Tools verlassen müssen. Es bietet dem Rest unserer Front-End-Teams eine einzige Informationsquelle für unsere Designsystemkomponenten und eine Komponenten-Testumgebung, um mit ihnen zu interagieren.“

Erfahre hier, wie du mit Dev Mode schneller in deinen bevorzugten Tools arbeiten kannst.

Weniger Wechselkosten

Bei mehreren Informationsquellen, die nicht eindeutig übereinstimmen, zahlen wir Wechselkosten – die Zeit, Energie und der Kontext, die verloren gehen, wenn wir zwischen Artefakten wechseln müssen. Das kann teuer und anstrengend sein. So hat das Produktentwicklungsteam bei Woolworth früher viel Zeit damit verbracht, darüber zu diskutieren, ob ein Jira-Ticket die neuesten Entwürfe enthielt, die das Team mit Screenshots kommentierte. Durch die Integration der beiden Informationsquellen – Figma und Jira – sind veraltete Screenshots kein Problem mehr.

„Wir verwenden die Live-Einbettungsfunktion von Figma, um die aktuellsten Designs in unsere Jira-Tickets für unsere Entwicklungsteams aufzunehmen“, so User Interface Design Manager Cindy Ramos. „Das beschleunigt auch die Sprint-Planung um einiges, wenn wir die Updates oder Journeys direkt in Jira durchgehen können. Wir verwenden auch das Jira-Widget, um kleinere Updates direkt in unseren Figma-Boards zu kennzeichnen, damit die Entwickler*innen genau wissen, wo sie sie finden können.“

Ähnlich dazu verwendet Condé Nast Jira für das Projektmanagement und die Problemverfolgung und Figma für die neuesten Designobjekte und Prototypen. Das Technikteam integriert die beiden, indem es Figma-Dateien direkt mit Jira-Themen verknüpft.

Erhalte mit Figma for Jira den vollen Kontext, wenn du Designs in Code umwandelst.

Flow ist lediglich ein wiederholbarer Rahmen

Wenn ein Design in Figma als fertig für die Entwicklung markiert wurde, kannst du den entsprechenden Status in den verknüpften Jira-Issues sehen.

Mit Konsistenz lässt sich Zeit und mentale Kraft sparen. Für One.com bedeutet dies, sich von einem der beständigsten Unternehmen der Welt inspirieren zu lassen: McDonald's. „Wenn man eine McDonald's-Filiale betritt, weiß man genau, was man bekommt. Wenn ein Entwickler oder eine Entwicklerin eine Datei erhält, wird der Inhalt anders sein, aber die Struktur, die Benennung sieht immer gleich aus“, so Carl Webb, ein Lead UI Designer bei One.com. „Das macht es auch für mich einfacher. Wenn ich die Arbeit eines anderen UI-Designers übernehme, dann weiß ich, wo alles sein sollte.“

Die Bedeutung von Vorlagen

Um dieses hohe Maß an Konsistenz zu erreichen, erstellt One.com eine Handoff-Datei in Figma. Berrie Schoots, Design Ops Lead bei One.com, beschreibt die Handoff-Datei als „eine Vorlage, die alle verschiedenen befüllten Seiten enthält – von einer Testumgebung über die Wireframes bis hin zu den tatsächlichen Entwürfen in den Spezifikationen, in denen du alles festhältst. Alle, die die Datei verwenden, können sehen, welche Arbeiten gerade durchgeführt werden, was zum Entwickeln bereit ist und was die Entwickler*innen bereits erstellt haben.“

Carl sagt: „Auf der Seite für Work in Progress und Design wartet ein Jira-Widget. Designer*innen müssen also nur ihre Aufgabe damit verbinden. Alles wird in Abschnitte unterteilt. So lässt sich leicht erkennen, was zusammengehört und was nicht.“

Diese Dateien enthalten nicht nur einen Prototyp, sondern normalerweise auch ein Flussdiagramm, dem Entwickler*innen folgen können. Es sieht aus wie eine Karte der Bildschirme mit Pfeilen (aus FigJam kopiert) und Erläuterungen dazu, was als nächstes passiert und welche Interaktionen stattfinden. Senior Software Engineer Yannick de Lange sagt: „Ich finde die Übersichtsseiten besser als die Prototypen, weil sie Dinge in einen Kontext stellen. Sie zeigen uns von einem Bildschirm zum nächsten, was geschieht, und zwar mit Anmerkungen. Ich klicke nie auf die Wiedergabe-Schaltfläche.“

Es gibt nicht den einen richtigen Weg, um die Arbeit durch die chaotische Mitte voranzubringen. Als letzter Tipp vielleicht: Ein Flow-Zustand mag sich zwar mühelos anfühlen, aber die Schaffung der Grundlagen dafür ist ein hartes Stück Arbeit. Apps wie Figma for Jira halten die wichtigen kleinen Dinge zusammen, damit du dich auf die großen Entscheidungen, die Planung und Ausführung konzentrieren kannst. Erfahre hier mehr über die neueste Version von Figma for Jira.

Erhalte mit Figma for Jira den vollen Kontext, wenn du Designs in Code umwandelst.