Figma Make: Lokalen Code als PR einreichen? Design-Workflow 2026

Figma Make für lokalen Code ist kein Schalter, den jedes Konto zwangsläufig vorfindet. Figma stellt die Funktion schrittweise als Beta bereit. Für den hier beschriebenen Arbeitsablauf benötigen Sie ein berechtigtes Konto, die Mac-Version der Beta-Desktopanwendung und Zugriff auf das Repository. Die Figma-Ankündigung zur Arbeit am lokalen Code und die Einrichtungsanleitung beschreiben den vorgesehenen Funktionsumfang und die Voraussetzungen.

Welche Konto- und Mac-Voraussetzungen müssen erfüllt sein? Öffnen Sie die Beta-Anwendung auf einem Mac und prüfen Sie, ob die Funktion in Ihrem Konto verfügbar ist. Fehlt sie, lässt sich das nicht durch eine andere Repository-Einstellung oder einen zusätzlichen Git-Befehl umgehen. Die Freischaltung ist keine Zusage, dass jedes Konto zugelassen wird. Planen Sie den Designauftrag deshalb nicht so, als sei die Funktion unabhängig von der Beta verfügbar.

Ziehen Sie außerdem eine klare Aufgabengrenze. Der Ablauf eignet sich für Änderungen an einer bereits vorhandenen Weboberfläche: etwa einen klar umrissenen Abschnitt, eine Komponente oder eine Beschriftung. Er ist keine Anleitung zum Erstellen einer neuen Anwendung, zur Backend-Entwicklung oder zum Einrichten der Projektinfrastruktur. Für diese Themen bleiben die zuständigen Entwickler verantwortlich.

Ein Git-Repository ist der gemeinsam verwaltete Speicherort des Projektcodes. Vor dem Öffnen in Figma Make sollte ein Entwickler bestätigen, dass Sie das richtige Repository verwenden dürfen und die erforderlichen Rechte besitzen. Die Verbindung mit dem Projekt ersetzt weder die Teamfreigabe noch eine Prüfung vertraulicher Dateien.

Lassen Sie die einmalige Projektvorbereitung von einer Person übernehmen, die das Repository kennt. Dazu gehören die passende Projektkonfiguration und die Information, wie sich die Vorschau starten lässt. Die offizielle Einrichtungsanleitung ist der Bezugspunkt für die unterstützte Vorbereitung. Stimmen die Voraussetzungen des Projekts nicht, kann der Start an Abhängigkeiten oder Konfiguration scheitern, bevor eine Designänderung überhaupt ins Spiel kommt.

Auch der Git-Anbieter beeinflusst den letzten Schritt. Figma beschreibt GitHub als Anbieter, bei dem PRs in der Anwendung erstellt werden können. Bei GitLab und Bitbucket erfolgt das Erstellen des Merge Requests beziehungsweise Pull Requests auf der jeweiligen Plattform. Die unterschiedlichen Begriffe ändern nichts an der Teamaufgabe: Änderungen nachvollziehbar bereitstellen und prüfen lassen.

Die Tabelle ist keine Aussage, dass jeder Projekttyp mit jeder Konfiguration automatisch funktioniert. Maßgeblich sind die aktuelle Figma-Unterstützung und die Rechte im jeweiligen Teamprojekt. Vermischen Sie insbesondere nicht die Fähigkeit, einen Codebestand zu öffnen, mit der Möglichkeit, den PR direkt innerhalb der Anwendung anzulegen.

Wie verbinden Sie Figma Make mit einem bestehenden GitHub-Projekt? Wählen Sie in der Mac-Anwendung den vorgesehenen Einstieg für einen vorhandenen lokalen Codebestand oder klonen Sie das entfernte Repository, sofern das Projekt und Ihr Zugriff diesen Weg erlauben. Prüfen Sie beim Verbinden den Repository-Namen und den Projektordner, bevor Sie fortfahren. Figma beschreibt Einrichtung und unterstützte Abläufe in der offiziellen Anleitung für lokalen Code.

Gehen Sie in dieser Reihenfolge vor, bevor Sie eine Oberfläche verändern:

1. Zugriff bestätigen. Melden Sie sich mit dem Konto an, das die erforderlichen Repository-Rechte besitzt. Ist der Zugriff nicht vorhanden, lassen Sie ihn durch die zuständige Projektperson einrichten.
2. Projekt öffnen. Verbinden Sie den vorhandenen lokalen Codebestand oder klonen Sie das Team-Repository über den vorgesehenen Einstieg. Kontrollieren Sie Ordner und Projektidentität.
3. Projektkonfiguration prüfen. Klären Sie mit einem Entwickler, ob notwendige Abhängigkeiten installiert sind und welche projektbezogene Startanweisung gilt. Verwenden Sie keine beliebige Anleitung aus einem anderen Projekt.
4. Vorschau starten. Öffnen Sie die Projektvorschau und verifizieren Sie, dass die angezeigte Seite zum vorgesehenen Repository und zum richtigen Arbeitsstand gehört.
5. Erst danach ändern. Wenn Vorschau oder Projektstart scheitern, stoppen Sie und dokumentieren Sie die Fehlermeldung. Prüfen Sie zuerst Zugriffsrechte, Projektkonfiguration und Abhängigkeiten.

