UX goes Dev

Die Zeiten klar getrennter Disziplinen in der Softwareentwicklung sind vorbei. Wo früher Design „vorgelagert“ und Entwicklung „nachgelagert“ stattfand, entstehen heute digitale Produkte in einem integrierten, iterativen Prozess. User Experience, User Interface und technische Umsetzung wachsen zusammen – fachlich, organisatorisch und zunehmend auch toolseitig. Im Zentrum dieses Wandels steht das Tool Figma. Was einst als kollaboratives UI-Design-Tool begann, entwickelt sich immer stärker zur zentralen Arbeitsplattform zwischen Entwurf, Designsystem und Code. Für Entwicklungsteams verändert das nicht nur die Zusammenarbeit, sondern auch das Verständnis von Qualität, Konsistenz und Effizienz.

Mit der Einführung des Dev Mode – eines dedizierten Modus mit entwicklerzentrierter Ansicht, dem Status „Ready for dev“, Diffs und Code-Snippets – positioniert sich Figma explizit als Workspace für Entwicklungsteams, nicht nur als Design-Tool. Zu den zentralen Ökosystem-Bausteinen zählen das Uno Platform Figma Plugin, das XAML- oder C#-Markup direkt aus Figma-Layouts für .NET- und Uno-Anwendungen generiert, Microsoft-UI-Kits (Fluent 2, Windows UI 3 und Fabric als Figma-Bibliotheken), die nahtlos an Microsofts Designsysteme andocken, sowie Design-Token-Tools wie Tokens Studio, die Figma-Variablen mit plattformneutralen JSON-Token-Dateien synchronisieren und so für eine einheitliche Gestaltungssprache über Design und Code hinweg sorgen.

UX, UI-Designsystem und Implementierung verschmelzen somit zu einem gemeinsamen, iterativen Prozess. Dies ist besonders attraktiv im .NET-Stack, der mit XAML, MVVM und unterschiedlichen, aber verwandten UI-Frameworks traditionell eine saubere Trennung von Logik und Darstellung kennt.

Entwicklungsprozess neu gedacht

Klassische Entwicklungsmodelle folgten viele Jahre einem klar strukturierten, linearen Ablauf (Bild 1). Zunächst wurden Anforderungen analysiert, anschließend in Designartefakte übersetzt, danach technisch implementiert und schließlich getestet. Diese strikte Phasentrennung vermittelte auf den ersten Blick Ordnung und Planbarkeit, führte in der Praxis jedoch häufig zu Reibungsverlusten. Medienbrüche zwischen Skizzen, Spezifikationen und Code waren die Regel, nicht die Ausnahme. Missverständnisse über Layouts, Abstände, Interaktionen oder Zustände führten zu inkonsistenten Benutzeroberflächen, erhöhtem Abstimmungsaufwand und nicht selten zu Frustration sowohl aufseiten des Designteams wie auch des Entwicklungsteams.

Mit der zunehmenden Komplexität digitaler Produkte und dem wachsenden Anspruch an Benutzererlebnis und Qualität stößt dieses Modell jedoch an seine Grenzen. Moderne Produktentwicklung folgt daher einem anderen Paradigma (Bild 2): Design und Entwicklung arbeiten nicht mehr sequenziell, sondern parallel, iterativ und auf Augenhöhe. UX-Entscheidungen entstehen nicht länger isoliert im Designprozess, sondern im kontinuierlichen Dialog mit der technischen Umsetzung. Fragen der Machbarkeit, der zugrunde liegenden Architektur und der Wiederverwendbarkeit von Komponenten fließen frühzeitig in konzeptionelle Überlegungen ein. Umgekehrt beeinflussen technische Rahmenbedingungen und bestehende Systemstrukturen das Design, ohne dessen Qualität oder Nutzerzentrierung zu kompromittieren.

Diese enge Verzahnung verändert nicht nur Prozesse, sondern auch Rollenverständnisse. Designer denken stärker in Systemen, Zuständen und Varianten, Entwickler wiederum befassen sich intensiver mit Interaktion, Wahrnehmung und Konsistenz. Die gemeinsame Verantwortung für das Produkt rückt in den Vordergrund. Agile Methoden allein reichen dafür jedoch nicht aus. Stand-ups, Sprints und Backlogs schaffen zwar den organisatorischen Rahmen, lösen aber nicht automatisch die inhaltlichen und kommunikativen Brüche zwischen Entwurf und Code. Erforderlich sind vielmehr gemeinsame Artefakte, die von beiden Disziplinen gleichermaßen verstanden und genutzt werden können, sowie eine gemeinsame Sprache, die fachliche, gestalterische und technische Aspekte verbindet. Genau an dieser Stelle gewinnen Werkzeuge an Bedeutung, die beide Welten adressieren und miteinander verzahnen. Sie fungieren als verbindende Ebene, auf der Konzepte, visuelle Gestaltung und technische Struktur nicht nebeneinander existieren, sondern sich gegenseitig bedingen und weiterentwickeln. In diesem Zusammenspiel entsteht die Grundlage für konsistente, wartbare und qualitativ hochwertige digitale Produkte.

