Figma bringt Code und Specs auf die Leinwand: Überlebt die Designabsicht?

Offizielle Markenkombination aus Figmas Markenressourcen, unverändert mit neutralem Rand nach den Richtlinien für informative Nutzung verwendet. Sie kennzeichnet das Unternehmen und zeigt weder Code Layers noch die Specs-Oberfläche.

Eine Registrierungsseite kann fertig aussehen, während wichtige Entscheidungen unsichtbar bleiben. Was passiert bei abgelaufener Einladung? Ist nach einem Netzwerkfehler ein neuer Versuch möglich? Welcher Text ist genehmigt? Ein laufender Prototyp beantwortet manche Fragen, kann sie aber auch hinter einem überzeugenden Erfolgsablauf verbergen.

Figmas Veröffentlichung vom 15. Oktober bringt Code Layers und Specs in die offene Beta. Code Layers platzieren laufende Prototypen direkt auf der Designleinwand. Specs geben schriftlicher Absicht einen gemeinsamen Ort neben den beschriebenen Designs, Diagrammen und Code. Figma, die vielen Produktteams bekannte kollaborative Designplattform, erweitert damit den Ort für Bildschirmdiskussionen zu einem Raum für gemeinsames Erkunden von Verhalten und Anforderungen. Figma-Veröffentlichungshinweise.

Unsere Einschätzung: Interessant ist die Beziehung zwischen diesen Materialien. Ein weiterer generierter Bildschirm überzeugt schnell in einer Demo; sein Verhalten mit Teamentscheidungen in Einklang zu halten ist der nützlichere Test. Dieser Artikel betrachtet drei praktische Abläufe, die unterschiedlichen Verfügbarkeiten und die Prüfaufgaben, die eine gemeinsame Leinwand verbessern, aber nicht automatisch erledigen kann.

Ein Prototyp läuft neben dem Design, das ihn erklärt

Eine Code Layer ist ein interaktiver Prototyp mit laufendem Code in einer Figma-Design-Datei. Menschen können Verhalten dort untersuchen, wo sie visuelle Alternativen vergleichen. Aus „Stellt euch diese Interaktion vor“ wird „Probiert diese beiden Versionen“, während das übrige Design sichtbar bleibt.

Der am 23. Oktober geprüfte Code-Layers-Leitfaden beschreibt Einstiege über Designframe, Prompt, erfasste Webseite, verbundenes Repository oder lokale Dateien. Teams können Code Layers duplizieren und Alternativen nebeneinander vergleichen. Einzelne Wege hängen weiterhin von Einführung und Repositorykompatibilität ab.

Ein beispielhaftes Produktteam prüft eine Registrierung. Eine Version kontrolliert die Einladung vor der Kontoerstellung, eine andere lässt zuerst Daten eingeben. Statische Frames lassen beide plausibel wirken. Ein laufender Prototyp zeigt Reihenfolge, Unterbrechung und verlorene Arbeit bei ungültiger Einladung.

Der Gewinn ist ein konkreteres Gespräch. Das Team entscheidet über passendes Verhalten, bevor die Entwicklung es auf die gesamte Anwendung überträgt. Der Prototyp ist ein prüfbarer Ausdruck einer Idee, kein Ersatz für die spätere Authentifizierungsimplementierung. Er ist wertvoll, weil er Uneinigkeit sichtbar macht, solange Richtungsänderungen günstig bleiben.

Specs gibt der Erklärung einen dauerhaften Ort

Figmas Specs-Ankündigung vom 15. Oktober beschreibt Markdown auf der Leinwand mit eingebetteten Verweisen auf Frames, Diagramme und weitere Figma-Inhalte. Das Dokument kann Entscheidungsgründe neben der visuellen Arbeit tragen. Diese Beziehung unterscheidet es von einem Screenshot in einem ansonsten unverbundenen Dokument.

Im Registrierungsbeispiel könnte eine Spezifikation festhalten, dass bei abgelaufener Einladung Eingaben erhalten bleiben, wer den Text verantwortet und welcher Fehlerzustand genehmigt ist. Solche Details fehlen leicht in „Baue diesen Bildschirm“. Ändert sich das Design, kann das Team direkt daneben fragen, ob auch die Regel geändert wurde.

Gemeinsamer Kontext ist nicht dasselbe wie korrekter Kontext. Ein für alle Kollegen und Agenten lesbares Dokument kann veraltete Entscheidungen sehr effizient verbreiten. Jemand muss weiterhin aktuelle Aussagen bestimmen, widersprüchliche Kommentare klären und offene Fragen markieren. Material zusammenzuführen verkürzt Wege, löst aber keine Widersprüche von selbst.