Figma nennt eigene Einrichtungshinweise und Fehlerbehebung für lokalen Code. Sie sind besonders relevant, wenn die Vorschau nicht startet oder die Anwendung das erwartete Projekt nicht laden kann. Eine fehlgeschlagene Vorschau belegt für sich allein nicht, dass eine Designanweisung falsch war: Das Problem kann bereits beim Repository-Zugriff oder bei der Projektkonfiguration liegen.

Arbeiten Sie nicht weiter, wenn unklar ist, ob die Vorschau die richtige Seite zeigt. Sonst bewerten Sie womöglich eine andere Projektversion als die, die später im Branch landet. Halten Sie vor dem Bearbeiten außerdem fest, welche Stelle verändert werden soll und woran das Team die gewünschte Wirkung erkennt.

Beginnen Sie mit einer kleinen, sichtbaren und prüfbaren Aufgabe. Infrage kommen beispielsweise eine genau bezeichnete Komponente, ein abgegrenzter Seitenabschnitt oder eine konkrete Anpassung an Abständen und Darstellung. Je klarer der Änderungsumfang, desto leichter lässt sich die Vorschau mit dem Code-Diff vergleichen.

Für die Arbeit können Sie die verfügbaren Bedienelemente wie Eigenschaften, Markierungen auf der Oberfläche oder natürlich formulierte Änderungsanweisungen einsetzen. Beschreiben Sie nicht nur, was anders aussehen soll, sondern auch, was unverändert bleiben muss. Ein sinnvoller Auftrag benennt das betroffene Element, die beabsichtigte Änderung und eine sichtbare Bedingung für die Kontrolle. Vermeiden Sie unbestimmte Aufträge wie „Seite moderner machen“: Sie erschweren eine nachvollziehbare Prüfung.

Die Vorschau ist eine Kontrolle der sichtbaren Wirkung, aber keine Bestätigung, dass die Änderung dem Designsystem, allen Projektregeln oder den Erwartungen des Teams entspricht. Prüfen Sie deshalb beide Seiten:

• Vorschau: Wurde tatsächlich die beabsichtigte Stelle angepasst? Bleiben angrenzende Bereiche intakt?
• Code-Diff: Sind nur die erwarteten Dateien und Bereiche verändert? Gibt es unerwartete Änderungen?
• Projektanforderungen: Stimmen Texte, Komponentenverwendung und vereinbarte Gestaltungsregeln?
• Teamabstimmung: Ist für die Änderung eine zusätzliche Prüfung durch Design oder Entwicklung erforderlich?

Figma beschreibt in einem Workflow-Beispiel den Einsatz von Figma Make für die Umsetzung von Designs. Das Beispiel ist kein Nachweis dafür, dass jede generierte Änderung korrekt oder direkt übernahmefähig ist. Für Ihr Projekt bleibt der konkrete Diff entscheidend.

Ein Branch ist ein getrennter Arbeitszweig im Repository. Er hält die Änderung von der gemeinsam verwendeten Hauptlinie getrennt, bis das Team sie geprüft und über die Übernahme entschieden hat. Ein Commit dokumentiert einen festgehaltenen Arbeitsstand. Ein PR stellt die Änderung den zuständigen Personen zur Prüfung bereit. Keiner dieser Schritte ist eine automatische Freigabe.

Prüfen Sie den Änderungsumfang, bevor Sie einen Commit erstellen oder die Änderung zur Prüfung weitergeben. Entfernen oder klären Sie unerwartete Änderungen, statt sie zusammen mit der Designanpassung einzureichen. Führen Sie die Tests oder Projektprüfungen aus, die für das konkrete Repository vereinbart sind. Ist unklar, welche Prüfungen vorgesehen sind, fragen Sie die zuständige Entwicklerin oder den zuständigen Entwickler, statt Tests zu überspringen oder fremde Befehle auszuführen.

Wie werden Änderungen aus Figma Make zu einem Branch und PR? Prüfen Sie die angebotenen Git-Schritte in der Anwendung und halten Sie fest, welcher Branch die Änderung enthält. Bei GitHub kann die PR-Erstellung laut Figma in der Anwendung erfolgen. Bei GitLab und Bitbucket wechseln Sie für die Erstellung auf die jeweilige Plattform. Dort gelten die Plattformanleitungen für die Erstellung des jeweiligen Merge Requests oder Pull Requests.

Fügen Sie der Übergabe eine kurze, überprüfbare Beschreibung bei: betroffene Oberfläche, gewünschtes Ergebnis, geänderte Bereiche, vorhandene Vorschau und noch offene Fragen. Bitten Sie um Prüfung, statt eine bereits beschlossene Freigabe zu unterstellen. Die zuständigen Entwickler können den Diff, die Tests und mögliche Auswirkungen auf den übrigen Code bewerten. Hinweise zur Prüfung eines PR enthält die Dokumentation zur Überprüfung vorgeschlagener Änderungen.