Figma als Werkzeug zwischen Entwurf und Code

Der Dev Mode von Figma markiert einen entscheidenden Schritt vom klassischen „Inspect“-Werkzeug hin zu einer eigenständigen, entwicklerzentrierten Arbeitsumgebung. Er bündelt Funktionen, die Entwickler bislang über mehrere Tools, Plug-ins und Kommunikationskanäle hinweg nutzen mussten, in einer fokussierten Ansicht. Visuelle Ablenkungen aus dem Designprozess werden bewusst reduziert, während freigegebene Frames explizit als „Ready for Dev“ gekennzeichnet sind. Damit wird unmissverständlich signalisiert, welche Artefakte stabil, geprüft und für die Umsetzung vorgesehen sind.

Innerhalb der Inspektionsansicht erhalten Entwickler präzise, konsistente und reproduzierbare Informationen zu Abmessungen, Abständen, Typografie und Farbwerten. Diese Informationen liegen nicht mehr implizit in Layouts verborgen, sondern werden explizit und maschinenlesbar bereitgestellt. Ergänzt wird dies durch direkt nutzbare Code-Snippets für CSS, iOS (Swift) und Android XML sowie durch den unmittelbaren Export von Assets wie SVG oder PNG aus derselben Oberfläche. Entscheidend ist dabei die Tatsache, dass Designentscheidungen in klar strukturierte Parameter übersetzt werden, die sich technisch weiterverarbeiten lassen.

Ein weiterer zentraler Aspekt ist die Versionierbarkeit von Designänderungen. Der Dev Mode ermöglicht Diffs auf Frame-Ebene, die sowohl visuelle als auch codebezogene Unterschiede zwischen Versionen sichtbar machen. Änderungen an Abständen, Farben oder Typografie bleiben damit nachvollziehbar und überprüfbar. Für Entwicklungsteams bedeutet das deutlich weniger informelle Übersetzungsarbeit. Statt mit Screenshots, Kommentaren oder mündlichen Erläuterungen arbeitet die Entwicklung mit expliziten Werten, klaren Statusangaben und überprüfbaren Änderungen. Figma positioniert den Dev Mode damit bewusst als „credible developer workspace“ und nicht mehr nur als unterstützende Erweiterung für Designer.

Für .NET-Teams, die primär mit XAML und C# arbeiten, sind die bereitgestellten Code-Snippets eher als Orientierung denn als direkt einsetzbarer Code zu verstehen. Der eigentliche Mehrwert liegt jedoch nicht in der Code-Generierung, sondern in der Spezifikation von Layout, Typo­grafie und semantischer Struktur. Design Tokens, Variablen und klar definierte Zustände schaffen eine belastbare Grund­lage, auf der sich UI-Schichten in WPF, WinUI, MAUI oder Blazor konsistent umsetzen lassen. Statusmarkierungen wie „Ready for Dev“ oder „Needs review“ in Kombination mit nachvollziehbaren Diffs schaffen Transparenz und reduzieren Abstimmungsschleifen. Integrationen mit Entwicklungswerkzeugen wie VS Code oder Storybook in webnahen Stacks verstärken diese Kopplung zusätzlich und fördern einen kontinuierlichen Dialog zwischen Design und Implementierung.

Mit Code Connect und Figma Make geht das Figma-Ökosystem noch einen Schritt weiter. Anstatt pauschal Code aus Designs zu generieren, werden Figma-Komponenten direkt mit real existierenden Code-Komponenten aus der Code­basis verknüpft. Design und Code referenzieren sich gegenseitig. Figma Make ermöglicht es beispielsweise, HTML, CSS und JavaScript aus Frames zu erzeugen und diese im selben Workflow zu verfeinern, zu testen und weiterzuentwickeln. Der Fokus liegt dabei nicht auf automatisierter Vollständigkeit, sondern auf kontrollierter Annäherung zwischen Entwurf und Implementierung.

Dieses Prinzip lässt sich gut auf das .NET-Umfeld übertragen. Layout und visuelle Variablen verbleiben bewusst in Figma, während eine Zuordnungsschicht definiert, welche Figma-Komponenten welchen XAML-UserControls, DataTemplates oder Views entsprechen. Dev Mode und ergänzende Plug-ins liefern die notwendigen Parameter wie Abstände, Zustände oder Design Tokens, und das in strukturierter, maschinenlesbarer Form. Die eigentliche Implementierung bleibt dabei fest in der Hand der Entwickler und folgt den ­architektonischen Leitlinien des jeweiligen Projekts.

