Warum die meisten Konsistenz-Checklisten nicht funktionieren
Die Standardlisten stellen Fragen wie "Ist der Look and Feel der Benutzeroberfläche konsistent?" oder "Werden Labels konsistent verwendet?". Das sind lediglich Umformulierungen des Ziels. Die Person, die das Audit durchführt, muss jede dieser Fragen in etwas Prüfbares umwandeln, und das wird jedes Mal anders geschehen – was das Audit selbst inkonsistent macht.
Eine Prüfung ist nur dann wertvoll, wenn sie drei Dinge besitzt: ein spezifisches Objekt der Betrachtung, eine Methode zur Prüfung und eine Bedingung, die über Bestehen oder Nichtbestehen entscheidet. Alles Folgende erfüllt diese drei Kriterien.
Durchgang eins: mechanisch
Fünf Minuten, keine subjektive Beurteilung nötig, und es findet einen überraschend hohen Anteil an echtem Drift. Jede dieser Prüfungen sollte nach erfolgreicher Implementierung in die CI überführt werden; eine Prüfung, die nur während Audits läuft, lässt Drift zwischen den Audits akkumulieren.
- 1
Literale Farbwerte außerhalb der Token-Datei
Die Prüfung mit dem höchsten Ertrag. Jeder Hex-Wert in einer Komponente bedeutet, dass die Token-Ebene umgangen wurde und diese Farbe nicht zentral geändert werden kann.
grep -rn --include='*.tsx' --include='*.css' -E '#[0-9a-fA-F]{3,8}\b' src \ | grep -v 'tokens\|globals.css' - 2
Schriftstärken außerhalb Ihres Bereichs
Bei der Schriftstärke fällt die Hierarchie oft stillschweigend auf die Framework-Defaults zurück. Wenn Ihr System 400 und 600 vorsieht, ist alles, was stärker ist, Drift – ungeachtet dessen, wie es aussieht.
grep -rn --include='*.tsx' -E 'font-(bold|extrabold|black)|font-weight:\s*[78]00' src - 3
Abstandswerte außerhalb der Skala
Escape-Hatch-Lösungen mit beliebigen Werten sind der Ort, an dem der Rhythmus stirbt. Ein
p-[13px]ist vernachlässigbar; vierzig davon sind ein zweites Abstandssystem, dem niemand zugestimmt hat.grep -rn --include='*.tsx' -E '\b(p|m|gap|space)-\[[0-9]+px\]' src - 4
Radius-Werte
Der Radius driftet stärker als alles andere, da jeder Komponenten-Autor das wählt, was isoliert betrachtet richtig aussieht. Zählen Sie die verwendeten unterschiedlichen Werte; mehr als drei oder vier sind ein Befund.
grep -rhoE 'rounded-[a-z0-9]+|border-radius:\s*[0-9]+px' src -r \ --include='*.tsx' --include='*.css' | sort | uniq -c | sort -rn - 5
Vom System verbotene Properties
Alles, was in Ihrer Verbotsliste steht. Wenn dort steht, dass Elevation niemals ein Schatten sein darf, setzt diese Prüfung dies durch. Wenn Sie keine Verbotsliste haben, ist das bereits der Befund – schreiben Sie zuerst eine.
grep -rn --include='*.tsx' --include='*.css' -E 'box-shadow|shadow-(sm|md|lg|xl)|gradient' src
Führen Sie diese Prüfungen durch, bevor Sie sich irgendetwas ansehen. Jedes Ergebnis ist ein eindeutiger Befund, der keine Diskussion erfordert. Wenn diese zuerst bereinigt werden, befasst sich der komparative Durchgang mit echten Ermessensfragen statt mit offensichtlichen Versäumnissen.
Die vierte Prüfung hat eine Besonderheit: Das Zählen unterschiedlicher Radius-Werte gibt Aufschluss über die Konsistenz, nicht über die Korrektheit. Drei bewusst eingesetzte Werte – 6px für Controls, 12px für Container, vollrund für Avatare – sind ein System. Drei Werte, die zufällig 6, 8 und 10 sind, sind unbemerkter Drift.
Durchgang zwei: komparativ
Hier ist der Punkt, den jeder Audit-Prozess falsch macht: Die Überprüfung eines Screens für sich allein sagt aus, ob er intern kohärent ist. Sie sagt jedoch nichts darüber aus, ob er zu den anderen Screens passt, da man sich die anderen Screens nicht präzise genug im Kopf merken kann.
Drift ist pro Datei unsichtbar und im Vergleich offensichtlich. Ein Review pro Pull-Request kann ihn strukturell nicht erfassen.
Öffnen Sie daher drei fertige Screens derselben Oberfläche nebeneinander – drei Anwendungs-Screens oder drei Marketing-Seiten, niemals gemischt. Der Vergleich eines Dashboards mit einer Landingpage erzeugt Unterschiede, die beabsichtigt sind.
| Prüfung von | Fehler, wenn | |
|---|---|---|
| Dichte | Control-Padding, Zeilenhöhe, Abstände zwischen Sektionen | Ein Bildschirm wirkt luftig, ein anderer gedrängt, ohne dass dies durch den Inhalt begründet ist |
| Hierarchie | Unterscheidung zwischen Seitentitel und Sektionstitel | Einmal wird die Größe genutzt, einmal die Schriftstärke, ein drittes Mal die Farbe |
| Elevation | Kennzeichnung einer angehobenen Oberfläche | Schatten auf einem Bildschirm, Rahmen auf einem anderen |
| Empty States | Verhalten bei fehlenden Daten | Einmal eine Illustration, einmal ein Satz, ein drittes Mal gar nichts |
| Loading | Anzeige während des Datenabrufs | Skeletons, ein Spinner und ein weißes Aufblitzen über drei Bildschirme hinweg |
| Fehlerdarstellung | Position und Aussehen einer Fehlermeldung | Einmal Inline, einmal als Toast, ein drittes Mal als Full-Page-State |
In den unteren drei Zeilen ist die Konsistenz fast immer am schwächsten. Das liegt nicht an Nachlässigkeit – Empty-, Loading- und Error-States werden unter Zeitdruck, individuell und von der Person geschrieben, die gerade in der Datei gearbeitet hat. Gleichzeitig sind dies genau die Zustände, die ein frustrierter Nutzer überproportional oft sieht.
Wenn Ihr Designsystem keine Vorgaben für Empty-, Loading- und Error-States macht, ist davon auszugehen, dass diese auf jedem Bildschirm anders aussehen und kein Review dies bemerkt. Diese Zustände müssen ebenso explizit spezifiziert werden wie Buttons, was jedoch fast nie geschieht.
Die vollständige Vergleichsliste
In den sechs oben genannten Zeilen konzentriert sich der Drift. Dies ist die vollständige Liste, gruppiert für die Bearbeitung in einem Durchgang. Jeder Punkt enthält eine Pass-Bedingung statt einer Frage.
Farbe
- Jede Farbe auf jedem Bildschirm ist einer benannten Rolle zugeordnet. Fehler, wenn eine Komponente einen Literalwert enthält.
- Die Akzentfarbe wird über alle Bildschirme hinweg für dieselben Elementtypen verwendet. Fehler, wenn sie auf einem Bildschirm für einen Button und auf einem anderen für eine Überschrift genutzt wird.
- Statusfarben werden ausschließlich für Status verwendet. Fehler, wenn die Erfolgsfarbe irgendwo dekorativ eingesetzt wird.
- Jede Light-Mode-Farbe hat ein Dark-Mode-Gegenstück, das bewusst gewählt und nicht automatisch abgeleitet wurde. Fehler, wenn eine Oberfläche eine einfache Invertierung ist.
Typografie
- Jede auf dem Bildschirm verwendete Größe entspricht einer Stufe der Skala. Fehler, wenn eine Größe gefunden wird, die dies nicht tut.
- Schriftstärken bleiben innerhalb des definierten Bereichs. Fehler bei jeder Stärke oberhalb dieses Bereichs, unabhängig von der Optik.
- Dieselbe semantische Ebene sieht überall gleich aus – jeder Seitentitel entspricht jedem anderen Seitentitel. Fehler, wenn zwei Bildschirme ihren Titel unterschiedlich kennzeichnen.
- Zahlen in Spalten sind tabellarisch und ausgerichtet. Fehler, wenn die Ziffern zwischen den Zeilen nicht untereinander stehen.
Abstände und Formen
- Jeder Spacing-Wert ist eine Stufe der Skala. Fehler bei jedem beliebigen Wert.
- Es gibt nur wenige verschiedene Radius-Werte, und jeder hat einen festgelegten Zweck. Fehler, wenn nicht begründet werden kann, warum 8px neben 6px existieren.
- Elevation wird überall einheitlich dargestellt. Fehler, wenn Schatten und Rahmen gleichzeitig für denselben Zweck eingesetzt werden.
- Der Sektionsrhythmus ist konsistent – der Abstand zwischen einer Überschrift und ihrem Inhalt ist auf jedem Bildschirm identisch. Fehler bei jeder Variation ohne Begründung.
Komponenten und Steuerelemente
- Eine Implementierung pro Komponente. Fehlschlag, wenn zwei Dateien eine Card definieren.
- Primäre Aktionen sehen identisch aus und befinden sich an der gleichen relativen Position. Fehlschlag, wenn ein Screen sie links und ein anderer rechts platziert.
- Destruktive Aktionen sind visuell deutlich unterscheidbar und dies konsistent. Fehlschlag, wenn Löschen an irgendeiner Stelle wie Speichern aussieht.
- Interaktive Elemente haben einen sichtbaren Fokus-Zustand, und dieser ist überall gleich. Fehlschlag bei jedem fehlenden oder abweichenden Fokus-Ring.
- Deaktivierte Zustände sind visuell von ausgegrauten Inhalten unterscheidbar. Fehlschlag, wenn ein Nutzer ein nicht verfügbares Steuerelement nicht von de-emphasised Text unterscheiden kann.
Die Zustände, die niemand spezifiziert
- Empty States werden produktweit einheitlich behandelt. Fehlschlag bei einer Illustration hier und einem Satz dort.
- Ladevorgänge nutzen einen einzigen Mechanismus. Fehlschlag bei einem Skeleton, einem Spinner und einem blanken Flash über drei Screens hinweg.
- Fehler erscheinen an der gleichen Stelle mit der gleichen Behandlung. Fehlschlag bei Inline-Anzeige hier, Toast-Benachrichtigung dort.
- Fehlermeldungen sagen aus, was schiefgelaufen ist und was zu tun ist. Fehlschlag bei allem, was sich nur entschuldigt.
- Lange Inhalte werden überall auf die gleiche Weise gekürzt. Fehlschlag, wenn an einer Stelle ein Zeilenumbruch erfolgt und an einer anderen ein Ellipsen-Kürzung ohne zugrunde liegende Regel.
Arbeiten Sie bei Zeitmangel zuerst die letzte Gruppe ab. Dies ist die Gruppe, die am wahrscheinlichsten fehlschlägt, am wenigsten wahrscheinlich irgendwo spezifiziert ist und am ehesten von einem Nutzer gesehen wird, der bereits eine schlechte Erfahrung macht.
Inhalt und Sprache
- Das gleiche Konzept hat überall denselben Namen. Fehlschlag, wenn die Oberfläche an einer Stelle "Projekt" und an einer anderen "Workspace" für dieselbe Sache verwendet.
- Buttons benennen die Aktion, die sie ausführen, und die Bestätigung spiegelt dies wider. Fehlschlag bei "Absenden", gefolgt von "Ihre Änderungen wurden gespeichert".
- Die Groß- und Kleinschreibung folgt einer einheitlichen Regel für Labels, Überschriften und Buttons. Fehlschlag bei einem Mix aus Title Case und Sentence Case.
- Daten, Uhrzeiten und Zahlen verwenden ein einheitliches Format. Fehlschlag bei zwei Datumsformaten in einem Produkt.
Der erste Punkt in dieser Gruppe verursacht mehr echte Nutzerverwirrung als jede visuelle Inkonsistenz in diesem Artikel. Zwei Namen für ein Konzept bedeuten, dass der Nutzer zwei mentale Modelle pflegen muss und nicht erkennen kann, ob es sich um dieselbe Sache handelt.
Dritter Durchgang: Sind die Regeln selbst kohärent?
Auditieren Sie einmal im Quartal das System statt der Oberfläche. Die Frage ist nicht, ob die Regeln befolgt wurden, sondern ob die Regeln befolgbar waren.
| Signal | Bedeutung | |
|---|---|---|
| Eine Regel mit einem Vorbehalt | "Großzügige Abstände, wobei Tabellen dichter sein können" | Zwei Regeln, die so tun, als wären sie eine. Ein Modell oder eine Person muss wählen, und sie wählen unterschiedlich |
| Die gleiche Ausnahme wird wiederholt angefordert | Drei Teams benötigten denselben Wert außerhalb des Systems | In der semantischen Ebene fehlt etwas. Erweitern Sie diese, anstatt Ausnahmen zu gewähren |
| Multiplikation von Tokens auf Komponenten-Ebene | Viele Tokens mit genau einem Consumer | Der Notausgang ist zur Hauptstraße geworden |
| Eine Regel, die niemand aus dem Gedächtnis formulieren kann | Jeder muss sie nachschlagen | Entweder ist sie zu kompliziert oder sie ist willkürlich. Beides ist behebbar |
Die erste Zeile ist diejenige, die am strengsten geprüft werden muss, da eine vorsichtige Regel wie eine gründliche Regel wirkt. Wenn Ihre Richtlinien Vorbehalte enthalten, benötigen die beschriebenen Oberflächen separate Dokumente — Governance deckt die strukturelle Version davon ab.
Was sich ändert, wenn ein Agent die Screens schreibt
Zwei Dinge, in entgegengesetzte Richtungen, und beide ändern die Art und Weise, wie Sie diese Checkliste durchführen sollten.
Der mechanische Durchgang wird wichtiger, da das Code-Volumen gestiegen ist, die Review-Kapazität jedoch nicht. Ein Agent, der zwischen zwei Reviews vierzig Screens produziert, wird jeden Drift vierzigmal reproduzieren, bevor ihn jemand sieht. Automatisierte Prüfungen sind das Einzige, was in diesem Maßstab skaliert.
Der vergleichende Durchlauf wird ebenfalls wichtiger, und zwar aus einem subtileren Grund. Ein Agent ist *innerhalb* einer Datei extrem konsistent, besitzt aber kein Gedächtnis über Sitzungen hinweg. Das Ergebnis ist daher eine Reihe von intern kohärenten Screens, die sich jedoch untereinander unterscheiden. Genau das ist das Fehlerbild, das bei einer dateibasierte Review nicht erkannt werden kann.
Die Ursache liegt meist weiter oben im Prozess. Wir haben 299 DESIGN.md-Dateien analysiert, die Agenten als Design-Leitfaden dienen sollen: 86 % geben Farben als reine Hex-Werte ohne semantische Rolle an, 76 % enthalten keinerlei Verbote, 69 % definieren keinen Dark Mode, 57 % nennen keine Motive und 44 % enthalten an keiner Stelle einen konkreten Größenwert. 54 % verlassen sich auf mindestens ein vages Adjektiv – „clean“ in 39 %, „modern“ in 36 %.
Eine solche Datei lässt Entscheidungen zu Dichte, Hierarchie, Elevation und Empty-States offen, sodass das Modell diese für jeden Screen neu trifft. Konsistenzmängel gegenüber einem solchen Leitfaden sind real, und sie Screen für Screen zu beheben, wird nicht von dauerhafter Wirkung sein. So schreiben Sie einen effektiven Leitfaden.
Identity Forge Design-Kits schließen diese Lücke direkt: semantische Farbrollen für Light- und Dark-Mode, Typografie- und Spacing-Skalen, Motive sowie eine explizite Liste mit Do's und Don'ts, serialisiert in einer DESIGN.md, die der Agent vor dem Schreiben liest. Kits durchsuchen.
Die Kurzfassung
Wenn Sie nur zwanzig Minuten statt eines ganzen Tages Zeit haben:
- Suchen Sie per Grep nach Hex-Werten außerhalb der Token-Datei. Jeder Treffer ist ein Befund.
- Suchen Sie per Grep nach Schriftstärken oberhalb Ihres definierten Bereichs. Jeder Treffer ist ein Befund.
- Zählen Sie die verschiedenen Radius-Werte. Bei mehr als vier sollten Sie die Ursache prüfen.
- Öffnen Sie drei Screens einer Oberfläche. Vergleichen Sie Dichte, Hierarchie und Elevation.
- Prüfen Sie gezielt die Empty-, Loading- und Error-States. Hier sind die Mängel meist am größten.
- Prüfen Sie, ob Ihr Leitfaden eine Liste mit Verboten enthält. Wenn nicht, ist dies die Lösung, die die nächste Fehlerrunde verhindert.
Die Schritte eins bis drei lassen sich heute automatisieren und sollten nie wieder manuell durchgeführt werden müssen. Die Schritte vier und fünf erfordern eine Person und sind eine regelmäßige halbe Stunde Zeitaufwand wert. Schritt sechs entscheidet darüber, ob Sie dies im nächsten Quartal erneut tun müssen.
Wie prüfe ich die UI-Konsistenz?
In drei Durchläufen. Mechanische Prüfungen per Grep – konkrete Farben, Schriftstärken, Spacing abseits der Skala, Radius-Streuung, verbotene Properties. Dann ein vergleichender Durchlauf mit drei fertigen Screens derselben Oberfläche nebeneinander. Schließlich vierteljährlich ein Audit, ob die Regeln selbst kohärent sind.
Warum erkennt das Code-Review keine Design-Inkonsistenzen?
Weil ein Review eine einzelne Datei betrachtet, Drift aber nur zwischen Dateien existiert. Ein Screen kann für sich genommen völlig kohärent sein und dennoch eine andere Strategie für Dichte, Hierarchie und Elevation verwenden als jeder andere Screen. Man kann die anderen Screens nicht präzise genug im Kopf behalten, um dies zu bemerken.
Welche Teile einer Benutzeroberfläche sind am häufigsten inkonsistent?
Mit großem Abstand Empty-States, Loading-States und die Darstellung von Fehlern. Diese werden oft individuell unter Zeitdruck erstellt, sind selten in einem Designsystem spezifiziert und werden in keinem Review-Prozess verglichen – obwohl sie genau das sind, was ein feststeckender Nutzer überproportional häufig sieht.
Wie oft sollte ich ein Konsistenz-Audit durchführen?
Integrieren Sie die mechanischen Prüfungen in die CI, damit sie kontinuierlich laufen. Führen Sie den vergleichenden Durchlauf monatlich oder nach jeder größeren Serie neuer Screens durch. Prüfen Sie die Regeln selbst vierteljährlich. Alles, was nur während eines geplanten Audits passiert, lässt Drift über einen gesamten Zyklus hinweg akkumulieren.
Ist KI-generierte UI konsistenter oder inkonsistenter?
Beides, und zwar auf eine Weise, die normale Reviews aushebelt. Sie ist innerhalb einer einzelnen Datei hochkonsistent, besitzt aber kein Gedächtnis zwischen den Sitzungen. Man erhält also eine Reihe von intern kohärenten Screens, die sich voneinander unterscheiden. Automatisierte Prüfungen und der Screen-zu-Screen-Vergleich sind die zwei Methoden, die dies erkennen; ein Review pro Datei kann dies strukturell nicht.