Mit KI vom Design zum Werkzeug: ein YouTrack-Widget für Figma

Ausgangslage

Üblicherweise verlinken wir das Design im Ticket. Häufig werden Screens aber noch angepasst, wenn die Umsetzung bereits läuft. Dann passiert meist eines von drei Dingen:

1. Die Entwicklung behält das Design während der gesamten Umsetzung im Blick und prüft selbst, ob sich etwas geändert hat.
2. Das Design sucht bei jeder Änderung an einem Screen die betroffenen Tickets heraus und informiert die Entwicklung.
3. Die Abweichung zwischen Design und Implementierung fällt erst im Test auf, im ungünstigsten Fall noch später.

Die ersten beiden Varianten erfordern dauerhafte Aufmerksamkeit und setzen voraus, dass niemand etwas übersieht. Die dritte ist die aufwendigste, da bereits umgesetzte Arbeit nachgebessert werden muss.

Die Idee: ein Werkzeug aus dem Design

Das Ziel war es, Figma und YouTrack im Arbeitsablauf besser zu koppeln, und zwar aus dem Design heraus, also direkt in Figma. Der Stand eines Tickets sollte direkt neben dem Screen zu sehen sein. Änderungen am Design sollten ohne Umweg bei der Entwicklung ankommen. Figma bietet dafür sogenannte Widgets an. Das sind kleine Programme, die als Element direkt auf der Arbeitsfläche liegen und für alle Beteiligten einer Datei sichtbar sind.

Vorgehen: iterativ mit Claude Code

Entwickelt habe ich das Widget mit Claude Code in Visual Studio Code. Als Ausgangspunkt diente das Grundgerüst aus der offiziellen Figma-Dokumentation. Die weitere Arbeit verlief in kurzen Runden: Anforderungen und Anpassungen beschreiben, das Ergebnis direkt in Figma testen und daraus die nächste Runde ableiten.

Phase 1: ein Prototyp in zwei Stunden

Die erste Version bildet das Ticket in Figma ab. Die Karte zeigt Ticket-ID, Titel, Status und die zuständige Person. Jeder Status hat eine eigene Farbe. So ist der Stand mehrerer Tickets auf einer Seite sofort erkennbar.

Phase 2: Design-Änderungen als Kommentar im Ticket

In Phase 2 kam die Verknüpfung mit Screens hinzu. Sobald ein Ticket den Status „Open“ verlässt, also die Umsetzung beginnt, speichert das Widget den aktuellen Stand der verknüpften Screens als Referenz. Weicht ein Screen später davon ab, zeigt die Karte das beim nächsten Aktualisieren an. Kurze Schlagworte wie „2 Texte“, „1 neu“ oder „Layout“ geben dabei einen ersten Überblick über die Art der Änderung.

Per Klick erzeugt das Widget daraus einen Kommentar, der die Änderungen im Detail auflistet. Vor dem Absenden lässt sich der Kommentar prüfen und um eigene Anmerkungen ergänzen. Entwicklung, Projektmanagement und Testing erfahren die Änderungen so in dem Ticket, in dem sie ohnehin arbeiten. Das Design muss die betroffenen Tickets nicht mehr selbst heraussuchen.

Die eigentliche Herausforderung lag dabei nicht im Code, sondern in der Frage, welche Änderungen überhaupt relevant sind. Die erste Version meldete zum Beispiel nicht nur die geänderte Ebene selbst, sondern auch jede Ebene, die damit zusammenhing. Das war technisch zwar korrekt, für die Entwicklung aber kaum brauchbar. Nützlich wurde das Widget erst, als ich festgelegt hatte, was zählt.

Was sich für das Design verändert

Früher wäre eine Idee wie diese als Ticket bei der Entwicklung gelandet und hätte dort mit Produktfeatures um Priorität konkurriert. Interne Werkzeuge, die „nur“ einen Prozess verbessern, verlieren diesen Vergleich meistens.

Mit KI verschiebt sich das. Wer im Design arbeitet, kann solche Ideen jetzt selbst umsetzen, auch ohne tiefe Programmierkenntnisse. Entscheidend sind Fähigkeiten, die zum Design ohnehin dazugehören: ein Problem genau verstehen, Anforderungen präzise beschreiben und ein Ergebnis kritisch prüfen. Den Code schreibt die KI. Ob das Werkzeug das Richtige tut, beurteilt das Design.

Damit ändert sich auch die Frage, die man sich bei einem Problem im Arbeitsalltag stellt. Sie lautet nicht mehr „Das müsste mal jemand bauen“, sondern „Lässt sich das an einem Nachmittag ausprobieren?“

Ganz ohne Entwicklung geht es trotzdem nicht. Spätestens wenn es um Sicherheit, Code-Review oder Wartung geht, braucht es ihre Expertise. Die Zusammenarbeit beginnt aber nicht mehr bei einer Idee, sondern bei einem Prototyp, der bereits funktioniert.

Takeaways

• Selbst ausprobieren: Wer den Prozess kennt, kann mit KI das passende Werkzeug bauen. Programmierkenntnisse sind dafür weniger entscheidend als ein klares Verständnis des Problems.
• Anforderungen genau formulieren: Die KI liefert schnell Code. Welche Informationen relevant sind, muss das Fachwissen festlegen.
• In kurzen Runden testen: Jede Anpassung direkt in Figma prüfen. So zeigt sich schnell, ob das Ergebnis passt und was als Nächstes kommt.
• Klein anfangen: Phase 1 hat nur den Ticketstand abgebildet. Auf dieser Grundlage ließ sich Phase 2 schrittweise aufbauen.

Ausblick

Phase 2 ist umgesetzt, aber noch nicht im Projektalltag erprobt. Als Nächstes setzen wir das Widget in einem laufenden Projekt ein. Welche weiteren Phasen sinnvoll sind, soll sich aus dieser Nutzung ergeben.

Das Projekt hat uns gezeigt, wie schnell sich mit KI ein Werkzeug für einen konkreten Prozess entwickeln lässt, wenn das Fachwissen direkt in die Entwicklung einfließt. Unser Ziel bleibt dabei, dass Design und Entwicklung mit möglichst wenig Aufwand auf demselben Stand sind. Und manchmal bauen wir als Designer die Lösung dafür jetzt einfach selbst.

‍