Die Layout-Ebene, die der Canvas früher verbarg

Eine nützliche Community-Antwort verlangt nicht nach einem größeren Button. Sie benennt die fehlende Ebene.

Genau das geschah unter der Open Design 0.8.0-preview-Diskussion. Der Launch-Thread plädierte für zwei Verschiebungen: den Canvas nicht länger als primäre Arbeitseinheit zu behandeln und den Agenten zum erstklassigen Design-Arbeiter zu machen. Eine Antwort stimmte der Richtung zu und zeigte dann auf den schwierigen Teil: Wenn der Canvas verschwindet, brauchen Nutzer weiterhin eine Möglichkeit zu verstehen, was der Agent erstellt hat, bevor sie es mit Zuversicht bearbeiten können.

Die Formulierung in der Antwort lautete „Layout Understanding Layer“. Das ist ein guter Name, weil er die bequeme Antwort verweigert. Agent-natives Design kann nicht bedeuten, „dem Screenshot zu vertrauen“. Es braucht ein lesbares Modell des Artefakts: Abschnitte, Intention, bearbeitbare Teile, stabile Referenzen und vorgeschlagene Bearbeitungsschritte. Dieser Beitrag ist ein Versuch, diese Antwort ernst zu nehmen — zu skizzieren, was eine solche Ebene tragen könnte, wo sie in Open Design angesiedelt sein sollte und warum sie ein Beitragspfad ist und kein Roadmap-Versprechen.

Der Canvas gab Designern räumliche Zuversicht

Figmas Canvas ist nicht nur eine Zeichenfläche. Er ist auch eine Erklärungsfläche. Man kann herauszoomen, die Seitenhierarchie sehen, einen Frame anklicken, Constraints inspizieren, Ebenen umbenennen und verstehen, wo ein Teil der Arbeit endet und ein anderer beginnt.

Was man tatsächlich verliert, wenn der Canvas verschwindet

Dieses Verständnis lässt sich leicht unterschätzen, bis es weg ist. Eine generierte Landingpage kann in einer abgeschotteten Vorschau korrekt aussehen und trotzdem schwer zu steuern sein. Das Problem sind nicht die Pixel — es ist das Fehlen eines gemeinsamen Vokabulars zwischen Mensch und Agent.

„Mach den Hero selbstbewusster“ ist nur nützlich, wenn Agent und Mensch sich einig sind, was der Hero ist. „Strafft den Pricing-Abschnitt“ funktioniert nur, wenn das Artefakt über Revisionen hinweg eine stabile Abschnittsidentität trägt. Ohne sie verkommt jede Anweisung zum Zeigen: Der Designer beschreibt eine Region über ihre Position („der zweite Block von oben“), der Agent rät anhand der gerenderten Ausgabe, und die nächste Neugenerierung nummeriert klammheimlich alles um. Der Canvas absorbierte diese Kosten früher stillschweigend. Er benannte die Teile für einen, hielt diese Namen während der Arbeit stabil und ließ einen davon auswählen, ohne ihn beschreiben zu müssen.

Die Klarheit lohnt sich, selbst wenn die Einheit falsch ist

Das ist der Teil des #DeFigma-Arguments, der Sorgfalt verlangt. Der Canvas mag die falsche Arbeitseinheit für ein Agent-natives System sein — er setzt einen Menschen voraus, der Rechtecke zieht, nicht einen Agenten, der Dateien schreibt —, aber die Klarheit, die Menschen aus dem Canvas zogen, ist weiterhin wertvoll. Der Fehler wäre, „den Canvas fallen lassen“ und „das vom Canvas gelieferte Verständnis fallen lassen“ als dieselbe Entscheidung zu behandeln. Das sind sie nicht. Open Design muss diese Klarheit in das Artefaktmodell verlagern, nicht wegwerfen. Die Layout-Ebene ist der Name für diese Verlagerung.

Open Design hat bereits die richtigen Primitive

