Wie nehmen Sie Figma-Code-Layers-Prototypen ab? Designer-Checkliste 2026

Abnahmeziel festlegen: Was der Code-Prototyp belegt

Figma beschreibt Code Layers als codebasierte, interaktive Prototypen innerhalb der Designfläche. Laut der offiziellen Hilfe und den Produktupdates wird die Funktion zum genannten Prüfzeitpunkt schrittweise als öffentliche Beta bereitgestellt. Verfügbarkeit und konkrete Funktionen können daher je nach Zugang oder späteren Änderungen abweichen. Prüfen Sie vor dem Abnahmetermin den aktuellen Stand in der offiziellen Code-Layers-Hilfe und den Produktupdates.

Entscheidend ist die Grenze zwischen einer überprüfbaren Darstellung und einem freigegebenen Produkt: Eine Vorschau in der Designfläche zeigt, wie sich der aktuelle Prototyp verhält. Sie belegt nicht automatisch, dass der Produktionscode vollständig, sicher, barrierefrei, wartbar oder in allen Zielbrowsern geprüft ist. Das gilt auch dann, wenn der Prototyp echte Codebestandteile enthält oder sich mit einem Repository verbinden lässt.

Kann ein Figma-Code-Prototyp direkt an die Entwicklung übergeben werden?

Er kann als überprüfbare Referenz für Designabsicht und Interaktionen mitgegeben werden. Als alleinige Produktionsgrundlage reicht er nicht aus. Die Entwicklung muss weiterhin klären, welche Komponenten, Daten, Schnittstellen, Fehlerbehandlungen und Qualitätsanforderungen für das fertige Produkt gelten. Halten Sie deshalb in der Übergabe fest, was der Prototyp demonstriert und was ausdrücklich noch nicht implementiert oder getestet wurde.

Damit wird auch eine häufige Verwechslung vermieden: „Im Prototyp klickbar“ bedeutet nicht „im Produkt umgesetzt und abgenommen“. Die Freigabe sollte sich immer auf einen benannten Prüfgegenstand beziehen, nicht pauschal auf den Prototyp als Ganzes.

Visuelle Treue anhand repräsentativer Ansichten beurteilen

Eine einzelne gelungene Ansicht reicht nicht, um die visuelle Umsetzung zu beurteilen. Wählen Sie repräsentative Seiten aus, an denen sich die entscheidenden Gestaltungsregeln zeigen: etwa eine Seite mit Navigation, eine mit längeren Texten oder eine mit einem zentralen Formular. Welche Ansichten relevant sind, bestimmt der Projektumfang; eine feste Zahl von Screens ist dafür nicht erforderlich.

Prüfen Sie jede ausgewählte Ansicht in derselben Reihenfolge:

1. Layout und Ausrichtung: Stimmen Abstände, Fluchten, Spalten und die Position wichtiger Elemente mit der beabsichtigten Gestaltung überein?
2. Typografie und Inhalt: Sind Schriftgrößen, Zeilenumbrüche, Beschriftungen und Textlängen in der Vorschau plausibel? Ein Platzhaltertext kann ein Layout anders wirken lassen als der spätere Produktinhalt.
3. Komponenten und Zustände: Sind Schaltflächen, Eingabefelder, Menüs und Hinweise eindeutig erkennbar? Achten Sie darauf, ob aktive, inaktive oder fehlerhafte Zustände sichtbar voneinander abweichen.
4. Visuelle Hierarchie: Wird der Blick zuerst auf die Elemente gelenkt, die für den jeweiligen Schritt wichtig sind?
5. Dokumentation der Abweichung: Halten Sie fest, welche Stelle betroffen ist, was beobachtet wurde und welche Gestaltungsabsicht dagegensteht.

Die Prüfung bezieht sich auf die aktuell ausführbare Darstellung des Prototyps. Sie ist keine Garantie dafür, dass ein statisches Design automatisch und ohne Abweichungen in Code überführt wurde. Notieren Sie daher konkrete Beobachtungen statt pauschaler Urteile wie „sieht fast richtig aus“. Eine brauchbare Notiz beschreibt beispielsweise, dass sich ein Hinweistext über die Schaltfläche legt oder dass ein Beschriftungstext unerwartet umbricht.