Figma wird zur Architektur-Beschreibungssprache für UI-Schichten. Nicht im Sinne eines automatisch generierten, schwer wartbaren Codes, sondern als präzise, versionierte und für alle Beteiligten verständliche Spezifikation. Das Ergebnis ist keine Entkopplung von Design und Code, sondern eine neue Form der Verbindlichkeit und damit eine robustere Grundlage für konsistente, langlebige Benutzeroberflächen.

Designsysteme als fachliche und technische Grundlage

Designsysteme bilden das Rückgrat einer integrierten UX-Dev-Zusammenarbeit. Sie schaffen die fachliche und technische Grundlage für konsistente Benutzeroberflächen, wiederverwendbare Komponenten und nachvollziehbare Designentscheidungen. Figma hat sich dabei in den vergangenen Jahren etabliert, um Designsysteme aufzubauen und zu dokumentieren. Zentrale Funktionen von Figma unterstützen den systemischen Ansatz:

• Komponenten und Instanzen: Wiederverwendbare Bausteine (Buttons, Inputs, Layout-Container). Änderungen am Master spiegeln sich in allen Instanzen wider und garantieren Konsistenz.
• Varianten: Zustände (hover, disabled, error), Größen und Ausprägungen werden als ein einziges Komponenten-Set organisiert. Das ist nahezu perfekt zum Beispiel für .NET-Controls mit mehreren VisualStates.
• Shared Libraries: Komponenten und Styles werden als Team-Bibliotheken veröffentlicht und über Projekte hinweg wiederverwendet. Updates werden auf verknüpfte Dateien propagiert.
• Auto Layout: Definiert flexibles, responsives Verhalten direkt im Design, analog zu Stack Panels, Grids und Flexlayouts.

Gerade im .NET-Kontext zeigt sich eine bemerkenswerte ­inhaltliche Nähe zwischen diesen Designkonzepten und ­eta­blierten UI-Mustern. Figma-Komponenten lassen sich gedanklich nahezu eins zu eins auf User Controls, Custom Controls oder Data Templates abbilden. Varianten entsprechen Visual States, Triggern oder stilistischen Ausprägungen innerhalb von Styles. Shared Libraries finden ihr technisches Pendant in gemeinsamen UI-Assemblies oder NuGet-basierten UI-Kits, während Auto Layout dem Verhalten responsiver Panels wie einem Grid oder einem Stack Layout sehr nahe kommt. Diese konzeptionelle Kompatibilität erleichtert nicht nur die Kommunikation zwischen Design und Entwicklung, sondern senkt auch die Hürde, Designsysteme tatsächlich konsequent in Code zu überführen.

Eine zentrale Rolle spielen dabei Design Tokens. Sie fassen wiederkehrende Gestaltungswerte wie Farben, Abstände, Typografie, Radien oder Schatten in plattformneutralen, maschinenlesbaren Einheiten zusammen. Üblicherweise werden sie in JSON-Strukturen definiert und anschließend für die unterschiedliche Zielplattformen, etwa nach CSS (Web), iOS, Android oder XAML, transformiert. Mit den Figma Variables stehen diese Tokens direkt im Designwerkzeug zur Verfügung. Unterschiedliche Variablentypen wie Farbe, Zahl, String oder Boolean erlauben es, Farben, Maße, Text­inhalte oder Sichtbarkeiten systematisch zu modellieren. Variablen unterstützen zudem mehrere Modi beziehungsweise Themen innerhalb einer einzigen Definition, etwa für Light- und Dark-Mode oder unterschiedliche Markenauftritte.

Besonders relevant ist die Möglichkeit, semantische und komponentenspezifische Ebenen abzubilden. Aus einem primitiven Token wie color/brand/primary/500 entsteht so eine gezielt verwendete Variable wie button/primary/background. Figma beschreibt hierfür explizit drei Token-Ebenen:

• primitive Tokens als Beschreibung des „Was“,
• semantische Tokens als Beschreibung des „Wie“,
• komponentenspezifische Tokens als Beschreibung des „Wo“.

Best Practices empfehlen eine strikt hierarchische Namenskonvention, klar definierte Governance- und Migrations­regeln für Änderungen sowie eine bewusste Kombination aus Variablen und Styles für komplexere Anwendungsfälle. Auf diese Weise bleibt das System auch bei wachsender Komplexität beherrschbar. Plug-ins wie Tokens Studio for Figma erweitern diesen Ansatz, indem sie die Verwaltung der Tokens in einer zentralen JSON-Quelle ermöglichen, die Synchronisation mit Figma-Variablen und -Styles sicherstellen und den Export in unterschiedliche Zielformate wie Web, iOS, Android oder weitere Plattformen unterstützen. Für .NET-Stacks liegt es nahe, denselben Token-Satz in eine XAML-Resource-Dictionary-Datei oder in eine generierte C#-Klasse zu überführen – etwa in Form von DesignTokens.Button.Primary.Background. Auf diese Weise bleibt die semantische Bedeutung der Tokens zwischen Figma und Code kohärent. Designentscheidungen sind nicht nur visuell nachvollziehbar, sondern lassen sich direkt in der Implementierung wiedererkennen und systematisch weiterentwickeln.