Der Grund, warum dieser Vorschlag zu Open Design passt, ist, dass das Projekt bereits um explizite Verträge herum gebaut ist. Eine Skill ist eine SKILL.md-Datei. Ein Design-System ist eine DESIGN.md-Datei. Ein Plugin fügt ein open-design.json-Sidecar hinzu. Nichts im System ist ein binärer Blob, den man rückentwickeln muss; die Verträge sind Text, und Text ist etwas, das sowohl ein Agent als auch ein Mensch lesen kann. Die Mechanik wird in 31 skills, 72 systems: how the Open Design library works behandelt, und das Produktargument steht in Why we built Open Design as a skill layer, not a product.

Die Layout-Ebene sollte demselben Muster folgen. Sie sollte Text sein, den der Agent lesen kann, Zustand, den die UI rendern kann, und Metadaten, die ein anderer Agent wiederverwenden kann. Wenn sie nicht alle drei zugleich erfüllen kann, hat sie die falsche Form.

In Repo-Begriffen verweist das auf drei Flächen:

Fläche	Was sie tragen sollte
Artefakt-Manifest	Stabile IDs für Abschnitte, Komponenten, Assets und generierte Dateien
Plugin-Snapshot	Welche Skill, welches Design-System, welche Eingaben und welche Pipeline-Stufen das Artefakt erzeugt haben
Review-UI / Headless-Ausgabe	Eine Layout-Karte, bearbeitbare Aspekte und vorgeschlagene Bearbeitungsintentionen

Die wichtige Einschränkung: Die Ebene sollte nicht zu einem zweiten proprietären Canvas werden. Der zu vermeidende Fehlermodus ist, Figmas Szenengraph unter einem neuen Namen wiederaufzubauen — eine reichhaltige, app-spezifische Struktur, die nur die Open Design UI rendern kann und die in dem Moment stirbt, in dem man die App verlässt. Die Layout-Ebene sollte stattdessen eine schlichte Artefaktkarte sein, die mit den Dateien reist, sodass ein Beitragender sie in einem Texteditor lesen und ein anderer Agent sie ohne SDK konsumieren kann.

Ein Wireframe-Layout-Skelett, das sich als eigene auswählbare Ebene über einem leeren Canvas heraushebt, in einem grünen Rahmen auf einem fast weißen redaktionellen Untergrund — Die Layout-Ebene ist die Struktur, die der Canvas implizit hielt — herausgezogen an einen Ort, an dem ein Agent und ein Mensch sie beide lesen können.

Eine praktische Form für die Layout-Ebene

Hier ist die kleinste Version, die Agent-natives Design weniger undurchsichtig wirken ließe:

Jedes generierte Artefakt erhält stabile semantische IDs: hero, proof-strip, pricing, faq, final-cta.
Jede ID trägt einen Intentionssatz: „Erkläre das Produktversprechen auf einem Bildschirm“, nicht „oberer Abschnitt“.
Jeder Abschnitt listet bearbeitbare Aspekte auf: Text, Dichte, Layout, Farbe, Medien, Bewegung, Datenquelle.
Jede generierte Datei verweist zurück auf die Abschnitts-ID, die sie erzeugt hat.
Jeder Review-Durchgang gibt vorgeschlagene Bearbeitungsintentionen aus: „Hero-Überschrift kürzen“, „Kontrast in den Pricing-Karten erhöhen“, „Testimonial-Block aufteilen“.
Die UI rendert dies als Navigator, während Headless-Nutzer dieselbe Struktur als JSON oder Markdown erhalten.

Wie ein Manifest tatsächlich aussehen könnte

Der Sinn, es niederzuschreiben, ist, dass die Struktur unspektakulär ist — was genau der Grund ist, warum sie ein öffentlicher Vertrag statt eines privaten Tricks sein kann. Ein Manifest für eine generierte Landingpage könnte so aussehen:

{
  "artifact": "landing/index.html",
  "producedBy": { "skill": "magazine-poster", "system": "linear", "stage": "compose" },
  "sections": [
    {
      "id": "hero",
      "intent": "Explain the product promise in one screen",
      "editable": ["copy", "density", "media"],
      "files": ["landing/index.html#hero", "landing/hero.css"]
    },
    {
      "id": "pricing",
      "intent": "Let a visitor self-select a plan without scrolling back",
      "editable": ["copy", "layout", "data-source"],
      "files": ["landing/index.html#pricing", "landing/pricing.json"]
    }
  ],
  "suggestedEdits": [
    { "target": "hero", "intent": "shorten headline to one line" },
    { "target": "pricing", "intent": "drop from three plans to two" }
  ]
}

Keiner dieser Schlüssel ist exotisch. sections ist eine Liste, editable ist ein Enum, files ist eine Rückreferenz. Der Wert liegt nicht in der Cleverness des Schemas — er liegt in der Tatsache, dass die IDs eine Neugenerierung überleben, sodass derselbe pricing-Block auch nach zwei Umschreibungen durch den Agenten noch pricing ist.

Das reicht aus, damit ein Designer sagen kann: „Ändere pricing von drei Plänen auf zwei“, und es reicht aus, damit ein Code-Agent die richtige Datei patchen kann, ohne aus Pixeln zu raten. Die Anweisung löst sich zu einer Abschnitts-ID auf, die Abschnitts-ID löst sich zu einer Menge von Dateien auf, und die Bearbeitung landet dort, wo sie gemeint war.

Warum dies ein Beitragspfad ist, kein Feature-Request

Es gibt der Community außerdem einen sauberen Beitragspfad. Ein Beitragender muss das Produkt nicht neu entwerfen, um hier zu helfen. Er kann eine Skill schreiben, die ein Manifest für einen Artefakttyp ausgibt, ein Review-Atom, das Bearbeitungsintentionen vorschlägt, eine Manifest-Erweiterung, die ein Feld hinzufügt, das andere Skills lesen können, oder einen Testfall, der sicherstellt, dass Abschnitts-IDs über eine Neugenerierung hinweg stabil bleiben. Jede davon ist eine kleine, mergebare Änderung, die eine Ausgabe weniger undurchsichtig macht — und weil die Ebene schlichter Text ist, müssen sich zwei Beitragende, die an einem Deck und einem Mobile-Screen arbeiten, nicht auf ein gemeinsames Binärformat abstimmen. Die Layout-Ebene wird zu einem öffentlichen Vertrag, nicht zu einer privaten, tief in der App vergrabenen Fähigkeit.

Was als Nächstes zu tun ist

Wenn dies die Art von Problem ist, an der du arbeiten möchtest, trag eine kleine Skill oder ein Plugin bei, das ein Artefakt leichter inspizierbar macht. Beginne mit einer konkreten Ausgabe: einer Landingpage, einem Deck oder einem Mobile-Screen. Füge stabile Abschnitts-IDs hinzu, beschreibe die bearbeitbaren Aspekte, gib sie als JSON oder Markdown neben dem Artefakt aus und öffne den PR mit einem Vorher-/Nachher-Artefakt, damit ein Reviewer den Unterschied sehen kann, den eine inspizierbare Ebene macht.

Das ist immer noch eine Richtung, kein ausgeliefertes Feature — der Wert, es jetzt zu benennen, liegt darin, dass die Primitive bereits existieren, sodass die Arbeit additiv ist statt eines Neuschreibens.

Trag eine Skill bei.

Weiterführende Lektüre

31 skills, 72 systems: how the Open Design library works — die aktuellen dateigetriebenen Primitive, die dem Vorschlag zugrunde liegen
Why we built Open Design as a skill layer, not a product — die Produktform, die öffentliche Artefaktverträge möglich macht
The open-source alternative to Figma — wo „den Canvas fallen lassen“ gegen den Platzhirsch landet, der den Canvas zentral machte