UI-Mockups in Figma erstellen – vom Scribble zum Klickprototyp

Wer heute Websites oder Web-Apps plant, kommt an Figma kaum vorbei. Das Tool ist schnell, läuft im Browser und eignet sich perfekt, um saubere UI-Mockups zu bauen. Entscheidend ist weniger das Werkzeug, sondern die Methode dahinter: Wie wird aus einer vagen Idee ein klares, klickbares Layout, das Entwicklung und Stakeholder wirklich weiterbringt?

Dieser Praxisleitfaden zeigt, wie UI-Mockups in Figma so aufgebaut werden, dass sie verständlich, erweiterbar und für Teams gut nutzbar sind – auch ohne jahrelange Design-Erfahrung.

Figma-Datei für UI-Mockups richtig anlegen

Bevor die erste Linie gezeichnet wird, lohnt sich ein sauberer Start. Eine strukturierte Datei spart später viel Chaos, Nachfragen und Nacharbeit.

Seiten, Frames und Namenskonventionen planen

In Figma gibt es Seiten (Pages) und darin Frames (Rahmen, meist einzelne Screens). Eine einfache Struktur für Webprojekte:

• Seite „❏ Flow & Sitemap“ – grobe Seitenübersicht, einfache Kästen mit Pfeilen zwischen den Screens.
• Seite „UI-Mockups“ – alle eigentlichen Layouts für Desktop, Tablet, Mobile.
• Seite „Designsystem“ – Farben, Schriftstile, Komponenten für Buttons, Formulare, Karten.

Für Frames hat sich ein klares Namensschema bewährt, zum Beispiel: web / home, web / produktliste, web / checkout. So lassen sich Screens später einfacher suchen, filtern und verlinken.

Wer bereits ein eigenes Designsystem nutzt, kann es aus anderen Figma-Dateien oder aus Tools wie klar geplanten Auto-Layout-Setups übernehmen und als Grundlage verwenden.

Layout-Raster und Breakpoints definieren

Bevor mit dem Gestalten begonnen wird, sollten die wichtigsten Breakpoints (also Bildschirmbreiten) feststehen. Für viele Business-Websites reichen typischerweise:

• Desktop: breiter Bildschirm (z. B. 1440 px Breite)
• Tablet: mittlere Breite (z. B. 768 px)
• Smartphone: schmale Breite (z. B. 375 oder 390 px)

In Figma lohnt sich ein Spaltenraster: etwa 12 Spalten für Desktop, 6 für Tablet, 4 für Mobile – mit gleichmäßigen Abständen. Das Raster gibt Halt, sorgt für Ordnung und erleichtert die spätere Umsetzung im Code oder im CMS.

UI-Mockups strukturieren: Vom Wireframe bis zum Detail

Viele Projekte scheitern daran, dass zu früh „schön“ gestaltet wird. Sinnvoller ist eine klare Trennung: erst Struktur und Funktion, dann visuelle Feinheiten.

Low-Fidelity-Wireframes in Figma umsetzen

Low-Fidelity-Wireframes sind grobe Skizzen mit einfachen Formen, ohne Bilder, ohne Farben. In Figma reichen dafür Rechtecke, Linien und Text. Der Fokus: Was steht wo, in welcher Reihenfolge, mit welcher Gewichtung?

• Header: Logo, Hauptnavigation, Call-to-Action (z. B. „Kontakt“, „Demo testen“).
• Above-the-Fold: starke Überschrift, kurzer Text, Hauptaktion.
• Content-Bereiche: Abschnitte für Nutzenargumente, Funktionen, Referenzen, FAQ.
• Footer: Kontakt, rechtliche Links, ggf. Newsletter-Anmeldung.

Die Elemente wirken anfangs bewusst simpel. So kann das Team sich auf Inhalte und Prioritäten konzentrieren, statt über Farben oder Symbolformen zu diskutieren. Für Inhaltsteams, die klare SEO-Strukturen brauchen, lassen sich die Wireframes gut mit einem sauber aufgebauten Textkonzept verbinden.

Vom Wireframe zum visuellen Mockup

Stehen Aufbau und Flow, wird aus dem Wireframe ein ausformuliertes Mockup. Dabei hilft eine einfache Reihenfolge:

• Typografie definieren: eine Schriftfamilie für Headlines, eine für Fließtext (oder eine Familie mit abgestuften Schnitten).
• Farbsystem anlegen: Primärfarbe für Hauptaktionen, Sekundärfarben für Akzente, neutrale Grautöne für Hintergründe und Rahmen.
• Abstände standardisieren: feste vertikale Abstände zwischen Abschnitten und konsistente Innenabstände in Boxen.
• Interaktive Elemente hervorheben: Buttons, Links, Input-Felder klar erkennbar machen.

So entsteht ein konsistentes Erscheinungsbild, das sich später in ein eigenes Designsystem überführen lässt – ähnlich systematisch wie bei einem klar definierten Typografie-Setup.

