23. Juli 2025·8 Min
Wie KI Layout und Absicht erkennt und Designs in UI‑Code verwandelt
Erfahre, wie KI aus Designs Layout, Hierarchie und Nutzerabsicht ableitet und daraus UI‑Code generiert — plus Grenzen, Best Practices und Prüftipps.
Erfahre, wie KI aus Designs Layout, Hierarchie und Nutzerabsicht ableitet und daraus UI‑Code generiert — plus Grenzen, Best Practices und Prüftipps.
„Design to code“‑KI übersetzt eine visuelle Designidee — normalerweise einen Figma‑Frame oder einen Screenshot — in ausführbaren UI‑Code. Es geht nicht um „perfekten Code“, sondern um einen brauchbaren ersten Entwurf, der Struktur, Styling und grundlegendes Verhalten einfängt, damit ein Mensch ihn verfeinern kann.
Im Kern bildet das System das Abzubildende auf die übliche UI‑Struktur ab.
Die KI kann gängige Muster erraten: eine Reihe von Icons ist wahrscheinlich eine Toolbar; ein gestapeltes Label + Input ist vermutlich ein Formularfeld; konsistente Styles deuten auf eine wiederverwendbare Komponente hin. Sie kann auch responsive Verhaltensweisen anhand von Constraints und Abständen schätzen.
Aber typischerweise müssen Sie angeben, was Pixel allein nicht garantieren: echte Komponenten‑Namen, Design‑Tokens (Farben/Typo‑Skalen), Zustände (Hover/Disabled/Error), Breakpoints, Datenregeln und tatsächliche Interaktionen (Validierung, Navigationsziele, Analytics).
Behandeln Sie das Ergebnis als Ausgangspunkt. Erwarten Sie, Struktur zu prüfen, Ad‑hoc‑Styles durch Tokens zu ersetzen, an Ihre Komponentenbibliothek anzupassen und iterativ zu verbessern. „Design to code“ beschleunigt — es ersetzt nicht das Design‑ und Engineering‑Urteil.
KI kann Produktregeln nicht aus einem „schönen Bildschirm“ ableiten. Sie arbeitet mit den Belegen, die Sie liefern — manche Eingaben beschreiben Pixel, andere Struktur. Dieser Unterschied bestimmt oft, ob Sie sauberen UI‑Code oder brüchige absolute Positionen erhalten.
Ein Screenshot ist die dünnste Eingabe: Er enthält Farben und Formen, aber keine expliziten Fakten darüber, was ein Button vs. ein Label ist, was wiederverwendbar ist oder wie das Layout sich anpassen sollte.
Aus reinen Pixeln muss die KI Grenzen erraten (wo ein Element endet und ein anderes beginnt), Textstile, Abstandsregeln und sogar, ob eine „Karte" ein Baustein oder mehrere separate Teile ist. Sie kann Constraints nicht ableiten — Responsivität bleibt meist Spekulation.
Wenn die KI auf die Designdatei zugreifen kann (oder einen strukturierten Export, der Struktur erhält), gewinnt sie wichtige Metadaten: Frames, Gruppen, Layer‑Namen, Auto‑Layout‑Einstellungen, Constraints und Text/Style‑Definitionen.
Hier wird Layout mehr als Geometrie. Ein Figma‑Frame mit Auto Layout kommuniziert z. B. „stapele diese Elemente vertikal mit 16px Abstand“ weit klarer als jeder Screenshot. Konsistente Layer‑Namen helfen außerdem, Elemente UI‑Rollen zuzuordnen (z. B. „Primary Button“, „Nav Item“, „Input/Error").
Ein angebundenes Design‑System reduziert Ratespiel. Tokens (Farben, Abstände, Typografie) lassen die KI Code erzeugen, der eine gemeinsame Quelle referenziert statt hartkodierter Werte. Verfügbare Komponenten (Buttons, Felder, Modals) bieten fertige Bausteine und klarere Grenzen für Wiederverwendung.
Schon kleine Konventionen — wie Variantenbezeichnungen (Button/Primary, Button/Secondary) und semantische Tokens (text/primary statt #111111) — verbessern das Komponenten‑Mapping.
Specs liefern das „Warum“ hinter der UI: Hover‑Verhalten, Lade‑ und Empty‑Zustände, Validierungsregeln, Tastaturverhalten und Fehlermeldungen.
Ohne das erzeugt die KI meist nur eine statische Momentaufnahme. Mit Specs kann die Ausgabe Interaktions‑Hooks, Zustandsbehandlung und realistischere Komponenten‑APIs enthalten — näher an dem, was ein Team ausliefern und pflegen kann.
Design‑to‑Code‑Tools nehmen einen Bildschirm nicht wie ein Mensch wahr; sie versuchen, jede Ebene als Layout‑Regel zu erklären: Reihen, Spalten, Container und Abstände. Je klarer diese Regeln sind, desto weniger verlässt sich die Ausgabe auf brüchige Positionierung.
Die meisten Modelle schauen nach wiederkehrender Ausrichtung und gleichen Lücken. Teilen mehrere Elemente dieselbe linke Kante, Grundlinie oder Mittellinie, behandelt die KI sie oft als Spalte oder Grid‑Spur. Konsistente Abstände (z. B. 8/16/24px) deuten darauf hin, dass Layout mit Stack‑Gaps, Grid‑Gutters oder tokenisiertem Spacing ausgedrückt werden kann.
Weicht der Abstand leicht ab (15px hier, 17px dort), kann die KI das Layout als „manuell“ einstufen und auf absolute Koordinaten zurückgreifen, um pixelgenaue Distanzen zu wahren.
Die KI sucht nach visuellen „Einschlüssen": Hintergründe, Ränder, Schatten und padding‑artige Lücken, die auf einen Container hinweisen. Eine Karte mit Hintergrund und innerem Abstand ist ein klares Signal für ein Elternelement mit Kindern.
Von dort mappt sie Struktur oft auf Primitive wie:
Saubere Gruppierung in der Designdatei hilft, Eltern von Geschwistern zu unterscheiden.
Enthält das Design Constraints (Pinning, Hugging, Fill), nutzt die KI diese, um zu entscheiden, was sich streckt und was fix bleibt. „Fill“‑Elemente werden typischerweise flexibel (z. B. flex: 1), während „hug“ auf inhaltsgroße Elemente abbildet.
Absolute Positionierung erscheint meist, wenn das Modell Beziehungen nicht sicher mit Flow‑Layouts ausdrücken kann — oft wegen inkonsistenter Abstände, überlappender Layer oder fehlender Ausrichtung. Sie kann bei einer Bildschirmgröße korrekt wirken, aber Responsivität und Textgrößenanpassung zerstören.
Eine kleine Abstands‑Skala und ein klares Grid erhöhen die Chance, dass die KI sauberen Flex/Grid‑Code produziert statt Koordinaten. Konsistenz ist nicht nur ästhetisch — sie ist maschinenlesbares Muster.
KI „versteht“ Hierarchie nicht im menschlichen Sinn; sie leitet Wichtigkeit aus Mustern ab, die typischerweise darauf hinweisen. Je klarer Ihr Design diese Signale kommuniziert, desto wahrscheinlicher ist es, dass die generierte UI Ihrer Absicht entspricht.
Typografie ist einer der stärksten Hinweise. Größere Schrift, stärkeres Gewicht, höherer Kontrast und großzügigere Zeilenhöhe signalisieren normalerweise höhere Priorität.
Beispiel: Eine 32px fette Überschrift über einem 16px regulären Absatz ist ein klares „Heading + Body“‑Muster. Schwieriger wird es, wenn Stile kaum abweichen — z. B. 1–2px Unterschied oder gleiche Gewichtung mit unterschiedlicher Farbe. Dann könnte die KI beide als normalen Text kennzeichnen oder das falsche Überschriftenniveau wählen.
Hierarchie wird auch aus räumlichen Beziehungen abgeleitet. Elemente, die näher beieinander sind, ausgerichtet und durch Weißraum von anderem Inhalt getrennt, werden als Gruppe behandelt.
Gemeinsame Hintergründe (Cards, Panels, getönte Bereiche) wirken wie visuelle Klammern: Die KI interpretiert sie oft als Container wie section, aside oder ein Component‑Wrapper. Ungleichmäßiges Padding oder inkonsistente Abstände können zu versehentlicher Umgruppierung führen — z. B. wenn ein Button an die falsche Karte angehängt wird.
Wiederkehrende Muster — identische Karten, Listeneinträge, Reihen oder Formularfelder — sind starke Hinweise auf wiederverwendbare Komponenten. Schon kleine Unterschiede (Icon‑Größe, Radius, Textstil) können die KI dazu bringen, mehrere Einmal‑Versionen statt einer Komponente mit Varianten zu generieren.
Buttons kommunizieren Absicht durch Größe, Füllung, Kontrast und Position. Ein ausgefüllter Button mit starkem Kontrast wird normalerweise als primäre Aktion behandelt; Outlined‑ oder Text‑Buttons werden sekundär. Wenn zwei Aktionen gleich betont aussehen, kann die KI erraten, welche primär ist — und dabei falsch liegen.
Schließlich versucht die KI, Hierarchie in Semantik zu übersetzen: Überschriften (h1–h6), gruppierte Bereiche (section) und sinnvolle Cluster (z. B. „Produktdetails“ vs. „Kaufaktionen“). Klare typografische Schritte und konsistente Gruppierung machen diese Übersetzung deutlich zuverlässiger.
Modelle sagen Intent voraus, indem sie Gesehenes mit Mustern aus vielen UIs abgleichen: gängige Formen, Labels, Iconografie und Platzierungs‑Konventionen.
Bestimmte Anordnungen deuten stark auf spezifische Komponenten hin. Ein horizontaler Streifen oben mit Logo links und Textlinks rechts ist wahrscheinlich eine Navigation. Eine Reihe gleich breiter Items mit einem hervorgehobenen Item wird oft zu Tabs. Wiederholte Boxen mit Bild, Titel und kurzem Text lesen sich als Karten. Dichte Grids mit ausgerichteten Headern und Zeilen werden zu Tabellen.
Diese Annahmen beeinflussen Struktur: Ein „Tab“ impliziert ausgewählten Zustand und Tastaturnavigation, während eine „Reihe von Buttons" dies nicht tut.
Die KI sucht nach Hinweisen, die üblicherweise Interaktion kennzeichnen:
Dann weist sie Verhaltensweisen zu: Klick, Menü öffnen, navigieren, submitten, expand/collapse. Je deutlicher das Design interaktive von statischen Elementen unterscheidet, desto genauer die Ausgabe.
Zeigt das Design mehrere Varianten — Hover, Active/Selected, Disabled, Error, Loading — kann die KI sie auf zustandsbehaftete Komponenten abbilden (z. B. disabled Buttons, Validationsmeldungen, Skeleton‑Loader). Sind Zustände nicht explizit, lässt sie sie meist weg.
Ambiguität ist häufig: Ist eine Karte klickbar oder informativ? Ist ein Chevron dekorativ oder ein Disclosure‑Control? In solchen Fällen klären Sie per Naming, Annotation oder separaten Frames, die die Interaktion demonstrieren.
Hat die KI eine plausible Lesart von Layout, besteht der nächste Schritt darin, „wie es aussieht“ in „was es ist“ zu übersetzen: semantisches HTML, wiederverwendbare Komponenten und konsistentes Styling.
Die meisten Tools mappen Design‑Layer und Gruppen in einen DOM‑Baum: Frames werden zu Containern, Text‑Layer zu Überschriften/Absätzen und wiederkehrende Items zu Listen oder Grids.
Ist die Intention klar, kann die KI bessere Semantik anhängen — z. B. wird eine Top‑Bar zu einem <header>, Logo und Links zu einem <nav>, und eine klickbare Karte zu einem <a> oder <button>. ARIA‑Rollen lassen sich manchmal ableiten (wie role='dialog' für ein Modal), aber nur bei eindeutigem Muster; sonst ist sicherere Ausgabe reines HTML plus TODOs für Accessibility‑Review.
Um nicht eine riesige Datei zu erzeugen, versucht die KI, die UI in Primitive zu schneiden:
Wiederkehrung, konsistentes Padding/Typografie und gruppierbarer Klickbereich sind Signale für eine Komponente. Fehlerquellen sind Über‑Fragmentierung (zu viele winzige Komponenten) oder Unter‑Fragmentierung (alles einmalig hardcodiert).
Der Generator wählt meist einen Ansatz basierend auf Ziel‑Stack oder Defaults:
Hochwertige Ausgabe nutzt Design‑Tokens — Farben, Abstände, Radius, Schatten — sodass Code konsistent bleibt, wenn das Design sich verändert. Ein striktes Pixelmatching führt oft zu One‑off‑Werten (z. B. 13px Abstände, fast identische Grautöne), die zwar richtig aussehen, aber schwer wartbar sind.
Praktischer Kompromiss: Bewahren Sie Hierarchie und Abstandsrhythmus, normalisieren Sie dann in Tokens und wiederverwendbare Komponenten und refaktorisieren Sie in der Review‑Phase weiter (siehe /blog/how-to-review-and-refactor-generated-ui-code).
Designdateien sehen oft „fertig“ aus, weil sie bei ein paar festen Frame‑Größen gezeichnet sind (z. B. 1440 und 375). Code darf das nicht voraussetzen. Ein Design‑to‑Code‑Tool muss entscheiden, wie die UI zwischen Breiten reagiert, mithilfe von Hinweisen und Defaults.
Enthält Ihr Design mehrere Versionen derselben Seite (Desktop/Tablet/Mobil) und ist die Struktur konsistent, kann die KI sie ausrichten und erkennen, wo Layoutregeln wechseln. Ohne Varianten fällt sie meist auf gängige Breakpoints zurück und behandelt die Frame‑Größe als „Basis“, was zu holprigen Sprüngen führen kann.
Die KI erkennt Muster: wiederkehrende Karten in einem Grid, gleiche Abstände, Ausrichtung. Daraus kann sie ableiten, dass ein 3‑Spalten‑Grid zu 2 Spalten und dann zu 1 Spalte wird. Probleme entstehen, wenn das Design auf manuellen Nudges basiert — Elemente sehen ausgerichtet aus, sind es aber nicht wirklich — denn die KI kann nicht entscheiden, ob das Absicht war.
Die meisten Designs verwenden kurze, ordentliche Texte. In echten Produkten ist das anders. KI‑generierter UI‑Code setzt oft fixe Breiten/Höhen oder kürzt zu aggressiv.
Ein kurzer Test:
Die KI kann den pixelgenauen Zuschnitt aus dem Design übernehmen, aber responsive UIs brauchen Regeln: Seitenverhältnis beibehalten, entscheiden wie gezoomt/gekürzt wird und wann Bilder herunter skaliert oder neu positioniert werden. Fehlt die Spezifikation, erwarten Sie ein „fill“‑Verhalten, das wichtige Bereiche zuschneidet.
Bevor Sie der Ausgabe vertrauen, prüfen Sie in sehr kleinen Breiten, auf sehr großen Monitoren und auf Zwischenbreiten. Überschneidet sich etwas, wird abgeschnitten oder unleserlich, ist meist Layout‑Intent unklar — nicht „schlechter Code“ — und ein Signal, die Constraints im Design zu präzisieren.
KI kann Pixel überraschend gut in UI‑Code übersetzen, aber Barrierefreiheit ist oft der Punkt, an dem „sieht gut aus" nicht mit „funktioniert für alle“ übereinstimmt. Viele Anforderungen sind nicht in einem statischen Frame sichtbar; das Modell braucht explizite Signale.
Einige barrierefreundliche Entscheidungen sind sichtbar und lassen sich oft in besseres HTML übertragen:
Andere Anforderungen sind nicht sichtbar:
Erwarten Sie Lücken wie fehlende label/for‑Verknüpfungen, falsche Überschriftenebenen, klickbare <div>s ohne Tastaturunterstützung, schwache Fokus‑Styles und Icons ohne Textalternative.
h1 → h2 → h3).header, nav, main, footer) und sind nicht dupliziert.alt‑Attribute (oder alt='' wenn dekorativ).Fügen Sie eine kurze Spec bei Modals, Drawern, komplexen Formularen, Custom Selects, Drag‑and‑Drop oder allem mit nicht trivialen Zuständen hinzu. Schon ein paar Notizen wie „trap focus in modal“, „Esc schließt“ und „inline errors werden angekündigt“ verbessern den generierten Code erheblich.
KI kann UI‑Code erzeugen, der auf den ersten Blick nah dran ist, aber kleine Interpretationsfehler summieren sich schnell. Die meisten Probleme entstehen durch „vernünftige Annahmen“, wenn das Design Regeln nicht klar codiert.
Häufige Beschwerde: Abstände passen nicht — Buttons wirken leicht versetzt, Sektionen atmen zu viel oder Karten sind gedrängt. Das passiert, wenn Padding bei ähnlichen Elementen inkonsistent ist oder Auto‑Layout/Constraints mit manuellen Nudges gemischt wurden. Das Modell kann ein Muster (z. B. „überall 16px“) inferieren und Ausnahmen überschreiben — oder versehentliche Ausnahmen beibehalten.
Generierter Markup hat oft zu viele Wrapper. Jede visuelle Gruppierung wird zu einem weiteren <div>. Das macht Styling, Debugging und manchmal Rendering schwieriger. Sie merken es, wenn eine einfache Karte fünf geschachtelte Container hat, nur um ein Icon und einen Titel auszurichten.
Die KI kann Komponenten zu granular aufsplitten (jedes Label eine Komponente) oder zu monolithisch bleiben (ganzer Screen als eine Komponente). Ursache sind unklare Grenzen: Sind wiederkehrende Muster nicht identisch, kann das Modell keine gemeinsame Komponente extrahieren.
Typografie driftet oft, weil Design‑Textstile nicht sauber auf Code abgebildet werden. Subtile Unterschiede in Zeilenhöhe, Letterspacing oder Gewicht gehen verloren, und Fallback‑Fonts ändern Metriken zwischen Umgebungen. Daher bricht eine Überschrift, die in Figma passt, plötzlich im Code um.
Fehlen Hover, Focus, Error, Loading oder Empty im Design, erfindet die KI sie selten. Die UI schaut im statischen Screenshot korrekt aus, versagt jedoch sobald Nutzer interagieren.
KI‑Generatoren „sehen“ Ihr Design nicht wie ein Mensch — sie lesen eine strukturierte Datei voller Layers, Constraints, Styles und Instanzen. Je sauberer die Struktur, desto weniger muss das Modell raten (und desto weniger merkwürdigen Div‑Soup müssen Sie später aufräumen).
Layer‑Namen sind eines der stärksten Intent‑Signale und helfen beim Komponenten‑Mapping. Bevorzugen Sie konsistente, beschreibende Muster, die zu Ihrer Bauweise passen:
Button/Primary, Button/SecondaryCard/Product, Card/ArticleForm/Input/Text, Form/CheckboxVermeiden Sie Namen wie „Rectangle 12“ oder „Group 5“ — das drängt die KI zu generischen Wrappern statt zu wiederverwendbaren Komponenten.
Manuelles Positionieren führt oft zu absoluten Koordinaten im Code. Wenn Sie Flex/Grid‑Output wollen, sollte Ihr Design wie Flex/Grid funktionieren:
Wenn das Design im Tool gut reagiert, ist die generierte UI viel eher standardmäßig responsive.
Einzelne Farben, Font‑Sizes und Abstände fördern One‑off‑CSS. Stattdessen:
Das erhöht Konsistenz und erleichtert spätere Refaktorisierung zu einem Design‑System.
KI kann nicht inferieren, was sie nicht findet. Ergänzen Sie wichtige Varianten wie Hover/Pressed/Disabled, Error‑Zustände für Inputs, Loading‑ und Empty‑States.
Wenn Verhalten zählt, annotieren Sie kurz: „öffnet Modal“, „server‑validiert“, „zeigt Toast bei Erfolg“. Eine einzige Zeile neben einer Komponente kann falsches Interaktionsverhalten verhindern.
Wenn Sie Team‑Workflow standardisieren, halten Sie Konventionen in einer leichten Checkliste fest und verlinken intern (z. B. /blog/design-to-code-checklist).
KI‑generierter UI‑Code ist am besten als erster Entwurf zu behandeln: Er kann Stunden sparen, braucht aber einen menschlichen Durchgang, damit UI korrekt funktioniert, wartbar bleibt und Produktstandards erfüllt.
Lesen Sie zuerst das Markup wie ein Screenreader.
<h1>, dann logische <h2>/<h3>).<ul>/<ol>) und nicht nur gestapelte <div>s.Ist die Semantik falsch, hilft kein CSS.
Viele Generatoren setzen auf absolute Positionierung oder tief verschachtelte Wrapper, um den Screenshot zu matchen. Das bricht oft bei Content‑Änderungen.
Bevorzugen Sie Flex/Grid statt Koordinaten und reduzieren Sie Verschachtelung, bis jeder Wrapper einen klaren Zweck hat (Layout‑Gruppe, Abstand, Komponenten‑Boundary). Sehen Sie wiederholte style={{ left, top, width, height }}‑Muster, bearbeiten Sie diesen Bereich zuerst.
Suchen Sie nach wiederkehrenden Mustern (Cards, Input‑Zeilen, Nav‑Items) und machen Sie daraus wiederverwendbare Komponenten. Ersetzen Sie dann harte Werte durch Tokens: Spacing, Radius, Typografie und Farben. Stimmen Sie auf vorhandene Team‑Guides ab oder starten Sie mit einem minimalen Set und erweitern es schrittweise (siehe /blog/design-tokens).
Kein großes Test‑Setup nötig:
Generatoren raten Intent. Halten Sie Änderungen (Interaktionsregeln, Breakpoints, Komponenten‑Mapping) fest, damit künftige Generationsläufe oder Entwickler sie nicht rückgängig machen.
„Design to code“ funktioniert am besten, wenn Sie es als Beschleuniger behandeln, nicht als Autopiloten. Die schnellsten Teams wählen einen Workflow, der zur Reife ihres Design‑Systems und zum Risiko des Screens passt.
1) KI‑Assist im Design‑Tool (z. B. Figma‑Plugins): Gut, um nahe an der Quelldatei zu bleiben. Schnell beim Scaffolding während Designer iterieren; leichter, Namen, Komponenten und Tokens im File konsistent zu halten.
2) Externe Konverter (Upload/Export → Code): Nützlich für wiederholbare Pipelines über viele Dateien oder Teams. Oft schneller für Massenkonvertierung, aber der Cleanup von Struktur und Interaktionen kostet mehr Zeit.
In der Praxis kombinieren viele Teams Design‑to‑Code mit einem umfassenderen „Spec to shipped app“‑Flow. Plattformen wie Koder.ai gehen weiter: Sie verwandeln Intent in Implementierung und erweitern das Prinzip über UI‑Scaffolding hinaus — Feature‑Beschreibung im Chat, React‑Frontends mit Go/PostgreSQL Backends (und Flutter für Mobile), Planning‑Mode, Snapshots, Rollback und Source‑Code‑Export, wenn Integration in ein bestehendes Repo nötig ist.
KI glänzt bei:
Vorsicht bei:
Behandeln Sie jede Generierung als Entwurf: Review, dokumentieren wiederkehrender Probleme (Naming, fehlende Zustände, falsche Semantik), Prompt/Spec und Design‑Konventionen anpassen. Über ein paar Runden verbessert sich die Qualität oft deutlich.
Führen Sie ein kleines Pilotprojekt durch und bewerten Sie Ergebnis nach: Layout‑Fidelity, Komponentenwiederverwendung, Responsivität, grundlegende Accessibility und Refaktorierungsaufwand. Beim Vergleich von Tools und Plänen prüfen Sie /pricing.
Es ist eine KI‑unterstützte Übersetzung einer visuellen UI (Figma‑Frame, Design‑Export oder Screenshot) in ausführbaren UI‑Code. Ziel ist ein belastbarer erster Entwurf — Layout, Rhythmus der Stile und grundlegende Struktur — damit ein Entwickler daraus Tokens, Komponenten und produktionsreife Semantik herausarbeiten kann.
Gewöhnlich übersetzt sie:
Pixel allein kodieren nicht alles. Meistens müssen Sie angeben oder bereitstellen:
Ein Screenshot ist die dünnste Eingabe: Er liefert Farbe und Geometrie, aber keine explizite Struktur (Layer, Constraints, Komponenten). Rechnen Sie mit mehr geratenen Annahmen, mehr absoluter Positionierung und weniger wiederverwendbarem Code.
Eine Figma/Sketch‑Datei oder strukturierter Export liefert Frames, Layer‑Namen, Auto‑Layout, Constraints und Stile — Signale, die sauberere Flex/Grid‑Layouts und präzisere Komponenten‑Grenzen ermöglichen.
Die KI sucht nach wiederkehrender Ausrichtung und konsistenten Abständen, um die UI als Flex/Grid‑Regeln auszudrücken. Wenn sie ein klares Abstands‑Rhythmus (z. B. 8/16/24) findet, kann sie stabile Stacks und Grids generieren.
Sind Abstände inkonsistent oder Elemente leicht verschoben, greift das Modell oft auf absolute Koordinaten zurück, um das exakte Aussehen zu bewahren — auf Kosten der Responsivität.
Sie sucht nach visuellen Einschluss‑Signalen:
Saubere Gruppierung und konsistente Struktur im Design‑Tool (Frames, Auto‑Layout) macht Eltern/Kind‑Beziehungen viel leichter reproduzierbar.
Absolute Positionierung taucht auf, wenn Beziehungen unklar sind — Überlappungen, inkonsistente Abstände, manuelle Verschiebungen oder fehlende Gruppierung. Sie kann auf einer Bildschirmgröße korrekt aussehen, bricht aber leicht bei:
Wenn Sie flexibles Ergebnis wollen, lassen Sie das Design wie Flex/Grid wirken (Auto Layout, Constraints).
Die KI leitet Hierarchie aus visuellen Hinweisen ab:
Differieren Stile nur um 1–2px oder sind die Schritte unklar, kann sie die falsche Überschriftsebene wählen oder Überschriften als normalen Text behandeln.
Die KI schätzt Interaktivität aus Affordanzen:
Wenn etwa eine Karte klickbar oder nur informativ sein könnte, sollten Sie das annotieren oder eine Variante zeigen; sonst kann das Modell falsche Verhaltensweisen verdrahten oder sie weglassen.
Beginnen Sie damit, das Markup wie ein Screenreader zu lesen.
<h1>, dann logische <h2>/<h3>).<ul>/<ol>) und nicht gestapelte <div>s.Wenn die Semantik falsch ist, rettet kein CSS Barrierefreiheit oder Bedienbarkeit.