Wenn in einem Webprojekt mehrere Entwürfe nebeneinander entstehen, geht es selten nur um „schöner“ oder „moderner“. Oft sollen konkrete Fragen beantwortet werden: Welche Hierarchie funktioniert besser? Wird der Call-to-Action schneller gefunden? Passt die Lösung noch zu bestehenden Komponenten? Genau dafür sind Design-Varianten in Figma ideal – wenn sie sauber organisiert sind.
Das Problem: Varianten werden häufig „nebenbei“ angelegt. Dann gibt es Frames mit kryptischen Namen, doppelte Komponenten, abweichende Abstände und Diskussionen, die niemand mehr zuordnen kann. Mit einem klaren Vorgehen lassen sich Varianten dagegen wie kleine Experimente behandeln: übersichtlich, vergleichbar und später leicht in die beste Lösung überführbar.
Welche Varianten sich wirklich lohnen (und welche nicht)
Varianten mit klarer Fragestellung statt Bauchgefühl
Eine gute Variante beantwortet eine konkrete Frage. Beispiele aus dem Alltag:
- „Erkennen Nutzer den nächsten Schritt besser, wenn der Button oben statt unten steht?“
- „Funktioniert die Produktliste mit zwei Spalten besser als mit einer?“
- „Ist die Navigation verständlicher als Tabs oder als Dropdown?“
Ohne Frage entsteht schnell ein Sammelsurium an „Option A/B/C“, das niemand mehr begründen kann. Ein hilfreicher Trick: Die Frage in den Variantennamen aufnehmen (kurz, aber eindeutig).
Was eher keine eigene Variante braucht
Kleine, rein visuelle Mikroänderungen (z. B. „Ecke 6 px vs. 8 px“) lassen sich oft innerhalb derselben Komponente klären – oder später über einen Design-Review. Varianten sind am stärksten, wenn sich Layout, Struktur oder Inhalt messbar anders anfühlen.
Struktur im File: Frames, Seiten und Benennung, die später noch Sinn ergibt
Ein Ort für Experimente, ein Ort für „sauber“
Damit ein Figma-File nicht „ausfranst“, hilft eine simple Trennung:
- Variant-Frames liegen gesammelt auf einer Seite (z. B. „Exploration“ oder „Variants“).
- Freigegebene Lösungen (die weitergebaut werden) liegen auf einer separaten Seite (z. B. „Proposed“).
So bleibt klar: Hier wird ausprobiert, dort wird entschieden. Das wirkt banal, spart aber im Team enorm viele Rückfragen.
Benennung: kurz, standardisiert, durchsuchbar
Ein funktionierendes Schema nutzt drei Bausteine: Screen/Flow, Hypothese, Version. Beispiel:
- Checkout – CTA oben – v1
- Checkout – CTA unten – v1
- Checkout – Zusammenfassung rechts – v2
Wichtig ist, dass das Schema im Team identisch genutzt wird. „Final_final2“ hilft niemandem. Wer häufiger über Entscheidungen stolpert, kann zusätzlich das Datum nutzen, aber ohne endlose Ziffernketten.
Varianten vergleichen, ohne dass Layout und Inhalte auseinanderlaufen
Komponenten als Sicherheitsgeländer nutzen
Eine der häufigsten Ursachen für „Chaos“ sind Varianten, die mit losen Kopien gebaut werden. Dann ändern sich bei jeder Anpassung Texte, Padding (Innenabstand) oder Typografie – und plötzlich wird nicht mehr die Idee verglichen, sondern die Ausführung.
Besser: Die Variante wird aus denselben Komponenten aufgebaut, die auch in der späteren Lösung genutzt werden. Wenn Komponenten fehlen, lohnt es sich, sie vor dem Varianten-Test zu erstellen. Das zahlt auf Konsistenz ein und verkürzt spätere Nacharbeit.
Auto Layout so einsetzen, dass Varianten fair vergleichbar bleiben
Auto Layout bedeutet vereinfacht: Elemente ordnen sich automatisch, wenn Inhalt oder Größe sich ändert. Für Varianten ist das Gold wert, weil Layout-Regeln stabil bleiben, auch wenn Textlängen variieren.
Praktische Regeln:
- Texte in Buttons nie „von Hand“ zentrieren, sondern über Auto Layout.
- Listen (z. B. Features) immer als vertikale Auto-Layout-Gruppe anlegen.
- Komponenten mit festen Maximalbreiten arbeiten lassen, damit Varianten nicht zufällig „luftiger“ wirken.
Wer Auto Layout bereits für responsive Komponenten nutzt, kann vieles wiederverwenden. Passend dazu erklärt Figma Auto Layout meistern – flexible UI-Layouts mit System die Grundlagen und typische Fehlerbilder.
Text-Inhalte stabil halten: echte Copy oder bewusst neutral
Ein fairer Vergleich braucht gleiche Voraussetzungen. Zwei sinnvolle Wege:
- Entweder echte Texte (z. B. aus dem Projekt) in allen Varianten identisch verwenden.
- Oder bewusst neutrale Platzhalter, aber dann überall gleich (z. B. gleicher Umfang, gleiche Zeilenanzahl).
Wichtig: Nicht Variante A mit kurzen Überschriften und Variante B mit langen Absätzen testen – sonst wird unbewusst Inhalt statt Layout bewertet. Wer mehr Sicherheit bei UI-Texten braucht, findet hilfreiche Leitlinien in UI-Text im Webdesign: Microcopy, die Nutzer führt.
Praktischer Workflow: Varianten anlegen, testen, Entscheidung sichern
Kleine Schritte statt „Big Bang“-Redesign
Varianten funktionieren am besten, wenn pro Runde nur wenige Dinge verändert werden. Eine Variante, die Navigation, Hero, Cards und Typografie gleichzeitig umkrempelt, ist schwer zu bewerten. Besser ist ein iteratives Vorgehen: Erst Layoutstruktur, dann Priorisierung, dann Details.
So geht’s: Varianten-Set in 20–40 Minuten aufsetzen
- Eine klare Frage formulieren (z. B. „Welche Produktkarte wird schneller verstanden?“).
- Basis-Screen duplizieren und in 2–3 Varianten aufteilen.
- Nur die Elemente ändern, die zur Frage gehören; alles andere identisch lassen.
- Komponenten verwenden (statt einzelne Layer zu kopieren) und Auto Layout aktiv halten.
- Frames sauber benennen und nebeneinander ausrichten, damit der Vergleich „auf einen Blick“ klappt.
- Entscheidung als kurzer Kommentar dokumentieren (was wurde gewählt und warum).
Entscheidungen nachvollziehbar machen – auch Monate später
Viele Teams kennen das: Nach ein paar Wochen fragt jemand „Warum ist das so gelöst?“ und niemand erinnert sich. Deshalb sollte jede Variante eine kurze Entscheidungsspur bekommen. Das muss kein Roman sein. Zwei Sätze reichen: „Variante B gewählt, weil CTA früher sichtbar und weniger Scrollen nötig. Variante A verworfen, weil Sekundärinfos zu dominant.“
Für strukturierte Feedbackrunden ist ein klarer Ablauf hilfreich. Dazu passt Design Review im Webdesign – Feedback, das wirklich hilft, um Diskussionen nicht im Kreis laufen zu lassen.
Typische Stolperfallen bei Varianten (und wie sie vermieden werden)
Unterschiedliche Abstände verfälschen den Vergleich
Abstände wirken stärker, als vielen bewusst ist: Eine Variante kann „besser“ wirken, weil sie mehr Luft hat – nicht weil die Struktur besser ist. Darum sollten Spacing-Regeln (Abstände) gleich bleiben. Wenn Abstände Teil der Frage sind, muss das bewusst benannt werden.
Wer ein einheitliches Spacing-System aufbauen will, kann sich an Designsystem-Abstände im UI – Spacing-System klar planen orientieren.
Zu viele Varianten auf einmal
Drei Varianten sind oft ein sinnvoller Maximalwert: Basis plus zwei Alternativen. Alles darüber macht Entscheidungen eher schwerer, weil Unterschiede nicht mehr klar zuordenbar sind. Wenn fünf Ideen existieren: zuerst grob aussortieren, dann zwei Favoriten sauber ausarbeiten.
Varianten werden „nachträglich“ in das System gepresst
Ein häufiger Zeitfresser: Erst frei bauen, später versuchen, das Ganze in Komponenten zu überführen. Besser ist, Varianten früh systemnah zu denken. Das bedeutet nicht, dass alles perfekt sein muss – aber zentrale Bausteine (Buttons, Inputs, Card-Grundstruktur) sollten als Komponenten stehen, damit nichts auseinanderdriftet.
Wann Varianten besser als Prototypen sind – und wann nicht
Statische Varianten: ideal für Layout- und Priorisierungsfragen
Wenn es um Hierarchie, Lesefluss und visuelle Klarheit geht, reichen nebeneinanderliegende Screens oft völlig aus. Der Blick „A vs. B“ ist schnell, und Feedback wird konkreter.
Klick-Prototyp: sinnvoll bei Flows und Interaktionen
Wenn die Frage lautet „Verstehen Nutzer den Ablauf?“, braucht es häufig einen klickbaren Prototyp (eine verlinkte Vorschau). Varianten können dann pro Schritt verglichen werden – wichtig ist, dass die Interaktionslogik gleich bleibt, sonst wird der Test unfair.
Wer unsicher ist, wann welches Artefakt passt, findet eine klare Einordnung in Wireframe vs. Mockup vs. Prototyp – richtig einsetzen.
Mini-Vergleich: Drei Wege, Varianten zu organisieren
| Ansatz | Vorteil | Nachteil |
|---|---|---|
| Nebeneinander auf einer Seite | Schnellster visueller Vergleich, ideal für Reviews | Kann bei vielen Screens breit und unübersichtlich werden |
| Pro Variante eine eigene Seite | Sauber getrennt, gut für große Flows | Vergleich dauert länger, weil Hin- und Herwechseln nötig ist |
| Ein Basis-Flow + Abzweige nur dort, wo nötig | Wenig Duplikate, leicht zu pflegen | Erfordert Disziplin bei Benennung und Struktur |
Für die meisten Webdesign-Projekte funktioniert „nebeneinander“ am besten – ergänzt um klare Namen und eine feste Seite für Experimente. Bei großen Flows ist die Mischform oft am stabilsten: Basis-Flow plus gezielte Abzweige.
Kurzer Reality-Check vor der Freigabe
Fünf Fragen, die Varianten sofort besser machen
- Ist pro Variante klar, welche Frage beantwortet werden soll?
- Sind Texte, Abstände und Typografie wirklich vergleichbar gehalten?
- Bestehen die Varianten aus Komponenten (statt aus Einzelteilen)?
- Ist erkennbar, welche Variante aktuell bevorzugt wird – und warum?
- Kann eine andere Person die Screens in 30 Sekunden verstehen?
Wenn diese Punkte sitzen, werden Varianten nicht zur Last, sondern zum Werkzeug: Entscheidungen werden schneller, Diskussionen konkreter und die spätere Umsetzung wird deutlich ruhiger – weil weniger „verlorene“ Designarbeit existiert.