Komponenten, Varianten und Auto Layout nutzen

Die wahre Stärke von Figma zeigt sich, wenn Elemente wiederverwendbar werden. Komponenten (wiederverwendbare Bausteine) sorgen dafür, dass Änderungen schnell und konsistent durchs Design laufen.

Basis-Komponenten für Buttons, Formulare und Karten

Für Web-Mockups braucht es einige immer wiederkehrende Muster. Diese sollten als Komponenten im „Designsystem“-Bereich liegen:

• Buttons: Primär, Sekundär, Text-Button, ggf. Gefahr-Button (Fehler/Löschen).
• Formularelemente: Textfeld, Dropdown, Checkbox, Radiobutton, Fehlermeldung.
• Karten: Produktkarte, Blog-Teaser, Team-Mitglied, Feature-Kachel.

Mit Figma-Varianten lassen sich z. B. Zustände wie „normal“, „hover“, „disabled“ abbilden. So sieht das Team auf einen Blick, wie der Button in verschiedenen Situationen wirkt.

Auto Layout für flexible UI-Mockups

Mit Auto Layout reagiert ein Frame automatisch auf Textlängen und Inhalte. Das ist besonders für Buttons, Navigationen und Karten praktisch. Ein Beispiel:

• Button-Komponente mit Auto Layout: Innenabstände festlegen, Text mittig, Mindestbreite definieren.
• Ändert sich der Button-Text („Mehr erfahren“ zu „Jetzt kostenlos testen“), wächst die Breite automatisch mit.
• Bei Karten können Bild, Titel, Text und Button untereinander mit festen Abständen reagieren.

Auto Layout im Mockup spart Zeit und bringt das Layout näher an die spätere HTML/CSS-Realität heran. Gerade in größeren Projekten mit vielen Screens wird so verhindert, dass hundert Varianten von fast identischen Elementen entstehen.

Interaktive Prototypen und Nutzerflüsse in Figma anlegen

Mockups zeigen, wie etwas aussieht. Prototypen machen erlebbar, wie sich die Anwendung anfühlt. Für Stakeholder ohne Design-Hintergrund ist das oftmals der entscheidende Schritt.

Navigation und Klickpfade verknüpfen

In Figma können Interaktionen direkt im Prototyp-Modus definiert werden: Ein Klick auf einen Button führt zu einer anderen Seite, ein Tab im Formular springt zwischen Feldern, ein Hamburger-Menü fährt eine Navigation aus.

• Hauptnavigation: Links so verlinken, dass sich das Gefühl einer echten Website ergibt.
• Primäre Call-to-Actions: von der Startseite direkt in die relevanten Detailseiten (z. B. „Produkt“, „Angebot anfragen“).
• Formular-Flow: Klick auf „Weiter“ im Checkout führt immer auf den nächsten Schritt.

So entsteht in kurzer Zeit ein zusammenhängender Prototyp, der in Usability-Tests oder Pitches genutzt werden kann.

Animationen gezielt und sparsam einsetzen

Figma ermöglicht Mikro-Animationen, z. B. Übergänge, Hover-Zustände oder Akkordeon-Bewegungen. Im UI-Mockup sollten diese sparsam eingesetzt werden, um nicht vom Inhalt abzulenken. Sinnvolle Einsatzbereiche:

• Hover-Effekte auf Buttons oder Karten, um Interaktivität zu zeigen.
• Ein- und Ausklappen von FAQ-Bereichen.
• Transitions zwischen Modalen (z. B. Login-Popup).

Wichtig ist, dass Animationen die Benutzerführung unterstützen. Sie sollten klar machen, was gerade passiert, nicht nur „schön“ aussehen.

UI-Mockups mit Team und Stakeholdern abstimmen

Ein Figma-Mockup ist kein Kunstwerk, sondern ein Arbeitswerkzeug. Es muss diskutiert, kritisiert und verbessert werden. Dafür braucht es klare Spielregeln.

Kommentarfunktionen sinnvoll nutzen

Statt Feedback in E-Mails und Chatnachrichten zu verstreuen, lohnt es sich, die Kommentar-Funktion in Figma konsequent zu nutzen. So sind alle Rückmeldungen direkt am betroffenen Element sichtbar.

• Bereiche markieren und konkret kommentieren („Text zu technisch“, „Button-Label unklar“).
• Threads nutzen, um Entscheidungen festzuhalten.
• Kommentare schließen, sobald sie umgesetzt sind.

Wer seine Feedback-Runden noch strukturierter aufsetzen möchte, kann sie gut mit einem klaren Prozess für geplantes Design-Feedback im Webprojekt kombinieren.

Typische Missverständnisse bei UI-Mockups vermeiden

Gerade bei komplexeren Webprojekten treten immer wieder ähnliche Probleme auf:

• Pixelperfekte Erwartungen: Stakeholder erwarten, dass die Website exakt wie im Figma-Screenshot aussieht. In Wirklichkeit gibt es Unterschiede durch Browser, Schrift-Rendering und echte Inhalte.
• Unklare Zuständigkeiten: Wer entscheidet über Textänderungen, Bildauswahl, Struktur-Anpassungen?
• Fehlende Priorisierung: Alles wirkt gleich wichtig, weil zu viele Elemente hervorgehoben werden.

Eine klare Absprache am Anfang – was der Mockup zeigt und was erst in der Entwicklung entschieden wird – verhindert viele dieser Stolperfallen.

So geht’s: Checkliste für praxistaugliche Figma-UI-Mockups

• Dateistruktur aufsetzen: Seiten für Flow, UI-Mockups, Designsystem anlegen.
• Breakpoints und Raster definieren: Desktop, Tablet, Mobile mit passenden Spaltenrastern planen.
• Low-Fidelity-Wireframes erstellen: Inhalte, Reihenfolge, Prioritäten klären, bevor es „schön“ wird.
• Schriften, Farben, Abstände standardisieren: Grundsystem für Typografie und Farbschema anlegen.
• Komponenten und Varianten bauen: Buttons, Formulare, Karten wiederverwendbar machen.
• Auto Layout konsequent nutzen: flexible Elemente und Layouts aufbauen, die auf Inhalt reagieren.
• Prototyping einrichten: Klickpfade, Navigation und wichtigste Interaktionen durchverlinken.
• Feedback organisieren: Kommentare im Figma nutzen, Entscheidungen dokumentieren, Versionen kennzeichnen.

Mini-Ratgeber: UI-Mockups für Entwicklerinnen und Entwickler lesbar machen

Wer UI-Mockups für Entwicklungsteams erstellt, sollte an mehr denken als nur an hübsche Screens. Eine kleine Struktur hilft, später Zeit und Nerven zu sparen.

Struktur, Tokens und Logik klar dokumentieren

In vielen Projekten geht bei der Übergabe vom Design ins Frontend Wissen verloren. Besser ist es, das Mockup so aufzubauen, dass sich daraus direkt ein Designsystem oder eine Komponentenbibliothek ableiten lässt:

• Farben als „Tokens“ benennen, z. B. „primary/500“, „gray/100“ statt „helles Blau“.
• Textstile klar benennen, z. B. „Heading/H1“, „Body/Default“, „Label/Small“.
• Interaktive Zustände sichtbar machen: normal, hover, active, disabled in einer Zeile darstellen.

So lässt sich das Mockup leichter in wiederverwendbare Komponenten im Code übersetzen.

Inhalte und Zustände realistisch planen

Sehr kurze Platzhaltertexte täuschen oft über echte Herausforderungen hinweg. Besser sind realistische Längen – etwa Produktnamen mit mehreren Wörtern oder längere Fehlermeldungen. Auch „Edge Cases“ sollten im Mockup vorkommen:

• Lange Seitentitel in der Navigation.
• Formulare mit Fehlermeldungen und Validierungshinweisen.
• Listen mit nur einem oder sehr vielen Elementen.

Wer im Mockup zeigt, wie das UI mit solchen Situationen umgeht, verhindert spätere Notlösungen direkt im Code.

Vergleich: Low-Fidelity-Wireframes vs. High-Fidelity-Mockups

Typische Fehler bei UI-Mockups in Figma und wie sie sich vermeiden lassen

Einige Probleme tauchen in vielen Projekten immer wieder auf. Wer sie früh kennt, spart Zeit und Schleifen.

• Zu viele Farben und Schriften: Ohne definiertes System entstehen schnell unruhige Layouts. Besser: zuerst ein kleines Set festlegen und im Zweifel ergänzen.
• Unklare Hierarchien: Wenn jede Überschrift gleich groß und gleich stark ist, fehlt Orientierung. Hier helfen abgestufte Heading-Größen und wiederkehrende Muster.
• Keine Komponenten: Einzelne Elemente händisch zu kopieren, führt zu einem Flickenteppich. Komponenten und Auto Layout schaffen Ordnung.
• Fehlende Zustände: Ein UI ohne Hover, Focus oder Fehlerdarstellungen bleibt theoretisch. Zustände gehören ins Mockup, nicht erst in die Entwicklung.
• Kein Bezug zu echten Inhalten: Reine Platzhalter-Welten ignorieren komplexe Produktnamen, rechtliche Texte oder Übersetzungen. Besser: mit realistischen Beispielen arbeiten.

Gute UI-Mockups sind kein Selbstzweck. Sie bilden die Grundlage für verständliche Nutzeroberflächen, saubere Entwicklung und klare Kommunikation im Team. Mit einem systematischen Aufbau in Figma wird aus Einzelscreens ein konsistentes UI-Design, das sich flexibel weiterentwickeln lässt – von der ersten Idee bis zur Live-Website.