Welche Kunst und Wissenschaft hinter den Anmerkungen in Dev Mode steckt

Figma-Dateien zu kennzeichnen ist für mich eine Hassliebe. Auf der einen Seite erfüllt es mich mit Stolz, einem Design den letzten Schliff zu geben, aufmerksam darauf zu achten, dass alle technischen Daten und Maße enthalten sind. Manchmal ist es nur eine Textnotiz, ein Pfeil, eine Hervorhebung, manchmal ist es zusätzlicher Kontext, der die Intention hinter einer Designentscheidung erläutert, der fast so wichtig ist, wie eine Design-Eigenschaft selbst. Auf der anderen Seite fühlt sich das Kennzeichnen der Datei an wie ein großer Zeitfresser, auch wenn es einen großen Unterschied beim abschließenden Produktentwicklungsprozess machen kann. Designer*innen stecken eine Menge Zeit in das Beschreiben, die Zeichnungen und die manuelle Verwaltung einer Datei, damit jede Designanforderung akkurat repräsentiert ist; und genauso viel Zeit investieren Entwickler*innen in die Designumsetzung, Kontexterfassung und Anforderungssammlung, um das Konzept zum Leben zu erwecken.

Oft erstrecken sich diese nicht-visuellen Anforderungen über verschiedene Dateien und Tools, egal ob es sich um ein Dokument mit Produktanforderungen oder eine Designdatei handelt. Unsere Anmerkungen sollten so aufgebaut sein, dass alle Inhalte an einem Ort zu finden sind – eine vollständiges technisches Datenblatt direkt in Dev Mode – und sich sowohl für Anwendungsfälle von Designer*innen als auch von Entwickler*innen zweckgebunden aufbaut.

Beim Entwickeln der Funktion mussten wir einige Schlüsselprobleme lösen, damit anschließend die Kluft zwischen Design und Programmcode geschlossen ist: Anmerkungen zu erstellen, kann zeitaufwändig sein, sie veralten schnell und machen Designdateien oft unübersichtlicher.

Lösungen für Designer*innen und Entwickler*innen

Um einen roten Faden zu bekommen, sind wir einen Schritt zurückgegangen, um uns zunächst zu überlegen, welche Rolle Anmerkungen im Designprozess spielen sollen – beim aktuellen Arbeitsschritt und auch für zukünftige Aufgaben – aufbauend auf den Rückmeldungen von Designer*innen und Entwickler*innen.

Anmerkungen enthalten für Designer*innen häufig Designeigenschaften, die im Design selbst nicht erfasst werden können. Designer*innen benötigen einen Ort, um so etwas wie Barrierefreiheitseigenschaften oder detailliertes interaktives Verhalten festhalten zu können.

Für Entwickler*innen unterscheidet sich das Teilen eines Designs vom Teilen einer Konstruktionsaufgabe darin, dass sie der Herausforderung gegenüberstehen, die Nadel im Heuhaufen zu finden. Designdateien enthalten oft so viele Informationen und so viel Arbeit, dass es schwierig sein kann, herauszufinden, auf welchen Teil man sich konzentrieren sollte. Das Zusammenstellen ist daher ein wichtiger Teil im Designprozess.

Und wegen dieser unterschiedlichen Bedürfnisse und Herangehensweisen wurden die Anmerkungen in Dev Mode genau daran ausgerichtet, was intern zu häufigen Diskussionen geführt hat. Anmerkungen können für viele verschiedene Schritte im Designprozess genutzt werden, aber am allerwichtigsten war es, die Prozesse von Designer*innen und Entwickler*innen einander anzunähern und die speziellen Störfaktoren zu überwinden.

Wir wollten einen speziellen Bereich, um technische Details für Entwickler*innen zusammenzustellen und notwendige Details oder knifflige Bereiche hervorzuheben. Daher wurde schlussendlich entschieden, dass Designer*innen ihre Anmerkungen in Dev Mode verfassen sollten. Dabei würden sie genau das sehen, was ihre Entwicklerkolleg*innen sehen, und sie könnten einen Link zu Dev Mode teilen, sobald sie fertig sind. Unser Ziel ist es nicht, Dev Mode zu einem Silo für Entwickler*innen zu machen, sobald die Designarbeit erledigt ist, sondern das umliegende Team in den Produktentwicklungsprozess einzubeziehen. Und dabei sind Anmerkungen ein erster, entscheidender Schritt.