Das Risiko ist eine neue scheinbare Vollständigkeit. Eine ausgearbeitete Spezifikation mit Bildern wirkt verbindlich, auch wenn eine kritische Anforderung nicht genehmigt ist. Unterscheiden Sie knapp und ausdrücklich zwischen Entscheidungen, Annahmen und offenen Fragen. So erkennen Mitwirkende, welche Sätze die Umsetzung leiten und welche weitere Diskussion brauchen.

Eigene konzeptionelle Infografik. Designs, Specs und Code Layers enthalten unterschiedliche Informationen; Übereinstimmung erfordert weiterhin Prüfung.

Die Oktoberankündigung enthält mehrere Veröffentlichungsstände

Figma bündelt Fähigkeiten, die leicht zu einem Versprechen verschmelzen. Der Einführungsrückblick vom 15. Oktober unterscheidet offene Betas, eine geschlossene Beta und eine Vorschau. Teams können verfügbare Teile prüfen und die größere Systemvision von heutigen Werkzeugen trennen.

Auch der kommerzielle Zeitpunkt zählt. Laut Veröffentlichungshinweisen sind Erstellen und Bearbeiten innerhalb einer Code Layer in bezahlten Tarifen bis zum 4. November 2026 kostenlos. Das ist befristet und keine dauerhafte Preisaussage. Code Layers werden tarifübergreifend beschrieben, Specs wird in bezahlten Tarifen eingeführt. Vor einer Budgetplanung sollten Sitzplatz, Credits und aktuelle Tarifbedingungen geprüft werden.

Die Tabelle bietet auch eine sinnvolle Einführungsfolge. Teams können zunächst prüfen, ob gemeinsame Prototypen und Spezifikationen eine echte Prüfung verbessern, bevor eine unveröffentlichte Verwaltungsumgebung zur Abhängigkeit wird. Jede Komponente mit eigener Aufgabe und eigenem Status erleichtert die Bewertung.

Die Registrierung einschließlich Fehlerzuständen ausprobieren

Der erste praktische Fall ist eine Verhaltensprüfung vor der Implementierung. Wählen Sie einen Ablauf mit einer echten Entscheidung statt eines dekorativen Bildschirms, bei dem nur die Attraktivität offen ist. Registrierung eignet sich, weil Validierung, Laden, Fehler und Wiederherstellung das Erlebnis prägen.

Das folgende vorgeschlagene Vorgehen nutzt Figmas dokumentierte Einstiege und berichtet keine eigenen Praxisergebnisse:

1. Einen vorhandenen Frame wählen und das Nutzerziel daneben schreiben. Erfolgs-, Leer-, Lade- und Fehlerzustände vor dem laufenden Entwurf auflisten.
2. Frame auswählen und Code in der Werkzeugleiste wählen oder B drücken, dann Build selection verwenden. Das ist der dokumentierte Einstieg aus einem statischen Design.
3. Ein enges Verhalten anfordern: etwa Eingaben bei fehlgeschlagener Einladungsprüfung erhalten und eine klare Wiederholung anbieten. Der Prompt bleibt beim gewählten Ablauf.
4. Code Layer für eine tatsächlich andere Interaktion duplizieren. Beide laufenden Versionen am selben Szenario statt an unverbundenen Erfolgsfällen vergleichen.
5. Gewähltes Verhalten und Gründe in einer Spezifikation festhalten. Verworfene Alternativen aufnehmen, wenn sie eine sonst später übersehene Einschränkung erklären.
6. Geprüftes Design und Anforderungen in den normalen Implementierungsprozess geben. Tatsächliche Authentifizierung und Datenverarbeitung in der Anwendungsumgebung prüfen.

Das wichtige Ergebnis ist eine Entscheidung, gestützt auf etwas Ausprobierbares. Deckt der Prototyp Unsicherheit auf, bleibt sie besser offen in der Spezifikation, als für ein vollständiges Dokument eine Regel zu erfinden. Ein nützliches Werkzeug macht die offene Frage sichtbarer.

Ein Designsystem braucht Anweisungen und Komponenten

Das zweite Szenario ist die Pflege eines gemeinsamen Komponentensystems beim Erkunden eines neuen Bildschirms. Teams besitzen vielleicht genehmigte Schaltflächen, Abstandsregeln, Inhaltsmuster und Anforderungen an Barrierefreiheit. Ein Agent kann eine optisch plausible Alternative erzeugen, diese Investitionen unbemerkt umgehen und hinter attraktiver Vorschau Wartungsarbeit schaffen.

