Interface-Guidelines, die ein KI-Agent tatsächlich befolgen kann

Das Muster in Agent-Skill-Katalogen ist es, Apples Human Interface Guidelines – oder Material bzw. die Barrierefreiheits-Richtlinien einer Plattform – zu nehmen und sie so aufzubereiten, dass ein Agent sie vor dem Bau des UIs lädt. Ein veröffentlichtes Set unterteilt die HIG in viernzehn Skills, die Plattformen, Grundlagen und Komponenten abdecken: Layout, Controls, Dialoge, Menüs, Suche. Andere liefern es als einzelnen Design-Skill aus, der native Komponenten, korrekte Typografie und semantische Farben verspricht.

Dies ist ein guter Instinkt. Ein Coding-Agent, der ohne Anleitung einen iOS-Einstellungen-Bildschirm erstellen soll, wird etwas produzieren, das zwar funktioniert, sich aber subtil falsch anfühlt: ein Modal, wo ein Push konventionell wäre, ein Control, das im Web existiert, aber nicht auf der Plattform, oder Touch-Targets, die für eine Maus dimensioniert sind. Das Laden der Plattform-Regeln behebt eine ganze Klasse von Fehlern – und das kostengünstig.

Es bewirkt jedoch auch etwas, das viele nicht erwarten und über das man präzise sein muss.

Diese zweite Zeile ist das Kernproblem, und das ist nicht spezifisch für Apple. Eine nicht falsifizierbare Instruktion kann das Verhalten nicht ändern, da das Modell sie mit jeder beliebigen Interpretation des Wortes erfüllen kann. Fordert man „Klarheit“, erhält man die mediane Vorstellung des Modells von Klarheit – die dieselbe ist wie die jedes anderen Modells. Deshalb konvergieren so viele agenten-generierte UIs zu denselben fast schwarzen Oberflächen, derselben Palette aus einer Akzentfarbe und Grau sowie denselben gleichmäßig abgerundeten Cards.

Wir haben dasselbe Versagen in der Praxis gemessen. Von 299 öffentlichen DESIGN.md-Dateien – Dokumente, die Entwickler explizit schreiben, damit ein Agent ihnen folgt – enthalten 54 % mindestens ein nicht messbares Adjektiv, am häufigsten „clean“ (39 %) oder „modern“ (36 %), und 44 % nennen keinen einzigen konkreten Größenwert. Diese Dateien lesen sich wie eine Design-Richtung und funktionieren lediglich als Absichtserklärung.

Hier ist der Punkt, der Leute überrascht, die einen HIG-Skill installieren in der Hoffnung, dass ihre App plötzlich gut aussieht: Plattform-Guidelines sind bewusst allgemein gehalten. Jede App auf der Plattform folgt ihnen. Genau das ist der Sinn – ein Nutzer soll eine App öffnen können, die er noch nie gesehen hat, und sofort wissen, wie sie funktioniert. Konformität ist das Ziel, Identität explizit nicht.

Ein HIG-Skill kann die Benutzeroberfläche also *korrekt* machen – richtige Komponenten, richtige Navigation, richtige Zielgrößen, richtiger Kontrast –, aber korrekt ist nicht dasselbe wie charakteristisch. Wenn zwei Teams dieselbe Richtlinie und keinen weiteren Design-Kontext laden, sollten sie austauschbare Interfaces produzieren. Das tun sie in der Regel auch.

Sobald man dies als zwei separate Aufgaben betrachtet, ist die Lösung offensichtlich und die Schichten stehen nicht mehr im Konflikt zueinander.

Halten Sie diese in separaten Dateien. Es ist verlockend, die Brand in den HIG-Skill zu integrieren, damit nur eine Datei geladen werden muss. Das geht jedoch beim ersten Plattform-Update oder dem ersten Rebranding schief, da man dann mühsam entwirren muss, welche Sätze zu welcher Ebene gehörten.

Der Test ist einfach: Könnte jemand das Ergebnis betrachten und ohne Diskussion sagen, ob die Regel befolgt wurde? Wenn zwei vernünftige Personen uneinig wären, wird es der Agent auch sein, und er wird die Unstimmigkeit zugunsten seiner Defaults lösen.

Beachten Sie, wie viele der rechten Einträge Verbote sind. Das ist keine stilistische Entscheidung: Eine Präferenz fügt eine Option hinzu, während ein Verbot alle anderen entfernt. „Verwenden Sie unser Grün“ lässt jeden generischen Default weiterhin zu; „führen Sie niemals eine Farbe ein, die kein Token ist“ hingegen nicht. In unserem Korpus listeten 76 % der Dateien nur Präferenzen auf, was eine präzise Beschreibung dafür ist, warum sie nicht funktionieren.

Dies passiert seltener, als befürchtet, da die beiden Ebenen meist unterschiedliche Fragen adressieren. Wenn es dennoch geschieht, handelt es sich in der Regel um einen von drei Fällen, wobei nur einer davon ein echter Konflikt ist.

1. Barrierefreiheits-Minima versus Markenfarbe. Kein Konflikt. Das Minimum gewinnt, und die Akzentfarbe muss für diese Oberfläche angepasst werden. Ein Agent, dem dies explizit mitgeteilt wurde, wird es tun; ein Agent, der wählen darf, wird meist die Markenfarbe beibehalten, da diese Anweisung spezifischer klang.
2. Plattform-Konvention versus hauseigenes Pattern. Ein echter Trade-off. Einmal entscheiden, schriftlich fixieren, was gewinnt und warum, und dies in der Identity-Ebene hinterlegen, damit es nicht pro Screen neu debattiert werden muss.
3. Plattform-Standard-Styling versus eigene Tokens. Kein Konflikt, auch wenn es so aussieht. Richtlinien legen fest, welches Steuerelement zu verwenden ist; sie spezifizieren selten die exakte Farbe. Verwenden Sie die Komponente der Plattform, gestaltet mit Ihren Tokens.

1. 1

   Plattform-Ebene als Skill oder Rules-File laden

   Was auch immer Ihr Agent unterstützt – ein Skill, .cursor/rules, .devin/rules oder ein Abschnitt in CLAUDE.md. Halten Sie es so nah wie möglich an der ursprünglichen Richtlinie, damit es bei Plattform-Updates vollständig ersetzt werden kann.

2. 2

   Identity-Ebene im Repo hinterlegen

   Eine Token-Datei sowie eine DESIGN.md mit Ihren Regeln und Verboten. Diese muss im Repository liegen und nicht in einem Prompt, da der Agent sie bei jeder Aufgabe erneut lesen muss – ebenso wie die nächste Person.

3. 3

   Priorität einmalig festlegen

   Ein Satz am Anfang der Identity-Datei, der definiert, was im Konfliktfall gewinnt.

4. 4

   Am Screen testen, den niemand designt hat

   Fordern Sie etwas Plausibles an, das keine der Ebenen vorhergesehen hat – einen Empty State, einen Berechtigungsfehler, eine Pagination-Steuerung. Was der Agent hier erfindet, ist das Erscheinungsbild jedes nicht abgedeckten Falls; das ist Ihr echtes Maß für die Abdeckung.

Der letzte Schritt ist der wichtigste. Beide Ebenen decken die Fälle ab, an die jemand gedacht hat. In einem von Agenten erstellten Produkt sind die meisten Screens Fälle, an die niemand gedacht hat. Deshalb muss die Identity-Ebene allgemeine Regeln und Verbote definieren, anstatt Komponenten aufzuzählen. Mehr dazu, was in diese Datei gehört: was eine DESIGN.md ist.