Figma im .NET-Umfeld: Von XAML bis Uno Platform

Auch im .NET-Umfeld gewinnt Figma als verbindendes Element zwischen Entwurf und Implementierung zunehmend an Bedeutung. Besonders deutlich wird dies am Beispiel der Uno Platform, die einen der derzeit umfassendsten Design-to-Code-Workflows rund um Figma aufgebaut hat. Ziel dieses Ansatzes ist es, den Übergang von Design zu lauffähigem .NET-Code nicht nur zu erleichtern, sondern strukturell zu ­integrieren, das heißt mit einem direkten Fokus auf XAML, C# und plattformübergreifende UI-Entwicklung.

Zentrale Bausteine dieses Workflows sind das Uno Platform Figma Plugin und das Uno-Material-Toolkit. Mit dem Plug-in lassen sich Figma-Screens per Klick in XAML- oder C#-Markup exportieren, einschließlich Farben, Schriftarten, Styles und sogar Lokalisierungsdateien. Das Material-Toolkit stellt ein umfangreiches Figma-UI-Kit bereit, das vorgefertigte Komponenten, Seiten und Layouts nach den Material-Design-Richtlinien enthält und explizit auf die Generierung für Uno und XAML optimiert ist. Ergänzt wird dieser Ansatz durch einen Previewer, der eine interaktive Live-Vorschau des generierten Codes ermöglicht. Designer können damit das Verhalten der Oberflächen wie in einer laufenden Anwendung testen, ohne Figma verlassen zu müssen.

Im typischen Ablauf bauen Designer ihre Screens in Figma auf Basis des Uno-Material-Toolkits aus vordefinierten Komponenten auf. Anschließend wird über das Uno-Plug-in XAML- oder C#-Markup inklusive Theme-Resource-Dictionaries generiert. Dieses Ergebnis dient den Entwicklern in Visual Studio als Ausgangspunkt, der gezielt um ViewModels, Geschäftslogik, Validierungen und Tests ergänzt wird. Der Workflow adressiert damit zentrale Hand-off-Pro­bleme klassischer UI-Entwicklung: Layouts und Komponenten-Hierarchien werden weitgehend eins zu eins in XAML abgebildet, eine hohe Pixelgenauigkeit zwischen Figma-Entwurf und finalem UI wird sichergestellt und ein erheblicher Teil manueller Fleißarbeit für Standard-Layouts entfällt. Erfahrungen aus Uno-Projekten zeigen, dass sich Abstimmungszyklen dadurch deutlich verkürzen und frühzeitig lauffähige Prototypen für Stakeholder, Usability-Tests und technische Validierung zur Verfügung stehen. Die Iterationsgeschwindigkeit steigt spürbar, ohne dass die Kontrolle über Architektur und Codequalität verloren geht.

Auch jenseits der Uno Platform wächst das Ökosystem an Brücken zwischen Figma und weiteren UI-Bibliotheken kontinuierlich. Es gibt ein Figma-UI-Kit für Windows UI-Komponenten, das exakt auf Microsofts UI-Stack abgestimmt ist und eine visuelle Eins-zu-eins-Abbildung zwischen Figma-Komponenten und WinUI-Komponenten ermöglicht. Ergänzend bieten Anbieter wie Telerik oder Kendo UI eigene Figma-Kits an, deren erklärtes Ziel ein „pixel-perfect hand­over“ und eine strukturelle Angleichung an die jeweiligen Implementierungsbibliotheken ist.

Figma wird zunehmend zum funktionalen Gegenstück der Codebasis auf der visuellen Ebene. Entwurf, Designsystem und Implementierung stehen nicht länger in einem hierarchischen Verhältnis, sondern bilden gemeinsam ein konsistentes, versioniertes System. Für .NET-Teams eröffnet sich dadurch die Chance, UX-Qualität, technische Robustheit und Entwicklungsgeschwindigkeit nicht gegeneinander auszuspielen, sondern systematisch miteinander zu verbinden.

Gemeinsames Verständnis von UX, UI und Implementierung

