Figma deckt im UI/UX-Design die Strecke von der ersten Skizze bis zur Entwickler-Übergabe ab: Wireframes, Komponentenbibliothek, klickbarer Prototyp und Kommentare in derselben Datei. Die Frage hinter „figma ui ux design" ist für Auftraggeber trotzdem selten, ob das Werkzeug taugt — sondern ob die fertige Datei ohne dreißig Rückfragen in Code übersetzbar ist. Das entscheidet sich an vier Dingen: Komponenten, Variablen, Zuständen und Breakpoints.
Was Figma im Prozess abdeckt — und wo der Prozess aus dem Werkzeug herausläuft
Figma ist browserbasiert und mehrbenutzerfähig; das Team arbeitet an einem einzigen, lebenden Stand statt an versionierten Exporten (figma.com). Für ein Web-App-Projekt heißt das konkret: Die Fachabteilung kommentiert im selben Dokument, aus dem die Entwicklung baut. Kein Screenshot in einer E-Mail, kein „welche PDF-Version war jetzt die letzte".
Die Grenze verläuft da, wo aus Bildern Verhalten wird. Ein Prototyp klickt sich durch acht handverlesene Beispieldatensätze. Die Anwendung muss eine Tabelle mit viertausend Zeilen, einen Timeout der Schnittstelle und einen Nutzer ohne Schreibrechte aushalten.
UI und UX: die Trennlinie wird im Dateiaufbau sichtbar
UX ist die Struktur — welche Schritte jemand geht, wann eine Entscheidung fällt, was passiert, wenn etwas schiefgeht. UI ist die Oberfläche, auf der diese Struktur sichtbar wird: Raster, Typografie, Farbe, Zustände von Bedienelementen. Figma ordnet UI in der eigenen Ressourcen-Bibliothek als Teilbereich von UX ein (Unterschied zwischen UI und UX).
Im Dateiaufbau sieht man das sofort. Eine Datei, die nur nach Screens sortiert ist, hat die UI-Ebene und keine UX-Ebene: Man sieht zwölf Bilder, aber nicht, welcher Weg sie verbindet. Die UX-Ebene steckt in den Prototyp-Verbindungen, in der Reihenfolge der Frames und vor allem in den Abzweigungen — Abbruch, Fehler, Rücksprung. Wenn diese Abzweigungen in der Datei fehlen, fehlen sie später auch im Angebot, weil niemand sie geschätzt hat.
Wo Figma aufhört
Vier Dinge kommen aus dem Werkzeug nicht heraus, egal wie sauber gearbeitet wurde: echte Nutzeraussagen, echte Datenmengen, gemessene Ladezeiten und die tatsächliche Tastatur- und Screenreader-Bedienbarkeit im Browser. Die ersten beiden gehören vor das Design, die letzten beiden in die Umsetzung. Wer Barrierefreiheit erst nach dem Design-Review anfasst, verschiebt Fokusreihenfolge und Kontraste rückwärts in fertige Komponenten — das ist die teuerste Reihenfolge.
Was eine unsaubere Figma-Datei in Entwicklungsstunden kostet
Dieselben zwölf Screens, zweimal übergeben: einmal als System aus Komponenten und Variablen, einmal als Sammlung kopierter Rahmen mit lokal überschriebenen Werten. Der sichtbare Unterschied ist gleich null — die Screens sehen identisch aus. Der Unterschied im Aufwand steckt in den Positionen, die niemand im Angebot separat ausweist.
Rechenbeispiel: 12 Screens, zwei Zustände derselben Datei
| Position | Saubere Datei | Unsaubere Datei |
|---|---|---|
| Abstände und Typo-Skala ableiten | 3 h | 8 h |
| Farb- und Typo-Tokens anlegen | 4 h | 7 h |
| 12 Basis-Komponenten bauen | 14 h | 18 h |
| Responsives Verhalten, 3 Breakpoints | 5 h | 9 h |
| Zustände nachziehen | 6 h | 9 h |
| Icons und Assets exportieren | 2 h | 3 h |
| Rückfragen und Freigabeschleifen | 4 h | 9 h |
| Nachbesserung nach Design-Review | 3 h | 5 h |
| Summe | 41 h | 68 h |
27 Stunden Differenz, rund zwei Drittel Aufschlag — für dasselbe sichtbare Ergebnis. Die Zahlen sind mein Kalkulationsmodell aus eigenen Web-App-Projekten, kein Branchen-Benchmark; die Größenordnung verschiebt sich mit Team, Stack und Komplexität. Interessant ist weniger die Summe als die Verteilung: Der größte relative Sprung liegt nicht im Bauen, sondern in den Rückfragen. Eine unsaubere Datei erzeugt keine schwierige Arbeit, sie erzeugt Warteschleifen.
Die Drei-Klick-Probe vor dem Angebot
Vor jeder Festpreis-Schätzung mache ich denselben Test: drei Buttons in drei verschiedenen Screens anklicken und prüfen, ob alle drei dieselbe Hauptkomponente referenzieren. Tun sie es nicht, ist die Datei eine Zeichnung, kein System — und jede Farbänderung später ein manueller Durchlauf durch zwölf Screens.
Dasselbe funktioniert mit Abständen: drei Karten, drei Innenabstände. Wenn dort 16, 16 und 18 Pixel stehen, gibt es keine Skala, sondern Augenmaß. Beides ist reparierbar, kostet aber Zeit, die in die Schätzung gehört und nicht in die Überraschung.
Übergabe-Score: sieben Kriterien, maximal 14 Punkte
Jedes Kriterium bekommt 0 Punkte (fehlt), 1 Punkt (teilweise) oder 2 Punkte (durchgängig):
- Auto Layout — Rahmen, die ihre Kinder automatisch anordnen und mitwachsen; ohne das ist jede Textlänge über der Vorlage ein Bruch.
- Komponenten mit Varianten statt kopierter Kästen: ein Button mit Zuständen und Größen als eine Definition.
- Variablen für Farbe, Abstand und Typo, benannt nach Funktion (`surface-elevated`), nicht nach Aussehen (`grau-3`).
- Breakpoints als eigene Frames, mindestens Mobil und Desktop, mit sichtbarem Umbruchverhalten.
- Zustände dokumentiert: leer, ladend, fehlerhaft, überlang.
- Konsistentes Namensschema, das Entwicklung und Design gleich lesen.
- Eine Wahrheit pro Screen — keine drei Varianten nebeneinander, von denen zwei tot sind.
Meine Schwelle: Ab 10 Punkten schätze ich einen Festpreis auf die Datei. Zwischen 7 und 9 Punkten kommt eine separate Position „Design-Aufräumen" ins Angebot, typischerweise ein bis zwei Tage. Unter 7 Punkten schätze ich nicht auf die Datei, sondern auf die Anforderung — sonst kalkuliere ich eine Fiktion.
Zustände sind die Arbeit, Screens sind nur die Ansicht
Zwölf Screens klingen nach zwölf Einheiten Arbeit. Implementiert werden aber Zustände, und die vermehren sich pro Screen. Für eine typische Web-App mit acht datengetriebenen Ansichten, fünf Listen und vier Formularen rechne ich so:
- 12 Grundzustände (je Screen einer)
- 8 Ladezustände für die datengetriebenen Ansichten
- 5 Leerzustände für Listen, die beim ersten Login immer leer sind
- 8 Fehlerzustände für ausgefallene oder langsame Schnittstellen
- 4 Overflow-Varianten für lange Namen, Titel und Adressen
- 4 rollenabhängige Varianten für Nutzer ohne Schreibrechte
Macht 41 zu bauende Zustände statt 12 Screens. Wenn im Design nur die 12 vorhanden sind, entwirft die Entwicklung die restlichen 29 — meistens auf Zuruf, oft samstags, in jedem Fall ohne Freigabe. Das ist der häufigste Grund, warum ein fertig aussehendes Design im Review durchfällt: nicht falsche Farben, sondern der leere Zustand, den niemand gezeichnet hat.
Der Leerzustand ist dabei der wichtigste, weil ihn jeder neue Nutzer als erstes sieht. Er trägt die Erklärung, den Startpunkt und den einzigen Button, der jetzt Sinn ergibt.
Variablen: der einzige Teil des Designs, der eins zu eins in Code wandert
Ein Design-Token ist ein benannter Wert für eine Gestaltungsentscheidung — eine Farbe, ein Abstand, ein Radius, eine Schriftgröße. In Figma sind das Variablen, im Frontend CSS-Custom-Properties oder Theme-Einträge im Tailwind-Config. Diese Zuordnung ist die einzige Stelle, an der Design und Code wirklich dieselbe Quelle benutzen; alles andere ist Nachbau nach Augenmaß.
Die Drei-Screens-Regel
Ein Wert, der in drei oder mehr Screens vorkommt, wird eine Variable. Ein Wert, der einmal vorkommt, bleibt lokal. Diese Regel hält die Token-Liste klein genug, dass sie jemand lesen kann, und groß genug, dass eine Markenänderung an einer Stelle passiert. Wer stattdessen jede Farbe der Datei zur Variable macht, hat 90 Tokens und wieder kein System.
Beim Benennen entscheidet die Funktion, nicht die Optik. `danger-fg` überlebt einen Rebrand, `rot-500` nicht — spätestens wenn Rot zu Orange wird, lügt der Name.
Wann sich ein eigenes Design-System nicht lohnt
Unter etwa 12 Screens und einer geplanten Laufzeit von weniger als sechs Monaten ist ein selbstgebautes Design-System für die meisten Projekte Verlustgeschäft: Die Investition amortisiert sich über Wiederverwendung, und die findet dort nicht statt. Sinnvoller sind dann eine fertige Komponentenbibliothek plus zehn bis fünfzehn eigene Tokens für Farbe und Typografie.
Umgekehrt gilt: Sobald zwei Anwendungen dieselbe Marke tragen oder mehr als eine Person am Frontend arbeitet, kippt die Rechnung. Ab da kostet das Fehlen des Systems mehr als sein Aufbau.
Design-Freeze im Oktober, Release im November
Wenn ein Release noch vor der Jahreswende stehen soll, ist der Design-Freeze der Punkt, an dem der Zeitplan hält oder kippt — nicht der Entwicklungsstart. Zwischen freigegebenem Design und lauffähiger Anwendung liegen bei den 41 Zuständen von oben nicht nur Bauzeit, sondern Freigabeschleifen, und die sind in Kalenderwochen zu rechnen, nicht in Stunden.
Meine Planungsannahme für Projekte, die im Oktober ins Bauen gehen: zwei Review-Runden à drei Werktage Rücklaufzeit, nicht eine à einem Tag. Urlaub, Krankheit und Jahresendgeschäft auf Auftraggeberseite verlängern genau diesen Block, nicht die Implementierung. Wer den Design-Freeze in den November schiebt, verschiebt damit faktisch das Release ins neue Jahr — auch wenn die Entwicklungsschätzung unverändert bleibt.
Praktisch heißt das: Übergabe-Score jetzt prüfen, Zustände jetzt zeichnen lassen, Tokens vor der ersten Komponente festlegen. Alles drei sind Design-Aufgaben und blockieren die Entwicklung nur, solange sie offen sind.
Häufige Fragen
Ist Figma ein UI/UX-Design-Tool?
Ja — Figma deckt Wireframing, UI-Gestaltung, Komponentenbibliotheken und interaktives Prototyping in einer browserbasierten Umgebung ab und positioniert sich selbst als kollaboratives UX-Werkzeug (figma.com). Welche Funktionen, etwa die Entwickleransicht, im jeweiligen Plan enthalten sind, steht auf der Produktseite von Figma; das ändert sich unabhängig von diesem Artikel und sollte dort geprüft werden.
Reicht Figma allein für UI/UX?
Für die Gestaltungs- und Übergabephase in den meisten Web-Projekten ja. Nicht abgedeckt sind Nutzerforschung mit echten Teilnehmern, Tests mit realen Datenmengen und die Messung von Ladezeiten oder Bedienbarkeit im fertigen Browser. Diese Schritte brauchen eigene Werkzeuge und eigene Zeit im Plan — Figma zeigt, wie es aussehen soll, nicht, wie es sich unter Last verhält.
Wie geht man UI/UX in Figma konkret an?
In dieser Reihenfolge: Flows und Abzweigungen klären, Tokens für Farbe, Abstand und Typo festlegen, dann Komponenten mit Varianten bauen, dann Screens daraus zusammensetzen, zuletzt Zustände und Breakpoints ergänzen. Figma beschreibt den zugrunde liegenden UX-Prozess von Recherche bis Test in der eigenen Ressourcen-Bibliothek (What is UX design?). Wer mit Screens statt mit Tokens anfängt, baut die Datei zweimal.
Ist Figma für Einsteiger geeignet?
Die Grundwerkzeuge sind an einem Tag benutzbar; die Konzepte, die eine Datei übergabefähig machen — Auto Layout, Varianten, Variablen — brauchen erfahrungsgemäß deutlich länger. Eine strukturierte Einordnung aus Sicht von UX-Designern liefert der Leitfaden von Designlab (The UX Designer's Guide to Figma). Für ein einmaliges Projekt ist die Frage ohnehin selten „selbst lernen oder nicht", sondern wer die Datei später pflegt.
Was ist der Unterschied zwischen UI- und UX-Design?
UX-Design legt Struktur, Abläufe und Entscheidungen fest, UI-Design die sichtbare Oberfläche mit Raster, Typografie, Farbe und Zuständen; Figma beschreibt UI als Teilbereich von UX (Unterschied zwischen UI und UX). Im Projektalltag ist der praktische Test simpel: Was passiert, wenn der Nutzer etwas falsch macht, ist UX. Wie diese Fehlermeldung aussieht, ist UI.