Was in der Praxis tatsächlich gemacht wird
Das Muster in Agent-Skill-Katalogen ist es, Apple's Human Interface Guidelines (oder Material bzw. die Barrierefreiheits-Guidelines 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 vierzehn 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.
Das 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 kosteneffizient.
Es bewirkt jedoch auch etwas, das viele nicht erwarten und über das man präzise sein sollte.
Was die Übersetzung überlebt und was nicht
| Beispiel | Reaktion des Agenten | |
|---|---|---|
| Präskriptive Regeln | Mindestgröße von Touch-Targets, welches Control für welche Aufgabe, wann ein Sheet besser ist als ein Push, Mindestkontraste | Wendet diese zuverlässig an. Diese Regeln sind prüfbar, daher ist eine falsche Antwort sichtbar falsch |
| Prinzipien | „Klarheit“, „Zurückhaltung“, „Tiefe“ | Stimmt ihnen zu und tut dann genau das, was es ohnehin tun wollte |
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 Bedeutung erfüllen kann, die es dem Wort zuschreibt. 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-erstellte UIs zu denselben fast schwarzen Oberflächen, derselben Palette aus einer Akzentfarbe und Grau sowie denselben gleichmäßig abgerundeten Cards.
Ein Agent kann einer Regel folgen. Einem Prinzip kann er nur zustimmen.
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.
Was eine Plattform-Guideline Ihnen nicht zu geben versucht
Hier ist der Punkt, der Leute überrascht, die einen HIG-Skill installieren in der Erwartung, 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 sollte in der Lage sein, eine App zu öffnen, 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.
Das ist ein Feature, bis es keines mehr ist
Für ein Utility, ein Plugin oder alles, was in die Umgebung eines anderen eingebettet ist, ist es die richtige Lösung, sich anzupassen; die Richtlinie ist dann das gesamte Briefing. Die Diskrepanz wird erst sichtbar, wenn das zu bauende Objekt ein Produkt ist, das erkennbar sein muss – und das bemerkt man meistens etwa beim fünften Screen.
Der Zwei-Schichten-Aufbau
Sobald man dies als zwei separate Aufgaben betrachtet, ist die Lösung offensichtlich und die Schichten stehen nicht mehr im Konflikt zueinander.
| Plattform-Schicht | Identity-Schicht | |
|---|---|---|
| Antworten | Wie soll sich dies hier verhalten? | Wie soll dies überall aussehen? |
| Quelle | Die Richtlinien der Plattform, als Skill oder Regeldatei | Ihr Token-Set und schriftliche Regeln im Repo |
| Änderung bei | Plattformänderung | Markenänderung |
| Fehler, falls fehlend | Korrekt aussehende UI, die sich auf der Plattform fremd anfühlt | Plattform-perfekte UI, die nicht von jeder anderen App zu unterscheiden ist |
Halten Sie diese in separaten Dateien. Es ist verlockend, die Marke in den HIG-Skill zu integrieren, damit nur eine Datei geladen werden muss. Das führt jedoch beim ersten Plattform-Update oder dem ersten Rebranding zu Problemen, da man mühsam entwirren muss, welche Sätze zu welcher Ebene gehörten.
Token specimen · real values
Ambient Sage
Live renderAmbient Sage's actual tokens — the same values its exports use.
Eine Regel schreiben, die ein Agent prüfen kann
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 Standardwerte lösen.
| Einverstanden mit | Befolgt | |
|---|---|---|
| Farbe | Verwenden Sie eine klare, moderne Palette | Verwenden Sie nur die semantischen Tokens. Niemals einen rohen Hex-Wert in einer Komponente. Ein Akzent pro Screen |
| Typografie | Die Typografie sollte raffiniert wirken | Zwei Schriftfamilien: Display und Body. Skalierungsschritte bei 1,25×. Niemals eine dritte Schriftschnitt-Stärke im Fließtext |
| Oberflächen | Halten Sie Oberflächen leicht und luftig | Cards sind flach. Kein Schatten auf einer flachen Oberfläche. Border 1px, border Token |
| Dark Mode | Unterstützen Sie den Dark Mode | Jede Farbroll muss in beiden Modi definiert sein. Veröffentlichen Sie niemals eine Änderung im Light Mode ohne das entsprechende Dark-Mode-Gegenstück |
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 Standard weiterhin zu; "führen Sie niemals eine Farbe ein, die kein Token ist" hingegen nicht. In unserem Korpus enthielten 76 % der Dateien nur Präferenzen – was eine präzise Beschreibung dafür ist, warum sie nicht funktionieren.
Wenn die Richtlinie und die Marke widersprüchlich sind
Dies geschieht seltener, als befürchtet, da die beiden Ebenen meist unterschiedliche Fragen adressieren. Wenn es dennoch passiert, handelt es sich in der Regel um einen von drei Fällen, wovon nur einer ein echter Konflikt ist.
- Barrierefreiheits-Minima gegenüber einer 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, behält in der Regel die Markenfarbe bei, da diese Anweisung spezifischer klang.
- Plattform-Konvention gegenüber einem internen 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.
- Plattform-Standard-Styling gegenüber Ihren Tokens. Kein Konflikt, auch wenn es so aussieht. Richtlinien legen fest, welches Steuerelement zu verwenden ist; sie legen selten die exakte Farbe fest. Verwenden Sie die Komponente der Plattform, eingefärbt mit Ihren Tokens.
Im File festlegen, welche Ebene gewinnt
Ein Agent, der zwei Dokumente ohne festgelegte Priorität vorliegen hat, wird bei jedem Durchgang willkürlich wählen, ohne mitzuteilen, welche Quelle genutzt wurde. Eine einzige Zeile („Bei Konflikten gewinnen Barrierefreiheits-Minima, dann Plattform-Konventionen, dann der House-Style“) eliminiert eine ganze Kategorie von Inkonsistenzen, die ansonsten am Output kaum zu diagnostizieren wären.
Praktisches Setup
- 1
Plattform-Ebene als Skill oder Rules-File laden
Unabhängig davon, was Ihr Agent unterstützt: ein Skill,
.cursor/rules,.devin/rulesoder ein Abschnitt in CLAUDE.md. Halten Sie die Inhalte so nah wie möglich an der ursprünglichen Richtlinie, damit sie bei Plattform-Updates vollständig ersetzt werden können. - 2
Identity-Ebene im Repo hinterlegen
Eine Token-Datei plus 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, die am Projekt arbeitet.
- 3
Priorität einmalig festlegen
Ein Satz am Anfang der Identity-Datei, der definiert, was im Konfliktfall gewinnt.
- 4
Am Screen testen, den niemand designt hat
Fordern Sie etwas Plausibles an, das keine der Ebenen vorgesehen hat: einen Empty State, einen Berechtigungsfehler, ein Pagination-Control. Was der Agent hier erfindet, ist das Erscheinungsbild jedes nicht abgedeckten Falls – und 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 einem 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.
Die Identity-Ebene als eine installierbare Datei
Jedes Identity Forge Kit wird in eine vollständige DESIGN.md (semantische Tokens für Light und Dark Mode, ein echtes Font-Pairing, Motive und explizite Verbote) sowie eine Token-Datei serialisiert. Sie existiert neben jeder geladenen Plattform-Richtlinie und steht nicht im Widerspruch zu ihr.
FAQ
Kann ein AI-Agent den Human Interface Guidelines von Apple folgen?
Den präskriptiven Teilen, ja: Wahl der Steuerelemente, Navigationsmuster, minimale Touch-Targets, Kontrast-Minima. Diese sind prüfbar, daher wendet der Agent sie zuverlässig an. Die prinzipiellen Teile (Klarheit, Zurückhaltung, Tiefe) können das Verhalten nicht ändern, da ein Agent eine nicht falsifizierbare Anweisung mit dem erfüllt, was er bereits unter diesem Wort versteht.
Wird ein HIG-Skill meine App gut aussehen lassen?
Er wird sie korrekt machen, was etwas anderes ist. Plattform-Richtlinien werden bewusst von jeder App auf der Plattform geteilt, damit Nutzer ihr Wissen übertragen können. Zwei Teams, die dieselbe Richtlinie und sonst nichts laden, sollten austauschbare Interfaces produzieren. Einzigartigkeit entsteht durch eine zweite Ebene: Ihre eigenen Tokens und Regeln.
Sollten Plattform-Richtlinien und mein Designsystem in einer Datei stehen?
Nein. Sie ändern sich in unterschiedlichen Zyklen (die eine bei Plattform-Updates, die andere bei Markenänderungen). Ein Zusammenführen würde bedeuten, später mühsam entwirren zu müssen, welche Sätze zu wem gehören. Nutzen Sie zwei Dateien und legen Sie fest, was im Konfliktfall gewinnt.
Was mache ich, wenn eine Markenfarbe ein Barrierefreiheits-Minimum nicht erfüllt?
Das Minimum gewinnt und die Akzentfarbe muss für diese Oberfläche angepasst werden. Legen Sie dies explizit in Ihren Regeln fest: Ein Agent, der wählen darf, behält meist die Markenfarbe bei, da diese Anweisung spezifischer klang als ein allgemeiner Hinweis zur Barrierefreiheit.
Woran erkenne ich, ob eine Regel gut genug für einen Agenten geschrieben ist?
Fragen Sie sich, ob ein Reviewer das Ergebnis betrachten und ohne Diskussion sagen könnte, dass die Regel befolgt wurde. „Verwenden Sie eine saubere Palette“ besteht diesen Test nicht. „Verwenden Sie nur die semantischen Tokens, niemals einen rohen Hex-Wert, eine Akzentfarbe pro Screen“ besteht ihn.