Wichtig ist eine gemeinsame Sprache zwischen Design- und Entwicklungswelt, weil viele Reibungsverluste genau an dieser Schnittstelle entstehen. Typische Stolperfallen sind zum Beispiel Farbnamen, die in Figma und im Code unterschiedlich benannt werden, Layout-Begriffe wie „Card“ oder „Feature Call­out“, die im Code ganz anders modelliert sind, oder Zustände, die im Design sauber dekliniert wurden, sich aber in den ViewModels nicht wiederfinden und damit faktisch nie implementiert werden. Empfohlen wird daher, Figma-Variablen und Code-Tokens konsequent mit identischen Namen zu führen, Layer und Frames in Figma semantisch statt generisch zu benennen, etwa OrderList.Item.Row statt Frame 123, und Komponenten-Hierarchien im Design so zu schneiden, dass sie später direkt als User Control, Data Template oder View in der Implementierung wiederverwendet werden können.

Ein aufgeräumtes Figma-File ist für die Entwicklerseite ebenso kritisch wie sauberer Code für UX-Teams, weil es ­direkt beeinflusst, wie schnell und fehlerarm sich Designs in Implementierung übersetzen lassen. Empfehlenswert für einen guten Hand-off ist, überflüssige Ebenen zu entfernen, Layout-Raster, Abstände und Responsivität klar zu dokumentieren und Anmerkungen sowie Spezialfälle sichtbar – etwa im Dev-orientierten Modus – hervorzuheben, damit Entwickler alle relevanten Informationen im Kontext des jeweiligen Elements finden. Für .NET-Teams lohnt es sich darüber ­hi­naus, Komponenten, die später eigene Views werden, in separaten Frames oder Pages zu organisieren, Bindungspunkte wie Platzhalter für dynamische Inhalte eindeutig zu markieren und Datenzustände wie Empty, Loading oder Error entweder als Varianten einer Komponente oder als eigene Frames abzubilden, sodass sie in XAML, ViewModels und Tests gezielt und nachvollziehbar umgesetzt werden können.

Damit UX-Entscheidungen nicht auf der Strecke bleiben, sollten sie im .NET-Code explizit nachvollziehbar und strukturell verankert sein. Dazu gehören ViewModels, die Zu­stände klar und typisiert modellieren, anstatt lediglich mit ein­zelnen Bool-Flags zu arbeiten, XAML-Styles und Control-Templates, die auf denselben Tokens und Variablen basieren wie in Figma definiert, sowie automatisierte UI-Tests, die konkrete Interaktionsmuster und Zustandswechsel überprüfen, nicht nur Pixel oder statische Snapshots. Figma-Design­systeme mit klar benannten Tokens, konsistenten Komponenten und eindeutig beschriebenen States erleichtern diese Abbildung erheblich, weil sie eine direkte, semantisch stimmige Brücke zwischen Designentscheidungen und der technischen Implementierung im .NET-Stack bereitstellen.

Reduktion von Medienbrüchen und Missverständnissen

Die Eliminierung von Medienbrüchen ist ein zentrales Qualitäts- und Effizienzthema. Figma-gestützte Workflows adressieren das auf mehreren Ebenen:

• Zugriff: Entwickler haben direkten Lesezugriff auf das originale Figma-File – keine abgeleiteten Screenshots mehr.
• Inspektion: Metriken, Styles, Assets und Tokens werden an einer Stelle gepflegt und sind im Dev Mode transparent.
• Änderungsdiffs: Unterschiedliche Fassungen von Screens sind über Version History und visuelle Diffs nachvollziehbar.
• Kommentare: Rückfragen werden im Kontext des betroffenen Elements geführt statt in Ticketsystemen ohne visuelle Referenz.
• Automatisierte Code-Generierung: Wo sinnvoll, reduziert generierter Code aus Figma zum Beispiel via Uno Interpretationsfehler und Copy-and-Paste-Fehler.

Figma selbst spricht von „tidy, well-prepared files“ als Basis dafür, Entwicklern „all the information they need“ bereitzustellen, inklusive expliziter Spacing-Information, Responsivitäts-Hinweisen und Annotationen für Sonderfälle.

Für .NET-Teams bedeutet dieser Ansatz ganz konkret eine Abkehr von traditionellen Arbeitsweisen, bei denen Design-PDFs oder statische Styleguides als maßgebliche Referenz dienten. Stattdessen rückt Figma als lebende, kontinuierlich gepflegte Quelle in den Mittelpunkt. Designsysteme, Komponenten, Tokens und Zustände sind dort nicht nur dokumentiert, sondern aktiv in Nutzung und Entwicklung eingebunden. Für die Implementierung wird Figma damit zum gemeinsamen Arbeitsraum, in dem Design und Entwicklung denselben aktuellen Stand teilen.