Die Kraft dynamischer Veränderungen

Da nun der übergeordnete Ansatz skizziert wurde, haben wir uns anderen wichtigen Designentscheidungen zugewandt. Bisher mussten Designer*innen ihre Anmerkungen manuell erstellen, was bedeutet, dass Anmerkungen bei Änderungen von Designs immer hinterherhängen. Dieser Prozess funktioniert, wenn ein*e Designer*in die Arbeit beendet und das Design als „entwicklungsfertig“ markiert. Häufig benötigt stetige Produktenwicklung jedoch eine ständige, klare Kommunikation, da Designer*innen mehrere Wiederholungen durchlaufen und Entwickler*innen eine einfache Möglichkeit benötigen, Änderungen nachzuverfolgen.

Bei einem Design-Sprint ganz am Anfang überlegten wir: „Wie wäre es, wenn man in einem Design Anmerkungen mit Eigenschaften verbinden könnte?“ Damit würde sich der Aufwand für die Designer*innen deutlich verringern, weil sie die Designdetails nicht mehr manuell übertragen müssten, wenn sie Dateien kennzeichnen. Gleichzeitig blieben alle Anmerkungen auf dem aktuellsten Stand, auch wenn sich die Designs ändern. Entwickler*innen können sich darauf verlassen, dass alle Anmerkungen, die sie sehen, auf dem neuesten Stand mit dem Design sind, selbst wenn die Designer*innen noch aktiv Änderungen daran vornehmen.

Den gleichen Ansatz haben wir auch für die Abmessungen verwendet, denn wenn sich ein Design ändert (was es zwangsläufig tut), ändert sich nicht automatisch auch die Linie, die eine Abmessung angibt.

Und es geht nicht nur darum, was sich in einem Design verändert hat. Reine Textnotizen lassen viel Interpretationsspielraum, wenn Anmerkungen aber konkreten Variablen und Komponenten im Designsystem zugeordnet sind, können Entwickler*innen darauf vertrauen, dass die technischen Daten zur Programmcodegrundlage passen.

Die Logik hinter der Positionierung

Studien und unsere Erfahrung zeigten, dass Designer*innen nach wie vor immer wieder mühsam Rahmen verschieben, um Platz für Anmerkungen zu schaffen. Kommen weitere Anmerkungen hinzu, geht die Endlosschleife weiter, es werden wieder Rahmen neu angeordnet, nur, damit die Inhalte an der richtigen Stelle platziert werden können. Wir haben uns gefragt, ob es eine Möglichkeit gibt, dass Anmerkungen zwar für Entwickler*innen ausreichend sichtbar sind, aber ohne tatsächlich Platz auf der Figma-Arbeitsfläche zu beanspruchen.

Eine Designrichtung war vielversprechend: Anmerkungen automatisch positionieren und anzeigen. Es fühlte sich wie ein riesiger Schritt an, im Vergleich zu der bisherigen Methode für Anmerkungen, aber wenn wir es richtig machten, würde sich der Aufwand für die Designer*innen drastisch verringern, weil sie ihre Dateien nicht mehr ständig neu gruppieren müssten, und es würde gleichzeitig die Ansicht für Entwickler*innen aufs Wesentliche lenken. Aber diese Aufgabe wirkte wie ein riesiger Berg, da dafür Dutzende von Prototypen und Wiederholungen vonnöten wären. Es gab dabei so viele Interaktionen. Zoomen. Schwenken. Skalieren. Minimieren. Auswählen. Bewegen.

Unser Designteam übernahm die Führung bei der Optimierung unserer Anzeigelogik, um zu gewährleisten, dass diese Designidee tatsächlich benutzerfreundlich wird. Während einer frühen ganzheitlichen Präsentation der Software vom Entwickler Roshan Bhalla sah unser Team das erste Mal, wie ihre Vision zur Wirklichkeit wurde.

Zunächst war der Plan, die Anmerkungen außerhalb des Rahmens der obersten Ebene beim jeweils zu beschriftenden Element zu positionieren. Doch Betanutzer*innen zeigten uns, dass dadurch die Anmerkungen zu weit entfernt lagen, sobald Designer*innen mit verschachtelten Rahmen arbeiten. Um dieser Herausforderung gerecht zu werden, haben wir einige Verbesserungen vorgenommen:

• Festlegen eines Maximalabstands zwischen einer Anmerkung und dem dazugehörigen Element
• Beschriftungen stoßen am Rand des Fensters an, damit sie beim Schwenken sichtbar bleiben

Aber wir erkundeten weiter: Nach dem Feedback aus der Beta- und internen Testphase haben wir viele weitere Ansätze getestet, einschließlich physikbasierter Positionierung:

Das Testen und Wiederholen unserer Positionierungslogik war schon für sich genommen ein Abenteuer. Einmal hatten wir probiert, Anmerkungen auszublenden, bis Nutzer*innen einen entsprechenden Rahmen anklicken. Das klappte in der Theorie, aber bei einem realen Testlauf stellte sich heraus, dass man dadurch immer noch zu leicht wichtige Anmerkungen übersehen konnte, falls man sich nur einen Rahmen ansah, ohne ihn aktiv auszuwählen.

Wir wiederholten das auf verschiedenen Versionen mit sich automatisch aufklappenden Anmerkungen je nach Zoomstufe und Position, und das fühlte sich sofort intuitiver an. An diesem Punkt haben wir der UI einen temporären Schieberegler hinzugefügt, mit dem wir verschiedene Vergrößerungsfaktoren einstellen konnten, bis wir die passende Stufe gefunden hatten. Das Ausfeilen dieser Interaktionen machte viel davon aus, wie wir das Gesamtsystem wahrnahmen.

Die Verbesserungen zielen insbesondere auf Geschwindigkeit und Verknüpfung von Anmerkung und Design ab, doch es fühlte sich an, als würden wir Anmerkungen als solche komplett neu denken. Wir wussten jedoch auch, dass fast jedes Team, mit dem wir gesprochen haben, eine ganz eigene Nutzung von Anmerkungen während des Workflows hatte und sie anders darstellten. Bei einigen dienten Anmerkungen als Aufgaben oder Anforderungen, die nachverfolgt werden sollten und die mit Tools zur Aufgabenverwaltung verknüpft werden sollten.

Im Hinblick auf zukünftige Projekte sind wir zufrieden, den Ansatz gewählt zu haben, der die Erweiterbarkeit an erste Stelle rückt und Teams ermöglicht, mithilfe der Plug-in-API ihre eigenen Workflows um Figmas Anmerkungsfunktion herum zu erstellen. Doch dazu später mehr.

Anmerkungen als Teil des Ganzen

Wir freuen uns, nach unzähligen Feedbacks durch Nutzer*innen nun die Anmerkungsfunktion zu veröffentlichen. Es wird Dev Mode zum Schlüssel-Tool für Designspezifikationen machen. Ein umfassender Ort, an dem Designer*innen ihre Vorhaben teilen und Entwickler*innen gleichzeitig alle Kontextinformationen erhalten, die sie brauchen.

Wir hoffen, dass Anmerkungen in Dev Mode es Designer*innen und Entwickler*innen erleichtern, die genaueren Details ihrer Arbeit besser zu kommunizieren. Wir sind uns natürlich bewusst, dass Anmerkungen nicht die einzige Lösung zur Verbesserung der Kommunikation zwischen diesen wichtigen Abteilungen sind, sondern nur ein Teil des Prozesses, bei dem es sich unserer Meinung nach gelohnt hat, ihn zu vereinfachen. Wir freuen uns darauf, bei unserer weiteren Arbeit an Dev Mode an weiteren Details der Zusammenarbeit von Designer*innen und Entwickler*innen zu feilen und freuen uns daher auf dein Feedback zu den Themen, die wir als nächstes angehen sollen.

Erfahre mehr über alles, was heute erscheint und was als Nächstes für Dev Mode geplant ist.

Vielen Dank an die Arbeitsgruppe bei Figma: Product Manager Benson Perry, Entwickler*innen Ed Bentley, Roshan Bhalla, Jenny Lea, Karl Jiang, und Sue Hitchins, Engineering Manager Noga Mann, Researcher Molly Jane Nicholas und Data Scientist Collin Wiles.