Auch Kontrast sollte nicht nur nach persönlichem Eindruck bewertet werden. Die WCAG-2.2-Erfolgskriterien nennen für normalen Text ein Kontrastverhältnis von mindestens 4,5:1 und für großen Text mindestens 3:1; für visuelle Informationen von Bedienelementen und grafischen Objekten gilt in den einschlägigen Fällen ebenfalls ein Mindestverhältnis von 3:1. Diese Werte sind konkrete Prüfkriterien der W3C-Empfehlung WCAG 2.2, aber kein Ersatz für die vollständige Barrierefreiheitsprüfung des fertigen Produkts.

Interaktionszustände als eigene Abnahmekriterien prüfen

Für die Interaktionsprüfung genügt es nicht, den Hauptpfad einmal erfolgreich durchzuklicken. Legen Sie vor dem Review fest, welche Aktion zu welchem sichtbaren Ergebnis führen soll. Dazu gehören je nach Produkt beispielsweise die Navigation zwischen Ansichten, das Absenden eines Formulars, das Öffnen eines Menüs oder die Rückkehr aus einem Dialog.

Wie lassen sich die Interaktionszustände in Figma Code Layers prüfen?

Prüfen Sie jeden relevanten Bedienpfad als Abfolge aus Auslöser, erwarteter Reaktion und sichtbarem Ergebnis. Ein einfaches Prüfprotokoll kann so aussehen:

Auslöser: Formular absenden
Erwartet: Eingaben werden geprüft
Sichtbar: Bestätigung oder verständlicher Fehlerhinweis
Offen: Verhalten bei fehlender Verbindung

Die Angaben in diesem Beispiel sind ein Muster für die Dokumentation, keine Behauptung über eine bestimmte Code-Layers-Funktion. Ersetzen Sie sie durch die tatsächlichen Projektanforderungen. Besonders wichtig ist die Unterscheidung zwischen einem Zustand, der im Prototyp dargestellt wird, und einem Zustand, dessen Verhalten im späteren Produkt bereits umgesetzt ist.

Gehen Sie anschließend die folgenden Punkte durch:

• Hauptpfad: Kann die gewünschte Aufgabe vom Einstieg bis zum Ergebnis nachvollziehbar durchgespielt werden?
• Leere Ansicht: Wird verständlich, was zu tun ist, wenn noch keine Inhalte oder Ergebnisse vorliegen?
• Ladezustand: Gibt die Oberfläche Rückmeldung, solange eine Aktion noch nicht abgeschlossen ist?
• Fehlerfall: Erfahren Nutzer, was fehlgeschlagen ist und welcher nächste Schritt möglich ist?
• Abbruch und Rückkehr: Ist klar, wie ein Dialog geschlossen oder ein vorheriger Zustand wieder erreicht wird?
• Nicht abgebildete Fälle: Sind Grenzen, etwa doppelte Eingaben oder fehlende Berechtigungen, für das Review relevant und bisher nicht dargestellt?

Nicht jeder Prototyp muss alle denkbaren Produktzustände enthalten. Er muss aber deutlich machen, welche davon im Review enthalten sind und welche noch offenbleiben. Führen Sie offene Zustände als Aufgaben mit Verantwortlichkeit und Folgeschritt. Sonst wird eine erfolgreiche Demonstration des Hauptpfads leicht als vollständiger Test missverstanden.

Achten Sie außerdem auf die Verständlichkeit der Bedienung. Ein Element, das wie eine Schaltfläche aussieht, sollte eine erkennbare Funktion haben; eine rein dekorative Fläche sollte nicht versehentlich den Eindruck einer Bedienmöglichkeit erwecken. Falls das Verhalten im Prototyp von der erwarteten Produktlogik abweicht, kennzeichnen Sie diese Abweichung ausdrücklich, statt sie durch eine spontane Erklärung während der Präsentation zu überdecken.

Responsivität und Inhaltsschwankungen am echten Einsatzfall messen

Ein Code-Prototyp kann in einer ausgewählten Fenstergröße überzeugend aussehen und bei anderer Breite dennoch Probleme zeigen. Prüfen Sie daher die Größen und Inhaltssituationen, die das Projekt tatsächlich unterstützen soll. Leiten Sie aus einer erfolgreichen Vorschau nicht ab, dass alle Geräte, Fenstergrößen oder Browser ebenfalls abgedeckt sind.

Prüfen Sie bei jeder relevanten Größe:

• Werden Inhalte abgeschnitten oder horizontal aus dem sichtbaren Bereich geschoben?
• Überdecken sich Text, Symbole, Schaltflächen oder Navigationselemente?
• Bleiben wichtige Handlungen erreichbar, wenn Zeilen umbrechen?
• Reagiert das Layout nachvollziehbar auf längere Beschriftungen oder zusätzliche Inhalte?
• Bleiben Abstände und Hierarchie auch dann verständlich, wenn sich die Ansicht verändert?

Für die Abnahme ist die konkrete Beobachtung wichtiger als ein allgemeiner Vermerk wie „responsive“. Notieren Sie die getestete Ansicht, die veränderte Bedingung und das sichtbare Ergebnis. Beispiel: „Bei schmalerer Fensterbreite bricht die Beschriftung um und schiebt die primäre Schaltfläche nach unten.“ So kann das Team später entscheiden, ob dieses Verhalten beabsichtigt ist.

Wenn das Projekt konkrete Größen oder Inhaltsvarianten vorgibt, verwenden Sie diese Vorgaben und halten Sie sie fest. Erfinden Sie keine allgemeingültigen Mindestbreiten und übertragen Sie Ergebnisse nicht auf Gerätegrößen, die nicht geprüft wurden. Das WebKit-Handbuch zum responsiven Designmodus in Safari beschreibt eine Möglichkeit, responsive Ansichten in Safari zu untersuchen. Ein solcher Test ist eine gezielte Browserprüfung, aber keine automatische Aussage über sämtliche Geräte oder Umgebungen.

Repository-Änderungen nachvollziehbar übergeben

Ist der Prototyp mit einem GitHub-Repository verbunden, gehört zur Abnahme auch die Frage, welche Änderungen sichtbar sind und wer sie prüfen muss. Die offizielle Figma-Dokumentation zum Git-Workflow für Make und Code Layers beschreibt die unterstützten Arbeitsweisen. Eine Verbindung zum Repository bedeutet jedoch nicht, dass jede Änderung ohne Prüfung übernommen werden kann oder bereits den Qualitätsmaßstäben des Produktionscodes entspricht.

Wie prüfen Sie Änderungen nach einer GitHub-Verbindung?

Klären Sie zuerst, welches Repository und welcher Branch für die konkrete Prüfung relevant sind. Ein Branch ist ein getrennt geführter Arbeitsstand, in dem Änderungen geprüft werden können, ohne sie sofort in den gemeinsam genutzten Hauptstand zu übernehmen. Vergleichen Sie anschließend die Änderung mit dem vorherigen Stand und ordnen Sie die betroffenen Dateien dem Auftrag zu.

Wenn das Team lokal mit dem Repository arbeitet, können diese Befehle einen ersten Überblick geben:

git status --short --branch
git diff --stat
git diff --name-status

Die Ausgabe zeigt je nach Arbeitsstand beispielsweise den aktiven Branch, geänderte Dateien und eine Zusammenfassung der Unterschiede. Sie beweist weder, dass der Code korrekt ist, noch dass er sich bauen lässt oder sicher für eine Veröffentlichung ist. Die GitHub-Anleitung zum Vergleichen von Commits erläutert, wie Änderungen zwischen Ständen gegenübergestellt werden können.

Für die Übergabe sollte feststehen:

• welcher Branch oder Änderungsstand geprüft wurde;
• welche Dateien oder Bereiche betroffen sind;
• welche Änderung die Designabsicht abbilden soll;
• welche Punkte die Entwicklung zusätzlich beurteilen muss;
• wer die formale Prüfung übernimmt und wie Rückmeldungen dokumentiert werden.

Eine Pull Request ist ein Verfahren, um Änderungen vor einer Übernahme zu besprechen und zu prüfen. Verwenden Sie dafür die im Team vorgesehene Prüfung, statt einen Prototyp als stillschweigende Freigabe zu behandeln. Die GitHub-Kurzanleitung zur Prüfung von Pull Requests beschreibt den Review-Ablauf; geschützte Branches können zusätzlich Regeln für Zusammenführung und Freigabe festlegen. Ob solche Regeln gelten, hängt von der Konfiguration des jeweiligen Repositorys ab.

Safari und Zielbrowser nur passend zum Prüfauftrag einbeziehen

Beginnen Sie mit der Frage, welche Browser und Betriebssysteme das Produkt laut Projektanforderungen unterstützen soll. Prüfen Sie dann den Prototyp in den Umgebungen, die für eine konkrete Freigabe relevant sind. Wenn Safari ein Zielbrowser ist oder das Projekt ausdrücklich ein macOS-spezifisches Verhalten berücksichtigen muss, sollte die abschließende Browserprüfung in einer passenden Safari-Umgebung erfolgen.