Damit diese Rolle wirksam wird, braucht es eine verbindliche Vereinbarung im Team, dass UI-Änderungen grundsätzlich ihren Ursprung im Figma-File haben. Anpassungen an Layout, Farben, Abständen oder Komponentenvarianten werden zuerst im Designsystem vorgenommen und anschließend in die Implementierung überführt – nicht umgekehrt. Dieser scheinbar strikte Grundsatz verhindert schleichende Abweichungen zwischen Entwurf und Code und sorgt dafür, dass Designentscheidungen sichtbar, nachvollziehbar und diskutierbar bleiben. Technische Sonderfälle oder notwendige Abweichungen werden so nicht stillschweigend im Code verankert, sondern fließen bewusst zurück ins Designsystem und stehen damit allen Beteiligten zur Verfügung.

Ergänzend dazu empfiehlt es sich, die Definition of Done in der Entwicklung um UX- und Design-bezogene Kriterien zu erweitern. Neben funktionalen und technischen Aspekten wird damit explizit überprüft, ob die Implementierung mit dem aktuellen Figma-File abgeglichen wurde und ob Design Tokens, Variablen und Komponenten konsistent verwendet werden. Diese Verankerung im Entwicklungsprozess macht UX-Qualität zu einem überprüfbaren Bestandteil der Lieferfähigkeit und nicht zu einem nachgelagerten Korrekturfaktor. Auf diese Weise wird Figma nicht nur als Werkzeug akzeptiert, sondern als integraler Bestandteil der .NET-Entwicklung etabliert. Das hat einen direkten Einfluss auf Qualität, Konsistenz und Wartbarkeit der Benutzeroberflächen.

Tools an der Schnittstelle von Kreativität und Technik

Der systemorientierte Ansatz zeigt sich insbesondere in der Art, wie Figma Design nicht als Sammlung einzelner Screens versteht, sondern als konsistentes System aus Komponenten, Varianten und Tokens. Diese Struktur entspricht in vielerlei Hinsicht den Denkmodellen moderner Softwareentwicklung. Wiederverwendung, klare Zuständigkeiten und kontrollierte Änderungen sind ebenso zentrale Prinzipien im Code wie im Designsystem. Werkzeuge an dieser Schnittstelle schaffen damit eine gemeinsame methodische Basis, auf der Kreativität und technische Stabilität nicht im Widerspruch stehen, sondern sich gegenseitig stützen.

Anschlussfähigkeit an Entwicklung bedeutet, dass Designartefakte nicht isoliert bleiben. Informationen zu Layout, Typografie, Abständen oder Zuständen lassen sich explizit auslesen, versionieren und in technische Strukturen überführen. Für Entwicklungsteams reduziert das Interpretationsspielräume und macht Designentscheidungen überprüfbar. Gleichzeitig bleibt die kreative Freiheit erhalten, weil das Werkzeug nicht vorgibt, wie etwas implementiert werden muss, sondern lediglich beschreibt, was fachlich und gestalterisch gemeint ist.

Dabei geht es ausdrücklich nicht darum, Design vollständig zu automatisieren oder Entwicklung zu vereinfachen. Weder lassen sich gute UX-Entscheidungen generieren noch komplexe Architekturen durch Tools ersetzen. Der eigentliche Mehrwert liegt darin, gemeinsame Verantwortung für das Produkt zu etablieren. Werkzeuge wie Figma machen sichtbar, dass UX, UI und Implementierung keine konkurrierenden Perspek­tiven sind, sondern unterschiedliche Blickwinkel auf dasselbe Ziel. Wenn Kreativität und Technik auf einer gemeinsamen Plattform zusammenfinden, entsteht nicht nur eine effizientere Zusammenarbeit, sondern auch eine höhere Qualität digitaler Produkte – fachlich, gestalterisch und technisch zugleich.

Ein Blick in Figma

Nun sehen wir uns die Funk­tio­nen und Teile der Software Figma an konkreten Beispielen an. Im Mittelpunkt steht Figma Make. Es handelt sich dabei um eine KI-gestützte Erweiterung innerhalb des Figma-Ökosystems, die da­rauf abzielt, den Prozess von der ersten Idee bis zu interaktiven Prototypen deutlich zu beschleunigen und zu vereinfachen. Anstatt Benutzeroberflächen ausschließlich manuell zu entwerfen, ermöglicht Figma Make die Generierung von Layouts, Komponenten und Interaktionen auf Basis natürlicher Sprache. Nutzer können Anforderungen in Form von Textprompts formulieren, etwa zur Struktur eines Screens, zu enthaltenen UI-Elementen oder zu funktionalen Zuständen. Die KI übersetzt diese Beschreibungen in visuelle, vollständig editierbare Figma-Objekte, die Auto-Layout-Regeln, sinnvolle Abstände sowie konsistente Typografie und Farbverwendung berücksichtigen. Naviga­tionsflüsse, Button-Aktionen, Hover-Effekte oder Zustandswechsel werden ohne manuelles Verknüpfen angelegt. Dabei erkennt das System typische UI-Muster und verbindet Screens logisch miteinander, sodass realistische Nutzerflüsse entstehen. Auch komplexere Zustände wie Ladeanzeigen, Fehlermeldungen oder Erfolgsmeldungen lassen sich auf ­diese Weise simulieren. Ergänzend dazu unterstützt Figma Make grundlegende Logik- und Datenkonzepte, etwa durch die Darstellung dynamischer Listen, Platzhalterdaten, Filtermechanismen oder einfache Formularvalidierungen. Diese Funktionen führen dazu, dass Prototypen nicht nur visuell überzeugen, sondern auch funktional näher an realen Anwendungen liegen.

