Vier Briefings rein, ein Designsystem raus

ux-skill ist meine quelloffene Design-Engine. Man gibt ihr eine Markenfarbe und ein Briefing, und sie erstellt ein Designsystem: Farben, Schriften, Abstände, Ecken, Bewegung. Ich habe sie gebaut, weil Seiten aus KI-Tools alle gleich aussehen und ich das ändern wollte.

Am 25. September 2026 war Version 4.0 fast fertig. Die Engine erstellte Systeme, und jedes bestand alle 324 Kontrastprüfungen. Sie prüfen, ob Text vor seinem Hintergrund lesbar ist. Die bisherigen Demos waren klein: Die Engine lief auf einer einzelnen Karte. Eine Karte beweist nichts über eine Marke.

Also ließ ich sie auf echten Websites testen, bevor ich weitermachte. Hier ist der Versuch als Prompt für Ihr eigenes Tool:

Erstelle vor der Veröffentlichung vier Designsysteme aus vier Briefings, die nichts gemeinsam haben sollten: eine Zahlungs-App für Ladeninhaber mit Arabisch als erster Sprache, ein standardmäßig dunkles Datenbanktool für Backend-Entwickler, ein warmes und verspieltes Familienrestaurant und eine Klinik, in der viele Patienten über 60 sind. Stelle die vier nebeneinander und liste alles auf, was gleich geworden ist.

Dieser Text richtet sich an alle, die ein Tool bauen, das etwas erzeugt: Designsysteme, Layouts, Texte, Code. Sie brauchen keine Programmierkenntnisse, um ihm zu folgen.

Was war überall gleich?

Fast alles.

Ich habe die vier Systeme gemessen, die diese Version erstellt:

Die Klinik für Menschen über 60 bekam denselben 16px-Text wie das Tool für Entwickler. Das verspielte Restaurant bekam die Schrift der Zahlungs-App. Jedes System verwendete dieselbe Schrift für Überschriften und Fließtext. Das Blau für Informationsmeldungen war in allen vier Systemen gleich.

Es war schlimmer, als die Tabelle zeigt:

• Das Briefing wurde gelesen und verworfen. Die Engine meldete, sie erkenne „viele über 60“ nicht, ignorierte es und berichtete danach, dass nichts zu tun sei.
• Die Schriften waren nur Namen. Jedes System nannte eine Schriftart, lieferte aber keine Möglichkeit, sie zu laden. Eine echte Seite nutzte deshalb, was auf dem Computer verfügbar war. Darum haben die vier Seiten oben dieselbe Schrift.
• Die Markenfarbe wurde verändert. Das Orange des Restaurants, #E85D04, wurde auf dem Button zu #BB4900, damit weißer Text die Kontrastprüfung bestand. Dunkler Text auf dem echten Orange hätte sie ebenfalls bestanden.

Alle vier Systeme bestanden jede Kontrastprüfung. Die Prüfungen fragten, ob jedes System korrekt war. Keine fragte, ob sich zwei Systeme unterschieden.

Was ist die falsche Lösung?

Die schnelle Lösung ist eine Tabelle. Restaurant bedeutet runde Ecken und eine freundliche Schrift. Klinik bedeutet großen Text. Entwicklertool bedeutet kantig und dunkel.

Das ist eine Sackgasse. Eine Tabelle ist eine Vorlage mit mehr Zeilen. Sie scheitert am ersten Briefing, das niemand eingetragen hat, und macht aus jedem Restaurant der Welt dasselbe Restaurant. Genau diese Gleichförmigkeit soll das Tool überwinden.

Mir wurde die Liste der Befunde vorgelegt. Meine Entscheidung bestand aus einem Satz:

Alles richtig. Löse es intelligent, ohne starre Vorgaben.

Starre Vorgaben sind die Tabelle. Intelligent heißt, jeden Wert aus diesem Briefing und dieser Marke abzuleiten, mit einer Bandbreite, deren Unterschiede ein Mensch sehen kann. Hier ist dieselbe Regel ausgeschrieben, damit Sie sie Ihrem eigenen Tool geben können:

Füge keine Nachschlagetabelle pro Branche oder Kategorie hinzu. Leite jeden Wert aus diesem Briefing und dieser Marke ab: Textgröße, Schriftart, Ecken, Abstände, Farbrollen, Bewegung. Nutze eine Bandbreite, deren Unterschiede mit dem Auge erkennbar sind. Lies heraus, für wen das Produkt gedacht ist: Alter, Sprachen, welche Schrift zuerst kommt, standardmäßig hell oder dunkel, Nutzung am Schreibtisch oder unterwegs. Schreibe die Begründung für jeden Wert in den Bericht. Wenn du etwas im Briefing nicht verstehen konntest, sage was und wie man es dir geben soll. Melde niemals, dass nichts zu tun ist.

Wie testet man „unterschiedlich“?

„Mach sie unterschiedlich“ kann ein Tool weder bestehen noch verfehlen. Einen Zahlenwert schon.

