Lerne, wie du mit Design‑Tokens und Komponenten‑/Formularregeln konsistente UI in React‑Apps erzielst, sodass KI‑generierte Screens Abstände, Typografie und Formulare einheitlich darstellen.
UI‑Inkonsistenzen fallen meist in kleinen Details auf, die sich beim Durchklicken merkwürdig anfühlen. Eine Seite hat großzügiges Padding, eine andere wirkt gedrängt. Überschriften springen in der Größe, Buttons ändern Form und Farbe, und dasselbe Input verhält sich je nach Screen unterschiedlich.
Meist entsteht das Drift durch ein paar grundlegende Dinge:
Das ist typisch, wenn Screens aus separaten Prompts generiert werden. Jeder Prompt ist effektiv ein Neustart, sodass das Modell fehlende Entscheidungen errät. Selbst „nutze modernes Styling“ lässt hunderte kleine Entscheidungen offen: 8px vs. 12px Gaps, 14px vs. 16px Body‑Text, wann Fehler gezeigt werden, wie ein Primary‑Button aussieht.
Du kannst zwei oder drei Seiten manuell nachbessern, aber das skaliert nicht. Du jagst One‑Off‑CSS‑Tweaks, kopierst Styles zwischen Dateien und reparierst Formulare immer wieder. Die Regeln existieren im Kopf, nicht im Projekt.
Stell dir vor, du generierst heute einen Login‑Screen und morgen einen Profil‑Screen. Wenn der eine Fehler nur beim Submit zeigt und der andere beim Blur, bemerken Nutzer es. Wenn die Höhe des Primary‑Buttons zwischen Screens wechselt, wirkt die App geflickt.
Konsistenz wird zur Norm, wenn jede Seite dem gleichen geteilten System folgt: Design‑Tokens (Abstand, Typo, Farbe) plus eine kleine Menge an Komponenten‑ und Formularregeln.
Design‑Tokens sind einfache benannte Werte, die du im UI wiederverwendest. Anstatt auf jeder Seite nach „komfortablem Padding“ zu fragen, verwendest du ein Token wie space-4. Statt „leicht gerundet“ nimmst du radius-md. Der Name bleibt stabil, auch wenn die Zuordnung später verändert wird.
Tokens sind die Entscheidungen, die du für alle Screens teilen möchtest. Sie nehmen Geschmack und Raten heraus — genau das, was Drift verursacht, wenn du neue Seiten generierst oder baust.
Typische Tokens decken Abstände, Typografie, Farben, Formen und ein kleines Set an Höhen (elevation) ab. Der praktische Gewinn: Eine Kopfzeile hat immer die gleiche Größe, eine Card immer dasselbe Padding und ein Primary‑Button behält Farbe und Radius.
Tokenisiere Dinge, die das gesamte Produktgefühl beeinflussen: Abstands‑Skala, Schriftgrößen und Zeilenhöhen, Kernfarben (Text, Hintergrund, Primary, Danger, Border) und ein kleines Set an Border‑Radien.
Flexibel bleiben sollten inhaltliche Entscheidungen, z. B. Textlänge, welches Icon genutzt wird oder ob ein Abschnitt zwei oder drei Cards braucht.
Wenn du Screens generierst (auch mit Tools wie Koder.ai), reduziert ein kleines Token‑Set im Vorfeld das Raten und macht die Ausgabe deutlich konsistenter.
Ein Token‑Set ist nur eine kurze Liste erlaubter Werte. Kleiner ist besser, weil es weniger Raum für zufällige Entscheidungen lässt, aber es muss die Basics abdecken, die Screens unruhig wirken lassen.
Beginne mit Abständen. Wähle eine Skala und nutze sie überall für Padding, Gaps und Layout. Eine Reihe wie 4, 8, 12, 16, 24, 32 deckt die meisten UIs ab. Wenn ein Design 10px oder 18px verlangt, runde auf das nächstgelegene Token statt neue Zahlen einzuführen.
Definiere dann Typografie‑Defaults, damit Überschriften und Fließtext nicht driftet. Du brauchst kein riesiges Typo‑System, aber klare, wiederholbare Schritte.
Ein kompaktes Set, das benutzbar bleibt ohne aufzublähen:
Accessibility gehört ebenfalls ins System. Definiere einen Fokus‑Outline‑Stil (Farbe, Stärke, Offset), damit Keyboard‑Nutzer konsistente Fokuszustände erhalten. Setze eine minimale Tap‑Target‑Größe (z. B. 44×44) für Mobilgeräte. Begrenze Textfarben auf eine kleine, vertrauenswürdige Menge, um Kontrast vorhersehbar zu halten.
Wenn Buttons manchmal gedrängt wirken, liegt es oft daran, dass eine Seite Padding 10 und eine andere 12 nutzte. Mit Tokens sagst du z. B.: „Buttons benutzen paddingY=8, paddingX=16, radius=12, Fokus‑Outline‑Token, min‑height 44.“ Sobald diese Zahlen feststehen, hört der Generator auf zu improvisieren.
Tokens legen die Zahlen fest. Komponentenregeln legen die Gewohnheiten fest.
Wähle eine kleine Menge Kernkomponenten und behandle sie als einzige Bausteine für Screens. Halte sie unspektakulär und wiederverwendbar: Button, Input, Select, Checkbox, Card. Du kannst TextArea und Modal hinzufügen, aber sie sollten dem gleichen System folgen (Labels, Abstände, Zustände).
Begrenze Varianten und definiere, wann sie erlaubt sind. Beispiel: Button hat primary, secondary und danger. Primary ist für die Hauptaktion auf der Seite (meistens eine). Secondary ist für Abbrechen oder wenig prioritäre Aktionen. Danger nur für destruktive Aktionen wie Löschen. Wenn eine Variante nicht zu rechtfertigen ist, nutze standardmäßig secondary.
Abstandsregeln verhindern subtilen Drift. Definiere Defaults innerhalb der Komponenten: Button‑Padding, Input‑Höhe, Abstand Label‑zu‑Feld, Standard‑Gap zwischen gestapelten Feldern. Füge ein paar Layoutregeln hinzu: Cards haben festes internes Padding und konsistente Header/Body‑Abstände; Modals verwenden die gleichen Breitenstufen und Footer‑Ausrichtung.
Mache Zustände nicht verhandelbar — hier wirken UIs oft zufällig:
Wenn du ein formularlastiges Screen wie „Projekt erstellen“ generierst, verhindern diese Regeln gemischte Button‑Größen, verrutschende Label‑Positionen oder ein einmaliges „speziales“ Card‑Design, das nur auf einer Seite auftaucht.
Selbst mit stabiler Optik kommen viele „das fühlt sich falsch an“‑Beschwerden vom Formularverhalten. Wenn jede Seite Labels, Fehler und Fokus anders handhabt, nehmen Nutzer das als Inkonsistenz wahr.
Wähle ein Formularmuster und nutze es überall: Label, optional/required‑Marker, Hilfetext, dann Fehlertext. Halte auch die Formulierungen einheitlich (z. B. Labels in Satzzeichen‑Kleinschreibung, kurze Hilfetexte und Fehlermeldungen, die mit einem Verb beginnen).
Regeln, die die meisten Drifts verhindern:
Sperre Größen und Layout, damit Screens nicht unterschiedlich „atmen“. Definiere eine Input‑Höhe, eine Button‑Höhe und eine Standard‑Feldbreite. Auf Desktop gleiche Felder an einem konsistenten Grid ausrichten und Labels über Inputs stapeln. Auf Mobil Felder in voller Breite und keine Zwei‑Spalten‑Formulare, außer wirklich notwendig.
Ein einfaches Beispiel: Ein „Projekt erstellen“‑Screen könnte Name, Region und Beschreibung haben. Selbst wenn Region ein Select ist, behandle es wie jedes andere Feld: gleiche Höhe, gleiche Label‑Position, gleiche Fehlerzeile. Wenn der Nutzer mit leerem Namen submitet, fokussiert der Fokus auf Name, der Fehler erscheint darunter und das Layout bleibt stabil.
Wenn du Screens in Koder.ai generierst, setze diese Formularregeln einmal in deinen Prompt und verwende sie in allen Features, damit jedes neue Formular gleich funktioniert, ohne ständige Nacharbeit.
Behandle deinen Prompt wie einen kleinen UI‑Vertrag. Halte ihn kurz, spezifisch und wiederverwendbar, damit jeder neue Screen dieselben Abstände, Typografie, Komponenten und Verhaltensregeln übernimmt.
Ein praktisches Muster ist, ein kompaktes UI‑Spec oben in die Anfrage zu kopieren und dann den Screen in einfacher Sprache zu beschreiben.
UI SPEC (apply to every screen)
Tokens:
- Spacing: 4, 8, 12, 16, 24, 32
- Radius: 8
- Typography: H1 24/32, H2 18/26, Body 14/20
- Colors: text, muted, bg, primary, danger (no custom hex)
Components (must use): PageShell, Section, Card, Button, Input, Select, TextArea, FormRow, HelperText, Toast
Layout rules:
- Page padding: 24 desktop, 16 mobile
- Section spacing: 24
- Card padding: 16
- Grid: 12 cols desktop, 4 cols mobile, gap 16
Do:
- Reuse components and tokens only
- Keep labels above inputs, helper text below
Do not:
- Invent new spacing values, font sizes, or one-off CSS
- Mix different button heights or input styles
If a new component is needed:
- Extend an existing component pattern and document it in the output
- Do not create new visual styles outside tokens
Nach dem Spec füge ein paar Akzeptanz‑Checks hinzu, die Drift früh auffangen:
Wenn du einen Chat‑basierten Generator nutzt, halte dieses Spec über Anfragen hinweg stabil. Ständige Änderungen zerstören den Zweck.
Schreibe den UI‑Vertrag, bevor du irgendetwas generierst: ein kleines Token‑Set (Abstand, Typo, Farben, Radius, Schatten) plus eine kurze Komponenten‑Inventarliste (Button, Input, Select, Card, Modal, Table, Toast). Wenn ein Token oder eine Komponente fehlt, erfindet das Modell eine und deine UI driftet.
Erstelle dann einen Referenzscreen, der die Regeln testet. Eine formularlastige Seite ist ein guter Stresstest, weil sie Header, Hilfetexte, Validierungsfehler, Primary/Secondary‑Buttons und einen Erfolgstoast enthält. Behandle diesen Screen als Basis.
Baue neue Screens, indem du bereits Definiertes komponierst. Bitte nicht um „frisches Styling“. Bitte um dieselbe Card, dieselbe Abstands‑Skala, dieselben Typografie‑Schritte und dasselbe Feldmuster.
Ein einfacher Workflow:
Wenn ein „Search users“‑Screen engere Abstände als die Referenz hat, ändere nicht manuell Margins. Aktualisiere die Spacing‑Tokens oder die Card‑Padding‑Regel einmal und generiere neu.
Wenn du mit Koder.ai arbeitest, helfen Snapshots und Rollback: Sperre eine Basis, experimentiere sicher und setze schnell zurück, wenn eine Änderung Drift einführt.
Der schnellste Weg, Konsistenz zu verlieren, ist, Tokens und Regeln als Vorschläge zu behandeln. Kleine Ausnahmen summieren sich über neue Screens.
Eine Falle ist, die Abstands‑Skala mittendrin zu ändern. Frühe Screens nutzen 8, 16, 24. Ein neuer Screen führt 10 und 18 ein „weil es besser aussieht“. Nun ist Drift erlaubt und alte Screens werden nie aktualisiert.
Eine weitere Drift‑Quelle ist, das Modell neue Komponenten‑Styles erfinden zu lassen. Wenn du nicht sagst „nur diese Button‑Varianten existieren“, kann es auf einer Seite neuen Radius oder anderes Input‑Padding erstellen.
Zustände werden oft falsch gemacht. Loading, Empty und Error‑Zustände ändern häufig Abstände und Verhalten, wenn sie am Ende ergänzt werden.
Pass auch auf vage Vorgaben auf: „mach es modern mit weichen Schatten“ ist unklar, während Verhaltensregeln wie „Fehler unter dem Feld anzeigen“, „deaktivierte Buttons behalten Fokus‑Stile“ und „Enter submit nur im letzten Feld“ konkret und wiederholbar sind.
Ein leichtes Guardrail‑Block für Prompts (kurz):
Vor dem Merge ein zweiminütiger Scan.
Beginne mit Abständen. Achte auf zufällige Werte wie 13px oder einmalige Margins. Wenn du Tokens nutzt, sollte jeder Gap aus dem genehmigten Set stammen, inklusive Gutters, Card‑Padding und Abständen zwischen Formularfeldern.
Dann prüfe die Typografie an der Typo‑Skala. Überschriften sollten stufenweise abnehmen. Fließtext darf nicht zwischen ähnlichen Abschnitten die Größe wechseln. Zeilenhöhe ist besonders wichtig auf dichten Seiten wie Einstellungen.
Scanne Buttons. Varianten und Größen sollten den Regeln folgen: Primary für die Hauptaktion, Secondary für weniger wichtige Aktionen, Danger nur bei echten Löschungen. Button‑Höhe, Icon‑Platzierung und Label‑Stil müssen übereinstimmen.
Bei Formularen geht es meist um Struktur. Labels an einem Ort, Required‑Indikatoren nach einer Regel, Hilfetext und Fehler konkurrieren nicht, Fehler erscheinen konsistent am gleichen Ort.
Kurze Checkliste:
Mache zuletzt eine schnelle Mobile‑Prüfung: Browserfenster schmaler machen und prüfen, dass das Layout adaptiert ohne neue Schriftgrößen oder Abstände zu erfinden.
Stell dir einen einfachen Onboarding‑Flow vor: drei Screens (Profil, Präferenzen, Bestätigen) plus später eine Einstellungen‑Seite. Jede Seite soll so wirken, als käme sie vom gleichen Designer, auch wenn sie in separaten Durchläufen generiert wurde.
Bevor du etwas generierst, liefere ein kleines Token‑Set und ein paar Komponentenregeln:
TOKENS
- spacing: xs=4, sm=8, md=12, lg=16, xl=24
- radius: sm=8, md=12
- type: body=14/20, title=20/28, label=12/16
- layout: pageMax=960, sectionGap=24, fieldGap=12
COMPONENT RULES
- Page: max width=pageMax, padding=xl, sectionGap between blocks
- Card: padding=lg, radius=md
- Field: label above, helper below, fieldGap between fields
- Button row: primary on right, gap=sm
- Errors: shown under field, same copy style, no alerts
Generiere dann „Profil“ und „Präferenzen“ getrennt. Weil beide Screens Page, Card, Field und Button row wie definiert nutzen müssen, haben sie die gleichen Margins, Label‑Abstände und Button‑Platzierung. Der Bestätigungs‑Step passt ebenfalls, obwohl er mehr Read‑Only‑Text enthält.
Formularverhalten ist ein häufiger Drift‑Ort, also definiere es einmal und nutze es wieder: Submit deaktiviert bis gültig, Inline‑Fehler nur nach Blur oder Submit, Enter submit nur im letzten Schritt, Back‑Button löscht nie bereits eingegebene Werte.
Wenn ein neues UI‑Stück nötig ist, lass das Modell nicht improvisieren. Füge eine Regel hinzu und generiere erneut mit Wiederverwendung im Blick:
Mach aus Tokens und Regeln ein wiederverwendbares Spec, das du tatsächlich nutzt. Wenn es zu lang ist, um es einzufügen, wird es nicht befolgt.
Ein praktisches Spec enthält: deine Token‑Tabelle (Abstand, Typo, Radien, Farben), ein kurzes Komponentenregel‑Set (Buttons, Inputs, Cards, Headings), Formularverhaltensregeln (Validierungszeitpunkt, Fehler, Disabled/Loading), Layout‑Defaults (Page‑Padding, Max‑Width, Abschnitts‑Spacing) und eine kurze „Never do this“‑Liste (zufällige Margins, Ad‑hoc‑Fontsizes).
Mach eine Gewohnheit daraus: Ändere zuerst das Spec, nicht einzelne Pixel.
Wenn du Koder.ai (koder.ai) nutzt, ist der Planung‑Modus ein guter Ort, um das Spec vor der Generierung zu bestätigen. Für Alternativen sind Snapshots und Rollback hilfreich, damit du ohne Verlust einer stabilen Basis experimentieren kannst.
Weil jede Bildschirm‑Anfrage als Neustart behandelt wird. Wenn kein gemeinsames System vorgegeben ist, füllt der Generator fehlende Details mit Vermutungen aus — Abstände, Schriftgrößen, Button‑Padding, Schatten und Formularverhalten. Diese kleinen Unterschiede summieren sich über Seiten hinweg.
Design‑Tokens sind benannte, wiederverwendbare Werte für Dinge wie Abstände, Schriftgrößen, Farben und Radien.
Anstatt „komfortables Padding“ zu verlangen, verwendest du z. B. space-md. Der Name bleibt stabil und jede Seite nutzt dieselben Entscheidungen, sodass die UI nicht mehr driftet.
Wenn du einen neuen Wert brauchst, runde auf das nächstgelegene Token, statt 10px oder 18px einzuführen.
Füge am Anfang jeder Anfrage einen kompakten UI‑Spec‑Block und behandle ihn wie einen Vertrag:
Beschreibe dann die Seite darunter. Wichtig: Das Spec sollte über Screens hinweg unverändert bleiben.
Tokens legen die Zahlen fest; Komponentenregeln definieren die Gewohnheiten. Nützliche Regeln sind z. B.:
Standardregel: Kann eine Variante nicht begründet werden, verwende die Standardvariante.
Wähle ein Muster und halte dich daran:
So vermeidest du, dass ein Screen auf Blur validiert und ein anderer nur beim Submit.
Standardisiere diese Zustände:
Wenn du Zustände nicht spezifizierst, erfindet jede Seite ihre eigenen Muster.
Erweitere das System, anstatt improvisierte Styles zuzulassen:
Wenn du sie nicht mit Tokens beschreiben kannst, ist sie oft zu speziell und erzeugt Drift.
Erstelle einen Referenzscreen, der das System belastet (formularlastige Seite ist ideal), und verwende das gleiche Spec für alle neuen Screens.
In Koder.ai kannst du planning mode verwenden, um das Spec vor der Generierung zu bestätigen, und snapshots/rollback, um eine stabile Basis beim Experimentieren zu behalten.
Wenn etwas nicht stimmt: Spec/Tokens anpassen und neu generieren — keine One‑Off‑Margins patchen.