Bestehende Designs können über weitere Prompt-Interaktionen gezielt angepasst oder verfeinert werden, ohne dass eine Neuerstellung erforderlich ist. Änderungswünsche wie Layoutanpassungen, alternative Farbkonzepte oder strukturelle Erweiterungen werden kontextsensitiv umgesetzt und in das vorhandene Design integriert. Dadurch entsteht ein kontinuierlicher, konversationeller Designprozess. Figma Make ist in der Lage, vorhandene Designsysteme zu berücksichtigen. Definierte Farben, Schriftstile, Komponenten und Layoutregeln werden bei der Generierung und Anpassung einbezogen, was eine konsistente Gestaltung sicherstellt.

Die in Figma Make generierten Strukturen sind klar organisiert, Auto-Layout-fähig und entwicklerfreundlich aufgebaut. Ebenenhierarchien, Benennungen und Komponentenstrukturen sind nachvollziehbar, wodurch die Übergabe an Entwickler vereinfacht und Missverständnisse reduziert werden.

Nachfolgend probieren wir die Funktionen von Figma Make aus. Die Idee ist, eine Stadtführungs-App zu erstellen, die eine Stadt aus der Perspektive ihrer Menschen zeigt. Statt klassischer Sehenswürdigkeiten führen kuratierte Spaziergänge durch vergessene Orte und zu persönlichen Geschichten aus Alltag, Migration, Teilung und Wandel. GPS-basierte Audio-Stories begleiten Nutzer:innen auf verschiedenen Routen und machen Geschichte dort erlebbar, wo sie passiert ist – leise, nah und authentisch. Zielgruppe sind Städtereisende, die keine klassische Tour wollen; Stadtbewohner, die ihre Stadt neu sehen möchten; Schulen und Bildungseinrichtungen sowie Menschen mit Interesse an Geschichte und Gesellschaft.

Ausgangspunkt war eine kurze Beschreibung der gewünschten Anwendung, inklusive Zielgruppe, thematischem Fokus und zentralen Funktionen. Diese Beschreibung wurde im linken Prompt-Bereich eingegeben und schrittweise ergänzt. Auf Grundlage dieser Eingaben hat Figma Make automatisch mehrere zusammenhängende App-Screens verschiedener Formate generiert. Dazu zählen eine Start- und Übersichtsseite mit App-Titel und Claim, eine Filterfunktion zur thematischen Eingrenzung der Inhalte sowie eine kartenbasierte Darstellung einzelner Routen in Form von Cards. Jede Route wurde mit Bild, Titel, thematischer Zuordnung, Kurzbeschreibung sowie Metadaten wie Dauer, Strecke und Schwierigkeitsgrad versehen. Im weiteren Verlauf wurden Anpassungen iterativ vorgenommen, ohne die bestehende Struktur neu aufzubauen. Änderungen an Inhalten, Filtern und Layout wurden dialogbasiert formuliert und direkt im bestehenden Design umgesetzt. Figma Make hat dabei nicht nur Platzhalter erzeugt, sondern konsistente Texte sowie realistische Bildmotive erstellt und eine visuell ausgearbeitete Hierarchie verwendet. Das Ergebnis ist ein durchgängiger, interaktiver UI-Prototyp, der funktionale Aspekte wie Navigation, Filterung und inhaltliche Struktur abbildet und sich für Konzeptvalidierung, UX-Diskussionen oder Präsentationen eignet (Bild 3).