Also wurde der Unterschied messbar. Für jedes Systempaar vergleicht die Engine, was ein Mensch auf einen Blick sieht: Farbe, Schrift, Größen, Ecken, Schatten und Abstände. Sie liefert einen Abstand: 0 bedeutet identisch, 1 bedeutet in allem verschieden. Die Untergrenze liegt bei 0.20. Liegt ein Paar der Testbriefings näher beieinander, schlägt die Testsuite fehl. Eine Änderung, die die Testsuite nicht besteht, wird nicht übernommen.

Miss für jedes Ergebnispaar, wie weit es bei den Dingen auseinanderliegt, die ein Mensch auf einen Blick sieht: Farbe, Schrift, Größen, Ecken, Schatten und Abstände. Gib mir eine Zahl pro Paar, wobei 0 identisch bedeutet und 1 in allem verschieden. Lege eine Untergrenze fest. Lass die Tests fehlschlagen, wenn ein Paar näher beieinanderliegt als diese Untergrenze.

Die Arbeit am eigenständigen Charakter floss noch am selben Tag ein: 44 Änderungen zwischen 09:22 und 16:31. Der Rest von 4.0 brauchte fünf weitere Wochen.

Wie sehen die vier jetzt aus?

Der Text der Klinik ist größer, weil das Briefing sagt, wer ihn liest. So steht es auch im Bericht. Das Datenbanktool öffnet sich dunkel, weil sein Briefing es verlangt. Jedes System hat eine eigene Schrift für Überschriften und liefert die Möglichkeit mit, beide Schriften zu laden. Aus dem Informationsblau sind vier verschiedene Blautöne geworden, jeweils auf die Marke abgestimmt.

Zwei Systeme teilen weiterhin 16px-Text und 2px-Ecken: das Datenbanktool und die Zahlungs-App. Sie unterscheiden sich in Schrift, Farbe und Layout. Deshalb beträgt ihr Abstand 0.46 und nicht null.

Die sechs Abstände liegen über der Untergrenze von 0.20:

Eines stimmt noch immer nicht. Der Restaurant-Button hat in 4.0.0 die Farbe #CA5000. Sie liegt näher an der Markenfarbe #E85D04 als das #BB4900 vom September, ist aber weiterhin nicht das Orange der Marke.

Die vier Seiten sind ordentlich. Keine ist eine Seite, vor der man stehen bleibt und staunt. Das habe ich für diese Veröffentlichung akzeptiert: 4.0 heißt Foundations, weil sie genau diese Grundlagen schafft. Am Morgen des Versuchs hatte die Engine 3,315 Tests. Version 4.0.0 wurde mit 13,059 veröffentlicht.

War sie veröffentlicht, als ich es sagte?

Nein. Dieselbe Art von Prüfung hätte das erkannt.

Am 2. November markierte ich 4.0.0 als veröffentlicht. Am 11. November sah ich nach, was jemand bekommt, der sie zum ersten Mal installiert. Die öffentliche Paketregistrierung, von der ein Installationsbefehl herunterlädt, lieferte noch immer 3.2.0, veröffentlicht am 23. September. Die Versionshinweise sagten 4.0. Die Installation sagte 3.2. Das blieb zehn Tage so, bis 4.0.0 am 12. November hochgeladen wurde.

Es ist derselbe Fehler wie im September. Ich hatte meine Seite geprüft: den Code, die Versionsmarkierung, die Hinweise. Ich hatte nicht geprüft, was bei einer Person ankommt. Diese Prüfung gehört jetzt zu jeder Veröffentlichung:

Installiere das Paket nach jeder Veröffentlichung auf einem sauberen Rechner aus der öffentlichen Paketregistrierung, so wie ein neuer Nutzer es tun würde. Gib die Version aus. Stimmt sie nicht mit der Veröffentlichung überein, ist diese nicht verfügbar. Melde es mir, bevor jemand anderes es entdeckt.

Wenn Sie ein Tool bauen, das etwas erzeugt

• Testen Sie vier Ergebnisse gegeneinander, statt nur eines auf Korrektheit zu prüfen.
• Wählen Sie Testeingaben, die nichts gemeinsam haben sollten, statt einfacher Eingaben.
• Leiten Sie jeden Wert aus der Eingabe ab, statt Gleichförmigkeit mit einer Tabelle pro Kategorie zu beheben.
• Messen Sie den Abstand zwischen Ergebnissen und setzen Sie eine Untergrenze, statt „mehr Vielfalt“ zu verlangen.
• Lassen Sie das Tool sagen, was es übersprungen hat, statt es unverstandene Angaben still übergehen zu lassen.
• Installieren Sie Ihr eigenes Produkt wie ein neuer Nutzer, statt Ihren Versionshinweisen zu vertrauen.

Die Frage, die ich erwarte: Vier Briefings sind eine kleine Stichprobe. Warum also darauf vertrauen? Ich nutze sie nicht als Maßstab. Vier Briefings, die nichts gemeinsam haben sollten, reichen aus, um ein Tool zu erkennen, das alles gleich aussehen lässt. Und es sind wenige genug, um sie auf einem Bildschirm nebeneinander mit dem Auge zu beurteilen. Den Rest deckt die Untergrenze ab: Dieser Test läuft bei jeder vorgeschlagenen Änderung an der Engine.

ux-skill ist kostenlos und quelloffen. Die Projektseite enthält die Details und den Link zum Code.