Wann ist eine Safari-Webprüfung notwendig?

Sie ist sinnvoll, wenn Safari zu den vereinbarten Zielbrowsern gehört, ein offener Fehler dort beobachtet wurde oder ein bestimmtes Verhalten unter macOS bestätigt werden muss. Fehlt eine solche Projektanforderung, sollte Safari nicht pauschal als Pflichtprüfung ergänzt werden. Umgekehrt ersetzt eine Prüfung in einem anderen Browser keine angeforderte Safari-Abnahme.

Unterscheiden Sie dabei drei Ebenen:

1. Prototypvorschau: Sie zeigt, wie der aktuelle Code-Prototyp in seiner vorgesehenen Vorschau reagiert.
2. Browserprüfung: Sie prüft die tatsächliche Darstellung und Bedienung im festgelegten Browser und in der vorgesehenen Umgebung.
3. Produktionsabnahme: Sie bewertet die umgesetzte Anwendung einschließlich ihrer Funktionen und der geltenden Teamanforderungen.

Eine Remote-Ansicht kann helfen, eine Umgebung zu bedienen, sagt aber für sich genommen nichts darüber aus, ob das Netzwerkerlebnis für eine bestimmte Arbeitsweise ausreicht oder ein Browserfehler vorliegt. Trennen Sie deshalb Beobachtungen zur Verbindung und Bildschirmübertragung von Fehlern in Layout oder Interaktion. Protokollieren Sie Browser, Betriebssystem, Prüfschritt und reproduzierbares Ergebnis, ohne aus einem einzelnen Versuch eine allgemeine Kompatibilitätsaussage abzuleiten.

Für Teams mit Windows-Arbeitsplätzen ist der nächste Schritt eine sachliche Bedarfsentscheidung: Ist tatsächlich eine macOS- und Safari-Prüfung vorgesehen, oder genügt die vereinbarte Prüfung in den übrigen Zielumgebungen? Einen Überblick über verfügbare Mac-Mietoptionen von NodeMini finden Sie in der deutschen Bestellübersicht. Für Hintergrundinformationen zum Angebot kann außerdem die deutsche NodeMini-Seite herangezogen werden; daraus sollten jedoch keine ungeprüften Aussagen über konkrete Browser-Testergebnisse, Gerätekonfigurationen oder Netzwerkqualität abgeleitet werden.

Übergabe mit klarer Freigabegrenze abschließen

Fassen Sie die Ergebnisse so zusammen, dass das Entwicklungsteam zwischen bestätigt, offen und nicht geprüft unterscheiden kann. Eine kurze Übergabe kann diese Angaben enthalten:

• Bestätigt: die im Review tatsächlich geprüften Ansichten und Interaktionen;
• Abweichungen: konkrete Beobachtungen mit nachvollziehbarem Prüfweg;
• Offen: Zustände, Inhalte oder Browser, die noch nicht geprüft wurden;
• Repository: geprüfter Änderungsstand und zuständige Person für den Review;
• Freigabegrenze: ob die Designrichtung, die Interaktion oder die fertige Anwendung abgenommen wurde.

Damit lässt sich auch die Frage beantworten, ob ein Prototyp „fertig“ ist: Er kann für ein Designreview ausreichend sein, während die Entwicklungsübergabe oder Produktionsprüfung noch offene Punkte enthält. Verwenden Sie für jede Freigabe die passende Bezeichnung und vermeiden Sie eine allgemeine Bestätigung, die mehr verspricht als tatsächlich geprüft wurde.

Wenn Safari-Tests Teil des Auftrags sind, aber im Team kein Mac verfügbar ist, vergleichen Sie zuerst den Aufwand einer zeitweisen Mac-Nutzung mit den Alternativen: Eine vorhandene Mac-Umgebung kann für gelegentliche Prüfungen genügen; ein eigener Mac ist sinnvoller, wenn regelmäßig darauf entwickelt oder dauerhaft gearbeitet wird. Eine Mietlösung von NodeMini kann für zeitlich begrenzte Browserprüfungen eine Option sein, während langfristige, intensive Nutzung oder notwendige physische Anschlüsse eher für eine eigene Arbeitsstation sprechen. Entscheidend bleibt, die konkrete Zielumgebung selbst zu prüfen und den Prototyp nicht mit einer Produktionsfreigabe gleichzusetzen.