Auf Basis der beschriebenen App-Idee hat Figma Make auto­matisch ein Projekt mit klarer Ordner- und Dateistruktur angelegt (Bild 4). Diese umfasst unter anderem Komponenten, Seiten, Routing-Dateien, Datenmodelle sowie Konfigurationsdateien für Build- und Styling-Prozesse. Innerhalb der Anwendung wurden konkrete React-/TypeScript-Dateien erstellt, etwa für die Startseite, Detailansichten einzelner Routen und einen Tour-Modus. Die Screens sind nicht statisch, sondern enthalten Zustandslogik, zum Beispiel zur Filterung von Routen nach Themen. Diese Logik wird über State-­Variablen umgesetzt und dynamisch auf die dargestellten ­In­halte angewendet. Nutzer:innen können entweder ohne visuelle Vorlage ausschließlich mit einem textbasierten Prompt beginnen, oder sie greifen auf bereits vorhandene Entwürfe zurück. Bestehende Figma-Frames oder -Komponenten lassen sich direkt in den Make-Chat übernehmen oder hochladen und dienen der KI als visueller Ausgangspunkt. So kann beispielsweise ein zuvor in Figma Design erstellter Wire­frame an Make übergeben werden, der anschließend in einen detailreichen, interaktiven Prototyp überführt wird. Auch Bilddateien wie handgezeichnete Skizzen oder Screenshots können als Referenz eingebunden werden. Unabhängig vom Einstieg bleibt die natürliche Sprache das zentrale Steuerungsinstrument. Über dialogartige Eingaben werden Funktionen, Layoutanpassungen oder Interaktionen beschrieben, die von der KI unmittelbar umgesetzt werden. Dieser kon­versationelle Ansatz ermöglicht es, auch ohne tiefgehende Figma-Kenntnisse komplexe Prototypen zu erstellen.

Darüber hinaus unterstützt Figma Make die Einbindung unternehmensspezifischer Designsysteme. Styles und Komponenten aus der Figma-Bibliothek lassen sich als Kontext hinzufügen, wodurch die KI automatisch Farben, Typografie und UI-Elemente gemäß den bestehenden Designvorgaben anwendet. Auf diese Weise bleibt der Prototyp konsistent im Look and Feel der Marke, während manueller Anpassungsaufwand reduziert wird.

Figma Make erzeugt hinter den Kulissen einen echten ausführbaren Code für die UI-Komponenten, inklusive Layout, Typografie, Icons und Farbschemata. Die Gestaltung erfolgt konsistent über Utility-Klassen und wiederverwendbare Komponenten. Texte, Kategorien und Routendaten werden aus separaten Datenquellen eingebunden, wodurch eine Trennung von Darstellung und Inhalt erkennbar ist. Figma Make fungiert damit nicht nur als Design-, sondern als Code-generierendes Prototyping-Werkzeug. Das ist eine zentrale Voraussetzung dafür, dass die entstehenden Prototypen nicht nur visuelle Mockups bleiben, sondern tatsächlich lauffähig sind. Gleichzeitig eröffnet dieser Ansatz neue Möglichkeiten für die Weiterentwicklung über die reine Designphase hi­naus. Sobald ein Prototyp generiert wurde, können Entwickler ­unmittelbar eingreifen: Im Vorschau-Panel steht ein Code-Inspector beziehungsweise Editor zur Verfügung, in dem sich der erzeugte Code live einsehen und anpassen lässt. In der Ausgangsversion generiert Figma Make eine webbasierte App auf der Basis von TypeScript und der Bibliothek React.

Das ist ein interessantes Zwischenergebnis, jedoch noch nicht das von uns angestrebte Ziel. Wir wollen mit Figma entwerfen, generieren (KI) und designen und dann nach .NET (Uno) exportieren, das heißt in XAML- beziehungsweise C#-Code. Dazu ist es notwendig, das Uno-Plug-in in Figma zu ­installieren (Bild 5). Die kostenfreie Version des Plug-ins beinhaltet zehn Exporte – für einen ersten Test ausreichend. Wir kopieren dazu beispielsweise einen Designentwurf in ein neues Projekt in Figma mit Uno-Export, können dann den Root-Frame der betreffenden Seite auswählen (Bild 6) und den Export in XAML-Code durchführen (Bild 7).

Fazit und Ausblick

Der Beitrag zeigt, dass sich die Grenzen zwischen UX-Design, UI-Systemen und technischer Implementierung zunehmend auflösen und integrierte Design-Dev-Workflows zum neuen Standard moderner Softwareentwicklung werden. Figma entwickelt sich dabei von einem reinen Entwurfswerkzeug zu ­einer verbindenden Plattform, die Spezifikation, Kollaboration und teilweise auch Code-Generierung vereint. Besonders im .NET-Umfeld eröffnen Design Tokens, Dev Mode und Werkzeuge wie Uno neue Möglichkeiten für konsistente, wartbare und schnell iterierbare Benutzeroberflächen. Entscheidend bleibt jedoch, dass Automatisierung kreative Gestaltung und architektonische Verantwortung nicht ersetzt, sondern diese lediglich unterstützt werden. Zukünftig werden KI-gestützte Funktionen, konversationelles Prototyping und engere Design-Code-Kopplung die Zusammenarbeit weiter verändern. Damit rückt ein gemeinsames, systemisches Verständnis von Produktentwicklung in den Mittelpunkt. Teams, die diese Integration aktiv gestalten, können Qualität, Effizienz und Nutzerorientierung gleichermaßen steigern.