Figmas Oktoberupdate ergänzt Guidelines in veröffentlichten Bibliotheken und führt Code Sources als geschlossene Beta ein. Der Einführungsrückblick beschreibt sie als Wege, Agenten Muster und vorhandene Komponenten vorzugeben. Die Vorschau zentralisierter Designsysteme erweitert das auf Bibliotheken, Code und Richtlinien zusammen; sie darf aber nicht als heute universell verfügbar gelten.

Ein beispielhafter Versuch könnte ein Einstellungsformular mit einer etablierten Feldkomponente anfordern. Die Spezifikation benennt Pflichtkomponente, Aussage der Validierungsmeldungen und wesentliche Interaktionsregeln. Prüfer kontrollieren anschließend, ob die Implementierung die Komponente tatsächlich wiederverwendet oder nur ihr Aussehen nachahmt.

Dieser Unterschied hat Folgen. Zwei Bildschirme können gleich aussehen, während einer das Verhalten der gepflegten Komponente erbt und der andere eine neue unabhängige Implementierung trägt. Visuelle Konsistenz ist wertvoll; Implementierungskonsistenz bestimmt, welche künftigen Korrekturen weiterwirken. Die Leinwand hilft beim Vergleich, der Code braucht weiterhin einen systemkundigen Prüfer.

Guidelines verursachen ebenfalls Pflege. Eine Regel aus einer alten Bibliothek kann einer neuen Komponente widersprechen; ein langes Anweisungsdokument kann die entscheidende Ausnahme verbergen. Konkrete genehmigte Beispiele und klare Verantwortung sind besser als viele undatierte Vorlieben. Lassen Sie den Agenten verwendete Komponenten erklären, damit Prüfer einen Einstieg haben.

MCP bringt Kontext in den Editor und Änderungen zurück

Die am 23. Oktober geprüfte Figma-MCP-Dokumentation beschreibt Agenten, die Designkontext lesen und native Inhalte zurück auf die Leinwand schreiben. Der Remoteserver bietet laut Dokumentation die breiteste Funktionsunterstützung. Das Schreiben von Specs benötigt ihn sowie Bearbeitungszugang zur Datei; andere Aktionen haben eigene Sitzplatz- und Clientanforderungen.

So entsteht ein Rückweg. Ein Coding-Agent kann Anforderungen erhalten, bei der Implementierung eine Einschränkung entdecken und die gemeinsame Spezifikation aktualisieren helfen. Der Vorteil liegt in der Kontinuität zwischen Entscheidung und Code. Bleibt jede Erkenntnis im Editorchat verborgen vor dem restlichen Team, ist der Nutzen geringer.

Die Verbindung verändert auch die Rechtefrage. Ein Frame-lesendes und ein Spezifikation-bearbeitendes Werkzeug haben unterschiedliche Fähigkeiten. Vor dem Einschalten sollten Datei, beabsichtigte Aktion und genehmigungsberechtigte Personen feststehen. Eine bequeme Verbindung darf nicht jedes Projektdokument standardmäßig beschreibbar machen.

Nutzen Sie für den Versuch eine Datei und einen engen Auftrag. Der Agent liest die geprüfte Spezifikation, schlägt die Implementierungsänderung vor und hält offene Fragen sichtbar fest. Prüfen Sie das Zurückgeschriebene. Ziel ist die Erhaltung der Bedeutung im Hin- und Rückweg, nicht bloß ein erfolgreicher API-Aufruf.

Payload bringt echte Daten näher und echte Verantwortung mit

Das dritte Szenario ist eine kleine inhaltsgestützte Anwendung: Veranstaltungsverzeichnis, interner Katalog oder Kampagnenseite, die Mitarbeiter aktualisieren. Ein statischer Prototyp vermittelt Layout und lässt betriebliche Fragen offen. Ändert sich Inhalt täglich, wird der Bearbeitungsprozess Teil des Produkts.

Figmas Veröffentlichungshinweise vom 15. Oktober sagen, Make könne ein Payload-Backend mit CMS, Datenbank, Medien, APIs, Authentifizierung und Verwaltungsoberfläche erzeugen; Figma hostet die Einrichtung. Payload ist ein quelloffenes Inhaltsframework. Damit geht die Veröffentlichung über eine neue Zeichen- oder Promptmethode fürs Frontend hinaus. Payload im Figma-Ankündigungskontext.