Für Windows-Teams stellt sich die Frage nicht nur, ob ein Remote Mac erreichbar ist. Entscheidend ist, ob Sie damit die erforderliche Mac-Beta-Anwendung ausführen können und ob Repository-Zugriff, Projektstart und anschließende Datei- beziehungsweise Branch-Übergabe im vorgesehenen Ablauf funktionieren. Wir können ohne einen repräsentativen Test des konkreten Projekts keine allgemeine Aussage zu Vorschau, Verbindung oder Übergabe versprechen.

Nutzen Sie diese Entscheidungsbedingungen:

• Wenn Ihr Konto für die Beta freigeschaltet ist, dann prüfen Sie den vorgesehenen Zugang zur Mac-Anwendung und testen Sie das Projekt mit der zuständigen Person.
• Wenn das Konto nicht freigeschaltet ist, dann wechseln Sie nicht einfach auf einen Remote Mac: Eine andere Umgebung schafft keine Beta-Berechtigung. Stimmen Sie einen alternativen Design- oder Entwicklerprozess ab.
• Wenn Repository-Rechte oder Projektkonfiguration fehlen, dann lassen Sie diese zuerst durch das Team klären. Ein Mac ersetzt keine Zugriffsfreigabe und keine einmalige Projekteinstellung.
• Wenn die Mac-Anwendung auf der gewählten Umgebung verfügbar ist und der Projektstart gelingt, dann kann ein Remote Mac für die Bearbeitung und PR-Vorbereitung infrage kommen. Testen Sie vor einem wichtigen Auftrag Vorschau und Übergabe am tatsächlichen Projekt.
• Wenn eine Änderung sofort produktiv gehen soll, dann halten Sie trotzdem die Teamprüfung und den bestehenden Veröffentlichungsprozess ein. Die Beta ist kein Ersatz für Freigaben.

Windows-only zu arbeiten ist für diesen lokalen Mac-Beta-Ablauf ungeeignet, wenn die erforderliche Anwendung dort nicht verfügbar ist. Ein eigener Mac vermeidet die Abhängigkeit von einer entfernten Sitzung, bindet aber Kapital und muss für die Arbeitsaufgabe eingerichtet und gepflegt werden. Ein Remote Mac kann den Zugriff auf einen echten Mac ermöglichen, bringt jedoch eine Verbindung und eine zusätzlich zu prüfende Projektübergabe mit sich. Wo die Daten verarbeitet werden und welche Dateien übertragen werden, sollte das Team außerdem anhand seiner Datenschutz- und DSGVO-Vorgaben klären.

Für einen zeitlich begrenzten Test können Sie die MESHLAUNCH-Übersicht zu Remote-Mac-Möglichkeiten prüfen. Das ist keine Zusage für Beta-Zugang, Repository-Rechte oder eine erfolgreiche Vorschau. Wenn Sie statt einer temporären Umgebung einen eigenen Mac vergleichen möchten, finden Sie außerdem Informationen zum Mac mini M4. Entscheidend bleibt, ob Ihr konkreter Projektablauf zur gewählten Umgebung passt.

Gehen Sie vor dem Öffnen oder Weiterleiten des PR diese Liste durch:

• [ ] Beta-Zugang und Mac-Anwendung geprüft.
• [ ] Richtiges Repository und ausreichende Teamrechte bestätigt.
• [ ] Vorschau gehört nachweislich zum vorgesehenen Projekt.
• [ ] Änderung ist auf einen vereinbarten UI-Umfang begrenzt.
• [ ] Vorschau und Code-Diff wurden getrennt kontrolliert.
• [ ] Unerwartete Änderungen sind geklärt oder entfernt.
• [ ] Vereinbarte Projektprüfungen wurden ausgeführt oder als offen markiert.
• [ ] Branch und PR beziehungsweise Merge Request sind eindeutig benannt.
• [ ] Übergabe enthält Änderungsumfang, Prüfergebnis und offene Fragen.
• [ ] Die zuständigen Personen wissen, dass Freigabe und Veröffentlichung weiterhin bei ihnen liegen.

Für Windows-Designer ist der praktikable nächste Schritt daher: erst Berechtigung und Teamzugriff bestätigen, dann mit einem kleinen bestehenden Webprojekt den vollständigen Ablauf erproben. Bleibt die Arbeit unter Windows, scheitert dieser konkrete lokale Code-Workflow an der erforderlichen Mac-Anwendung; ein eigener Mac kann dafür eine dauerhafte Alternative sein, ist aber für einen gelegentlichen Test womöglich unnötig aufwendig. Ein Remote Mac ist dann eine prüfbare Zwischenlösung, wenn Anwendung, Projektzugriff und Übergabe im tatsächlichen Teamprozess funktionieren. MESHLAUNCH kann für diesen zeitlich begrenzten Mac-Bedarf eine Option sein – nicht für die Beschaffung der Figma-Beta-Berechtigung und nicht als Ersatz für die technische Prüfung des PR.