Design‑Tokens in No‑Code‑UI‑Buildern helfen Teams, Farben, Typografie, Abstände und Varianten einmal zu definieren und so konsistente UIs ohne Schätzarbeit auszurollen.
Inkonsistente UIs beginnen selten als „Designproblem“. Meist sind es Zeitprobleme. Jemand braucht jetzt einen Button, kopiert ihn von einer anderen Seite und verändert ihn so lange, bis er „ungefähr passt“.
So schleichen sich kleine Unterschiede ein: zwei Blautöne, die fast gleich sind, ein Eckenradius, der von 6 auf 8 wechselt, eine Überschrift, die „irgendwie fett“ wirkt, und Padding, das davon abhängt, wer den Screen gebaut hat. In No‑Code‑Buildern ist es noch leichter, solche One‑Off‑Änderungen zu machen, weil die Kontrollen direkt verfügbar sind und Anpassungen harmlos erscheinen.
Mit wachsendem Produkt beschleunigt sich die Drift. Mehr Seiten bedeuten mehr wiederkehrende Muster. Mehr Builder bedeuten mehr persönlicher Geschmack. Mehr Kolleg:innen bedeuten mehr „Quickfixes“ in Isolation. Bauen eine Person das Kundenportal und eine andere das Admin‑Panel, entstehen zwei verschiedene Interpretationen derselben Marke.
„Nach Gefühl wählen“ zeigt sich im Alltag: eine Farbe so lange anpassen, bis sie „richtig aussieht“, den Abstand um ein paar Pixel verschieben, weil der Screen sich „zu eng“ anfühlt, einen neuen Button‑Stil erstellen statt einen vorhandenen zu nutzen, Schriftgrößen mischen, weil die Vorgabe „etwas klein“ wirkt, oder einen Screen fixen, ohne den Rest zu prüfen.
Die Kosten treten später zutage. Reviews verlangsamen sich, weil Feedback subjektiv wird („mach es mehr wie die andere Seite“). Nacharbeit häuft sich, weil Änderungen schwer überall anzuwenden sind. Web und Mobile driften auseinander, weil verschiedene Leute ähnliche, aber nicht identische Entscheidungen treffen.
Design‑Tokens lösen das, indem sie „ungefähr richtig“ durch gemeinsame Werte ersetzen. Die UI bleibt konsistent, selbst wenn Team und App wachsen.
Design‑Tokens sind benannte Entscheidungen zu eurer UI. Statt zu sagen „nimm dieses Blau“ oder „mach Buttons luftig“, gebt ihr diesen Entscheidungen klare Namen, die alle wiederverwenden können.
Ein Token ist nicht der rohe Wert. Der rohe Wert kann 16px, #2563EB oder 600 (Font‑Weight) sein. Der Token ist das Label, das erklärt, was der Wert im Produkt bedeutet, wie space-4, color-primary oder font-weight-semibold.
Dieser Wechsel verhindert das „Nach‑Gefühl“-Problem. Wenn Leute Werte nach Gefühl wählen, sammelt ihr langsam fünf verschiedene Blautöne, drei leicht unterschiedliche Überschriften und Abstände, die sich von Screen zu Screen ändern.
Tokens funktionieren am besten als Single Source of Truth. Wenn jeder Screen und jede Komponente dieselben Namen referenziert, könnt ihr das Aussehen der gesamten App ändern, indem ihr ein paar Token‑Werte anpasst, statt dutzende Screens zu durchsuchen.
Tokens überbrücken zudem Design und Build. Designer verwenden Token‑Namen in Specs und Builder nutzen dieselben Namen im No‑Code‑UI‑Builder, sodass das Design die Übergabe überlebt.
Die meisten Token‑Sets fallen in ein paar Kategorien: Farbrollen (primary, background, text, danger), Typografie (Schriftschnitt, Größen, Gewicht, Zeilenhöhe), Abstands‑Schritte (Padding, Margin, Gaps), Form und Tiefe (Radius, Border‑Breiten, Schatten) und manchmal Motion (Dauern und Easing).
Die meisten Teams brauchen keine riesige Token‑Bibliothek. Sie brauchen ein kleines, klares Set, das die meisten Screens abdeckt, damit Leute aufhören Werte zu erraten. Das gilt besonders in No‑Code‑Tools, wo „nur dieses eine Mal“‑Anpassungen schnell verbreitet werden.
Ein praktisches Starter‑Set deckt fünf Gruppen ab:
Eine Regel hält die Bibliothek übersichtlich: Wenn ein Wert an drei oder mehr Stellen auftaucht, macht ihn zum Token. Taucht er nur einmal auf, hinterfrage ihn, bevor er zur neuen Norm wird.
Gute Token‑Namen verhindern Streitigkeiten, bevor sie entstehen. Wenn Leute einen Token erraten können, ohne suchen zu müssen, werden sie ihn wiederverwenden. Wenn nicht, erstellen sie einen neuen und euer Theme spaltet sich.
Bevorzugt Namen, die die Rolle eines Wertes in der UI beschreiben, nicht wie er aussieht. text-primary sagt allen, wann er zu verwenden ist. blue-600 ist nur ein Farbcode.
Ein nützliches Muster sind zwei Ebenen:
color-blue-600, space-16, font-14text-primary, bg-surface, border-mutedIn einem No‑Code‑UI‑Builder helfen semantische Tokens nicht‑designer:innen schnell die richtige Wahl zu treffen, ohne zu raten.
Die meisten Token‑Bibliotheken werden unübersichtlich, weil „neu“ der Standard ist. Macht „wiederverwenden“ zum Standard.
Haltet Regeln simpel:
Standardisiert dann die Benennung. Wählt eine Schreibweise (kebab‑case funktioniert gut), benutzt stabile Präfixe (text-, bg-, border-, icon-, space-) und haltet Zahlenskalen konsistent (space-4, space-8, space-12, space-16).
Behandelt eure aktuelle UI als Beweis. Bevor ihr etwas Neues erstellt, macht ein schnelles Inventar: sammelt Screenshots, inspiziert Styles und schreibt jeden Farbwert, jede Schriftgröße und jeden Abstand auf, den ihr in Produktion seht (einschließlich Einzelfälle).
Reduziert Duplikate bewusst. Ihr findet meist denselben Grau‑Ton in fünf leicht unterschiedlichen Hexwerten oder Abstände, die zwischen 14, 15 und 16 springen. Wählt einen Wert zum Beibehalten und mappt die alten Werte darauf. Hier werden Tokens praktisch: Ihr hört auf, über Geschmack zu streiten und einigt euch auf ein kleines Set geteilter Entscheidungen.
Eine solide erste Version entsteht in einem Durchgang:
Für jeden Token ergänzt eine kurze Guidance: wo er zu verwenden ist und wo nicht. Beispiel: „text‑muted ist für Hilfetext, nicht für Primary‑Buttons.“
Bestimmt zum Schluss Ownership. Es hilft, eine Person (oder kleine Gruppe) zu benennen, die Änderungen genehmigt, mit einer einfachen Regel: „Füge einen neuen Token nur hinzu, wenn ein bestehender nicht passt.“ Das hält das System stabil, während das Produkt wächst.
Beginnt mit Defaults, die jeder Screen erbt: ein Basistextstil (Schrift, Größe, Zeilenhöhe, Farbe), Überschriftsstile (H1–H3) und ein kleines Set Layout‑Abstandsregeln, damit Seiten nicht zufällig wirken.
Mappt anschließend Tokens auf das, was euer Tool Theme‑Einstellungen nennt: Theme‑Variablen, globale Stile, Style‑Presets oder Design‑System‑Einstellungen. Das Ziel ist, dass die Auswahl „Primary“ oder „Space/16“ einen Token auswählt, nicht einen Einmalwert.
Haltet wiederverwendbare Stile fokussiert auf Muster, die ihr täglich nutzt. Ein Starter‑Set könnte einen Card‑Stil (Background, Border, Radius, Padding, Shadow), einen Form‑Field‑Stil (Label, Input, Hilfetext), Button‑Stile sowie Zeilendichte und Hover‑Zustände für Tabellen umfassen.
Zustände sind ein häufiger Ort für Inkonsistenzen, definiert sie daher früh. Jede interaktive Komponente sollte tokengetriebene Werte für Hover, Fokus, Disabled und Error haben. Der Fokus sollte überall dieselbe Ring‑Farbe und Stärke nutzen. Error sollte dieselbe Border‑/Text‑Farbkombination verwenden.
Plant schließlich das Teilen. Unterstützt euer Workspace Templates oder wiederverwendbare Module, legt Tokens und Basisstile in ein „Starter‑App“, das neue Projekte kopieren. So starten neue Screens standardmäßig konsistent.
Varianten sind der Punkt, an dem ein UI‑System entweder ruhig und vorhersehbar wird oder in eine Ansammlung von Einzelanpassungen kippt. Varianten funktionieren am besten, wenn sie eine dünne Schicht sind, die zu Tokens für Farbe, Typo und Abstände mapped.
Beginnt mit einem kleinen Satz Schlüsselkomponenten, die ihr überall nutzt: Buttons, Inputs, Badges, Alerts und Cards. Gebt jeder Komponente dieselben zwei Entscheidungsdimensionen: Größe und Absicht (Intent). Größe sollte mechanisch sein (Typografie und Abstand). Intent sollte Bedeutung sein (semantische Farben).
Größenvarianten bleiben konsistent, wenn sie nur wenige tokenbasierte Eigenschaften ändern: Schriftgröße, Padding und Radius. Intent‑Varianten sollten vor allem Farbrollen (Background, Text, Border) ändern und niemals heimlich Abstände verändern.
Ein Set, das die meisten Produkte abdeckt:
Definiert Zustandsregeln, die für jede Komponente gelten, nicht nur für Buttons. Beispiel: Fokus zeigt immer einen sichtbaren Ring, Hover erhöht konsistent den Kontrast, und Disabled nutzt dieselbe Opazität und blockiert Klicks.
Fügt eine neue Variante nur hinzu, wenn sie eine wiederkehrende Bedeutung darstellt (z. B. „danger“). Ist es ein einmaliges Layoutbedürfnis, ist es meist eine neue Komponente oder ein Wrapper, keine Variante, die später missbraucht wird.
Wenn ein Produkt auf Web und Mobile läuft, heißt „gleiche Marke“ nicht immer „gleiche Pixel“. Ziel ist, dass Screens wie aus einer Familie wirken, auch wenn Plattformen unterschiedliche Defaults haben.
Beginnt mit gemeinsamen Tokens, die gut übertragbar sind: Farbrollen (Background, Surface, Text, Primary, Danger), eine Typografie‑Skala (Größen und Gewichte) und Abstands‑Tokens (4, 8, 12, 16, 24). Diese entfernen Raterei und machen Updates vorhersehbar.
Akzeptiert dann reale Unterschiede. Mobile braucht größere Touch‑Ziele und oft etwas mehr Abstand. Web braucht dichtere Tabellen, Sidebars und Mehrspalten‑Layouts. Fonts können ebenfalls variieren: Auf Web nutzt ihr vielleicht die Brand‑Font, auf iOS/Android bevorzugt man Plattform‑Defaults für Lesbarkeit und Performance.
Ein praktischer Ansatz ist zwei Ebenen: globale Tokens, die Bedeutung definieren, und Plattform‑Tokens, die festlegen, wie diese Bedeutung gerendert wird.
color.text, color.primary, space.md, radius.sm, type.bodytype.family.web, control.height.web, space.tableRowtype.family.mobile, control.height.mobile, space.touchHaltet Komponentennamen konsistent (Button/Primary), auch wenn Größen variieren. Führt Kontrastprüfungen für beide Themes vor Release durch.
Tokens funktionieren nur, wenn sie stabil und verständlich bleiben. Ohne leichte Governance fügen Teams stillschweigend „noch ein Blau“ oder „noch ein Padding“ hinzu, und ihr seid zurück beim Eyeballing.
Haltet den Prozess klein, aber realistisch:
Pflegt ein einfaches Changelog mit Deprecations. Wenn ein alter Token ersetzt wird, sagt, was stattdessen zu nutzen ist, lasst ihn eine Weile weiter funktionieren und markiert ihn deutlich, damit neue Screens ihn nicht erneut verwenden.
Aufräumen gehört dazu. Entfernt oder markiert einmal im Monat ungenutzte Tokens und Komponentenvarianten.
Nicht‑Designer brauchen Beispiele, keine Theorie.
Do: Nutze die Abstandsleiter für Gaps und die Primary‑Button‑Variante für die Hauptaktion.
Don’t: Setze Padding auf „13px, weil es gut aussieht“ oder erstelle einen neuen Button‑Stil, um einen einzelnen Screen anzupassen.
Verknüpft Token‑Arbeit mit Produktprioritäten: neue Features, Rebrands und Accessibility‑Fixes sollten Token‑Updates antreiben, nicht persönliche Vorlieben.
Der schnellste Weg, die Vorteile von Tokens zu verlieren, ist, sie als Ablage für alles zu behandeln. Man beginnt mit guter Absicht, dann häufen sich ein paar Quickfixes und das Team ist wieder beim Nach‑Gefühl.
Eine häufige Falle ist, zu viele Tokens zu früh anzulegen. Wenn jeder Screen seinen eigenen Farb‑ oder Abstands‑Token bekommt, baut ihr kein System, sondern katalogisiert Ausnahmen. Fügt einen Token nur hinzu, wenn ihr mindestens zwei Stellen angeben könnt, wo er genutzt wird.
Ein weiteres Problem ist, rohe Werte in Komponenten zuzulassen. Jemand setzt Button‑Padding auf 14px „nur dieses eine Mal“ oder nutzt eine Hex direkt in einer Card. Wochen später erinnert sich niemand, warum es anders ist. Macht zur Gewohnheit: sichtbar und wiederholbar = Token.
Achtet auch auf das Mischen von Token‑Typen. Base‑Tokens (wie gray-900 oder space-4) beschreiben rohe Werte. Semantic‑Tokens (wie text-primary oder surface-muted) beschreiben Bedeutung. Probleme entstehen, wenn eine Komponente Base‑Tokens nutzt und eine andere semantische Tokens für dieselbe Rolle.
Zustände sind ein weiterer Late‑Stage‑Pain. Teams definieren oft Normal‑Styles und flicken Fokus, Hover, Disabled und Error kurz vor Release zusammen. So entstehen inkonsistente Fokus‑Ringe und drei verschiedene „Error“‑Rottöne.
Vor dem Skalieren macht eine kurze Fallenprüfung:
Bevor ihr eure UI auf mehr Screens, Teams oder Produkte ausrollt, prüft, ob eure Basis klar genug ist, um ohne Raten kopiert zu werden.
Ein kleines Team baut gleichzeitig zwei Apps: ein Kundenportal und ein internes Admin‑Panel. Unterschiedliche Personen bearbeiten unterschiedliche Screens und arbeiten schnell in einem No‑Code‑UI‑Builder. Nach ein paar Wochen wirkt die UI „falsch“, obwohl niemand ein konkretes Problem nennen kann.
Vor Tokens sammeln sich Review‑Kommentare: Buttons sind fast gleich, aber nicht identisch, Abstände wechseln von Screen zu Screen, Formularfelder stimmen nicht überein und das Portal wirkt „freundlich“, während das Admin‑Panel versehentlich „streng“ wirkt.
Sie lösen es, indem sie ein kleines, praktisches Token‑Set einführen. Sie definieren semantische Farben (Primary, Success, Danger, TextMuted), eine Abstandsskala (4, 8, 12, 16, 24) und Button‑Varianten (Primary, Secondary, Ghost) mit einem Radius und konsistenten Zuständen.
Von nun an hören Mitwirkende auf, zufällige Hex‑Werte und Schriftgrößen in jedem Screen zu wählen. Sie wählen Tokens und Varianten, sodass jede neue Seite dieselben Entscheidungen erbt.
Das Bauen wird schneller, weil Entscheidungen schon getroffen sind. Reviews verschieben sich von kleinen visuellen Nichtigkeiten zu echten UX‑Fragen. „Mach diesen Button zur Primary‑Variante“ ersetzt „Kannst du ihn etwas blauer und einen Tick höher machen?“
Bei einem kleinen Rebrand ändert sich die Primary‑Farbe und die Schriftskala wird angepasst. Mit Tokens aktualisiert das Team einige Werte einmal und sowohl Portal als auch Admin‑Panel passen sich gemeinsam an.
Wählt einen Flow, den viele nutzen und der offensichtliche Drift‑Probleme hat, z. B. Onboarding, eine Einstellungsseite oder ein einfaches Formular. Die Umstellung eines einzelnen Flows ist der schnellste Weg, die Idee zu beweisen und das Nach‑Gefühl zu stoppen.
Startet mit einem kleinen, sicheren Token‑Set: primary/background/text/border/danger, eine kurze Typografie‑Skala, eine Abstandsleiter und 2–3 Radien und Schattenlevel. Dann erstellt ein winziges Komponenten‑Set, das nur Tokens nutzt: ein Button, ein Input, eine Card, ein Alert. Fügt Varianten nur hinzu, wenn sie ein echtes Problem lösen.
Führt eine kurze Review mit dem Team durch, nutzt zwei Screenshots: einen „Vorher“‑Screen mit inkonsistentem Padding und Fonts und einen „Nachher“‑Screen, der aus Tokens und Varianten gebaut ist. Einigt euch auf ein paar Regeln (z. B. „keine Hardcoded‑Farben“ und „Abstände müssen Tokens sein“) und behebt die schlimmsten Inkonsistenzen zuerst.
Beim Rollout zuerst neue Screens konvertieren, ältere nach und nach beim Editieren anpassen. Wenn Support nach einem neuen Admin‑Filter fragt, baut dieses Panel tokenbasiert neu und ersetzt nur, was ihr gerade ändert.
Wenn ihr komplette Produkte (Backend, Web und Mobile) in AppMaster baut, hilft es, Tokens und wiederverwendbare UI‑Stile früh zu setzen, damit neue Screens dieselben Entscheidungen erben. So können visuelle Konsistenz und App‑Logik gemeinsam vorankommen, ohne später wieder aufzuräumen.
Warum passiert UI‑Inkonsistenz immer wieder, auch wenn wir einen Designer haben?UI‑Drift beginnt meist mit kleinen „nur dieses eine Mal“ Änderungen: eine Komponente kopieren, Padding anpassen oder eine Farbe nach Gefühl wählen. Mit der Zeit summieren sich diese kleinen Abweichungen über Seiten und Teammitglieder hinweg, und Reviews werden zu subjektiven Diskussionen statt schnellen Kontrollen gegen gemeinsame Regeln.
Was genau ist ein Design‑Token (ohne Theorie)?Design‑Tokens sind benannte UI‑Entscheidungen, die wiederverwendet werden, statt rohe Werte zu erraten. Der Wert kann 16px oder #2563EB sein, aber der Token‑Name erklärt den Zweck, z. B. space-16 oder color-primary, sodass alle dieselbe Wahl treffen.
Welche Token‑Kategorien sollten wir zuerst für ein echtes Produkt definieren?Fang mit Farbrollen, Typografie, Abständen und einer kleinen Auswahl an Radien und Schatten an. Das deckt die meisten Bildschirme ab und verhindert die häufigsten „nach Gefühl“-Probleme, während die Token‑Sammlung klein genug bleibt, dass sie tatsächlich verwendet wird.
Wann sollten wir einen neuen Token anlegen und wann einen Einzelfall beibehalten?Eine praktische Faustregel: Erstelle Tokens, wenn ein Wert an zwei oder mehr Stellen auftaucht oder wenn er einen echten Zustand wie Hover, Fokus, Disabled oder Error unterstützt. Ist ein Wert wirklich ein Einzelstück, behalte ihn lokal in der Komponente, damit er nicht versehentlich zum globalen Standard wird.
Sollen unsere Token‑Namen semantisch (z. B. text‑primary) oder roh (z. B. blue‑600) sein?Semantische Namen beschreiben, wofür ein Token gedacht ist, z. B. text-primary oder bg-surface, sodass man ohne Farbpalette zu lernen die richtige Auswahl trifft. Rohe Namen wie blue-600 sind als Basis in Ordnung, aber wenn Komponenten direkt darauf verweisen, führt das leicht zu falscher Verwendung der Farben.
Wie erstellt man Tokens aus einer bestehenden inkonsistenten UI, ohne alles kaputt zu machen?Auditiert, was ihr bereits ausliefert: sammelt die Farben, Schriftgrößen und Abstände, die tatsächlich in Produktion zu sehen sind, und fasst nahe beieinanderliegende Werte bewusst zusammen. Sobald ihr ein kleines, sauberes Set habt, mappt alte Werte auf den nächsten Token, damit zukünftige Screens Tokens wiederverwenden statt „fast gleiche“ Werte neu einzuführen.
Wie wendet man Tokens in einem No‑Code‑UI‑Builder praktisch an?Setzt globale Defaults, und mappt dann Tokens auf das, was euer Builder als Theme‑Variablen oder globale Stile nennt, sodass Komponenten Namen referenzieren statt Hex‑Codes und Pixelwerte. Erzeugt danach eine kleine Menge wiederverwendbarer Stile für die Komponenten, die ihr täglich nutzt, und stellt sicher, dass auch Hover, Fokus, Disabled und Error tokenbasiert sind.
Wie baut man Komponentenvarianten (Buttons, Inputs) ohne Chaos?Begrenze Varianten auf Größe und Absicht. Größe sollte nur wenige tokenbasierte Eigenschaften wie Schriftgröße und Padding ändern. Absicht (Intent) sollte hauptsächlich semantische Farbrollen tauschen, sodass etwa ein „danger“ Button nicht heimlich Abstände oder Typografie verändert.
Wie halten wir Web‑ und Mobile‑Themes in Einklang, ohne identische Pixel zu erzwingen?Teilt globale semantische Tokens über Plattformen, damit die Bedeutung gleich bleibt, und erlaubt plattformspezifische Tokens für Unterschiede wie Touch‑Zielgrößen oder Dichte. Das Ziel ist „gleiche Familie, nicht gleiche Pixel“: Web und Mobile sollen konsistent wirken, dabei aber ihre eigenen Anforderungen respektieren.
Wie steuern wir Tokens, damit das System über die Zeit sauber bleibt?Legt klare Verantwortlichkeiten fest und nutzt einen kleinen Review‑Ablauf für Änderungen, damit neue Tokens nicht als schnelle Flickschusterei entstehen. Ein regelmäßiger Veröffentlichungsrhythmus und das Deprecation‑Management (alte Tokens markieren statt heimlich ersetzen) hält das System stabil, gerade wenn in AppMaster viele Mitwirkende schnell bauen.
21. Jan. 2026
8 Min
20. Jan. 20268 Min
20. Jan. 20268 MinExperimentieren Sie mit AppMaster mit kostenlosem Plan.
Wenn Sie fertig sind, können Sie das richtige Abonnement auswählen.