Beim Veranstaltungsverzeichnis könnte ein Redakteur einen Eintrag über die Verwaltung aktualisieren, statt eine fest codierte Karte ändern zu lassen. Die Designdiskussion enthält dann echte Feldlängen, fehlende Bilder und Entwürfe. Solche Alltagsbedingungen verdecken sauber gestaltete Beispieldaten häufig.

Mit der Bequemlichkeit wächst Produktionsverantwortung. Wer darf veröffentlichen, welche Felder sind öffentlich, wie wird versehentliches Löschen rückgängig gemacht und was passiert bei geänderten Zugängen? Ein generiertes Backend bietet Platz für diese Entscheidungen, trifft sie aber nicht für die Organisation. Vor echten Einreichungen müssen die tatsächlichen Hosting- und Datenbedingungen geprüft werden.

Eigene Infografik. Der Übergang vom Prototyp zur Produktion ergänzt Implementierungs- und Betriebsentscheidungen; die Stufen sind Bewertungskriterien, keine gemessene Produktgarantie.

Schnellere Erkundung kann ungetroffene Entscheidungen aufstauen

Der Hauptvorteil ist, dass mehr Menschen Verhalten an einem konkreten Artefakt diskutieren können. Designer vergleichen laufende Alternativen, Produktmanager ergänzen Absichten und Entwickler benennen Einschränkungen vor der Veröffentlichung. Dieselbe Geschwindigkeit erzeugt aber womöglich viele Varianten, deren Status niemand mehr kennt.

Behandeln Sie jede Variante als Experiment mit einer Frage. „Verringert das Behalten der Eingaben nach diesem Fehler die Verwirrung?“ gibt Prüfern etwas zu untersuchen. „Fünf weitere Versionen erzeugen“ kann zur Erkundung dienen, braucht später aber eine Entscheidung darüber, was gelernt wurde. Sonst wird die Leinwand zum Warteraum für nie getroffene Entscheidungen.

Ein nützliches Teammaß ist die Zahl ungeklärter Entscheidungen, die die Implementierung erreichen. Verfolgen Sie einige normale Änderungen: Erhielt die Entwicklung klareres Verhalten, weniger widersprüchliche Verweise und einen verlässlichen Weg zum Verantwortlichen? Beachten Sie auch die Pflegezeit der Spezifikation. Gemeinsamer Kontext lohnt, wenn er Mehrdeutigkeit im gesamten Ablauf verringert.

Die sinnvolle Erwartung ist bescheiden und wirkungsvoll: Designs, schriftliche Gründe und laufendes Verhalten sollten leichter in Einklang bleiben. Betaqualität, Repositorygrenzen und Tarifbedingungen beeinflussen die konkrete Teamwirkung. Die Richtung verspricht Nutzen, weil sie das fehlende Gespräch zwischen Generierung und Produktion adressiert, wo vermeidbare Nacharbeit oft beginnt.

Die Leinwand kann Entscheidungen sichtbar halten

Code Layers machen eine Idee leichter ausprobierbar. Specs tragen ihre beabsichtigte Bedeutung weiter. Zusammen können sie die Gründe eines Designs neben dem Gebauten halten, sodass spätere Mitwirkende mehr erhalten als einen überzeugenden Screenshot.

Das nützliche Ziel ist Übereinstimmung, die die Implementierung übersteht. Beginnen Sie mit einem Ablauf, machen Sie unsicheres Verhalten sichtbar und halten Sie die Entscheidung bei der Arbeit. Erreicht das Team die Produktion mit weniger offenen Fragen, leistet die neue Leinwand mehr als einen weiteren Prototyp zu generieren.

---

Quellen

• Figma-Veröffentlichungshinweise, Config-India-Ankündigungen, 15. Oktober 2026; geprüft am 23. Oktober.
• Build by design: New workflows for new ways of building, 15. Oktober 2026.
• Code Layers in Figma Design, geprüft am 23. Oktober 2026.
• Introducing Specs: Markdown as a medium, 15. Oktober 2026.
• Figma-MCP-Serverdokumentation, geprüft am 23. Oktober 2026.
• Figma-Markenressourcen, geprüft am 23. Oktober 2026.

Die Gründe einer technischen Entscheidung aufbewahren

Wer Quellenlinks und geprüfte technische Notizen separat sammeln möchte, findet in Telli.sh eine Möglichkeit. Öffnen Sie Ihren Notizbereich.