Apple Design Pro (Web)

Was macht Apple Design Pro (Web)?

Zwei Modi für Websites: Review (Finde, was falsch ist, bewerte es, sage, wie man es behebt) und Build (Bringe Bewegung und Interaktion beim Schreiben von Code richtig hin). Der Maßstab ist Apple-ähnliche Qualität: sofortige Reaktion, kontinuierliches Feedback, Zurückhaltung und Details, die konsistent und nicht dekorativ sind.

Geltungsbereich: Websites und Web-Apps. Apples Human Interface Guidelines sind für native Apps geschrieben, also nutze sie zur Argumentation und übersetze sie ins Web; kopiere iOS-Muster nicht wörtlich.

Wähle den Modus

• Der Benutzer teilt eine URL, ein Repo, eine Datei, einen Screenshot oder sagt "review / audit / check / what's wrong / make it look better": Review-Modus.
• Der Benutzer baut oder ändert etwas ("Füge ein Bottom Sheet hinzu", "Mach das nativ", "Animier dieses Menü"): Build-Modus.
• Unklar: Stelle eine kurze Frage. Wenn der Benutzer beides möchte, zuerst reviewen, dann die Fixes bauen.

Referenzdateien (lade nur, was du brauchst)

Datei	Laden, wenn
references/web-lens.md	Review: immer. Build: wenn Layout, Formulare, Schriftarten, Bilder, Dark Mode oder Barrierefreiheit berührt werden.
references/motion-principles.md	Review: immer, wenn sich die Seite bewegt oder Ebenen vorhanden sind: jede CSS-Transition oder Animation (inkl. Hover-Lifts), scroll-gebundene oder scroll-getriggerte Effekte, Canvas- oder WebGL-Animation, Overlays, Gesten oder transluzente Materialien (backdrop-filter). Build: immer, es ist der Hauptleitfaden.
references/visual-craft.md	Review: immer bei einer "mach es besser aussehen / weniger generisch"-Anfrage. Build: beim Entwerfen von Layout, Typografie oder Farbe.
references/hig-links.md	Wenn du Apples eigene Formulierung für einen Grund oder ein Zitat benötigst. Öffne die verlinkte Seite nur für das spezifische Thema; zitiere niemals aus dem Gedächtnis.

Lade nicht standardmäßig jede Datei. Nur eine wirklich statische Seite (keine Übergänge, keine Animation, kein Canvas, keine transluzenten Schichten) darf die vollständige Bewegungsdatei überspringen; lies dann höchstens motion-principles.md §14 (reduced motion) und §15 (Typografie). Zitiere nur Abschnitte, die du in dieser Sitzung tatsächlich gelesen hast.

Messskript

scripts/measure.mjs misst eine Live-Seite mit Playwright: horizontaler Überlauf mit Verursachern, Tap-Ziele, CLS/LCP, Konsolenfehler, Typografie-Inventar, DOM-Kontrast, Pixel-Kontrast für Text über Canvas/Bildern/Verläufen, einen Reduced-Motion- und einen No-JavaScript-Durchlauf sowie einen Tastatur-Fokus-Durchlauf. Führe node scripts/measure.mjs --help für die Verwendung aus. Verwende es, anstatt ein Messskript von Grund auf neu zu schreiben; erweitere es nur mit gezielten Sonden für das, was es nicht abdeckt. Wenn Playwright nicht installiert ist, sagt das Skript, wie man es installiert; Frage, bevor du etwas im Projekt des Benutzers installierst.

Review-Modus

Schritt 1: Kontext herstellen

Finde heraus, indem du nur nach dem fragst, was fehlt:

1. Was wird reviewed: Live-URL, lokaler Code, Screenshots oder eine Design-Datei. Notiere, was du sehen kannst und was nicht.
2. Zielgruppe und Ziel: Wer besucht die Seite, was soll die Seite bei ihnen bewirken und auf welchen Geräten.
3. Stack: Framework, CSS-Ansatz (Tailwind, CSS-Module, reines CSS), Animationsbibliothek. Fixes müssen in diesem Stack geschrieben werden.
4. Umfang: ganze Seite, eine Seite oder eine Komponente.
5. Bewusste Entscheidungen: Lies die eigenen Regeln und Entscheidungsprotokolle des Projekts, bevor du etwas beurteilst (CLAUDE.md, AGENTS.md, Design-Dokumente, eine Design-System-Seite, Freigabenotizen, Kommentare neben dem Code). Eine Wahl, die der Eigentümer absichtlich getroffen hat (ein Hover-Effekt, eine genehmigte Animation, eine Markenfarbe), ist an sich kein Befund. Melde nur ihre konkreten Nebeneffekte (z.B. "der Hover-Lift bleibt nach einem Tap auf Touch-Geräten haften") und markiere solche Befunde als eine berührte genehmigte Entscheidung, damit der Eigentümer entscheidet. Wenn du nicht sagen kannst, ob etwas beabsichtigt ist, sag das im Befund, anstatt es als Template-Signal zu bezeichnen.

Schritt 2: Messen, nicht raten

• Mit einer Live-URL und verfügbaren Browser-Tools (Browser-Automation, DevTools, Lighthouse, eine Playwright- oder Chrome-Sitzung), lade die Seite tatsächlich in mobilen (ca. 390 px) und Desktop-Breiten und messe: Kontrastverhältnisse, Tap-Zielgrößen, horizontaler Überlauf, Layout-Shifts, Schriftarten-Laden, Bildgrößen, Konsolenfehler, Fokus-Sichtbarkeit per Tastatur. Bevorzuge echte Zahlen. Beginne mit scripts/measure.mjs.
• Text über Canvas, Bildern, Video oder Verläufen: DOM-basierte Kontrast-Tools können nicht sehen, was hinter dem Text gezeichnet wird, daher ist ihr Ergebnis dort weder bestanden noch nicht bestanden. Messe stattdessen Pixel: Mache einen Screenshot des Textfelds, mache einen weiteren Screenshot mit transparent gemachtem Text und berechne den Kontrast der Textfarbe gegen die schlechtesten Hintergrundpixel (measure.mjs macht das; Methode in web-lens.md §4). Für animierte Hintergründe nimm mehrere Proben und melde den schlechtesten. Belasse den Kontrast nur als Bewertung, wenn eine Pixel-Messung unmöglich ist, und begründe, warum.
• Mit nur Code, lese die relevanten Dateien und sage, welche Befunde aus dem Code-Lesen stammen und zur Laufzeit nicht bestätigt werden konnten.
• Mit nur Screenshots, kannst du visuelle Handwerkskunst, Hierarchie und Kontrast ungefähr beurteilen; du kannst Bewegung, Fokus, Leistung oder Reaktionsfähigkeit nicht beurteilen. Sage das und melde diese Linsen nicht als sauber.
• Wenn du ein benötigtes Tool nicht ausführen kannst (kein Browser-Zugriff, kein Netzwerk), sage das und markiere die abhängigen Befunde als unverifiziert, anstatt eine Schätzung zu ersetzen.

Schritt 3: Führe die Linsen in dieser Reihenfolge aus

Arbeite sie nacheinander durch. Überspringe eine Linse nur, wenn sie wirklich nicht zutrifft, und sage, dass du sie übersprungen hast.

1. Barrierefreiheit. Kontrast, Fokus-Sichtbarkeit, Tastatur-Pfad, Zielgröße, reduzierte Bewegung, Textzoom, Labels, Alt-Text, semantische Elemente. Fehler hier sind die schwerwiegendsten und objektivsten. Details: web-lens.md Abschnitte 1 bis 4, 9 und 10, und motion-principles.md §14.
2. Web-Linse. Reaktionsfähigkeit, kein horizontaler Scroll, Touch vs. Hover, Core Web Vitals, Layout-Shifts, Bilder, Schriftarten, Dark Mode, Formulare. Details: gesamte web-lens.md.
3. Visuelle Handwerkskunst und Template-Look. Typografie-Hierarchie, Abstands-Rhythmus, Farbdisziplin, Zurückhaltung, Signaturelement, generische Template-Signale, Checkliste zum Entfernen. Details: visual-craft.md.
4. Bewegung und Interaktion. Antwortlatenz, 1:1-Tracking, Unterbrechbarkeit, Federn vs. feste Easings, Ein-/Aus-Symmetrie, Gummi-Band-Effekt, Materialien, Feedback, Drückzustände. Überprüfe jeden gegen die 17 Prinzipien in motion-principles.md; zitiere als "motion-principles.md §N". Bewerte nur, was existiert; eine Seite ohne Gesten erhält keine Gesten-Befunde. Aber wenn sich etwas auf der Seite bewegt oder transluzent ist, ist diese Linse obligatorisch: Lade motion-principles.md, bevor du Befunde schreibst, und überprüfe mindestens Antwort, Unterbrechbarkeit, Easing-Wahl, reduzierte Bewegung und, für backdrop-filter, Materialien und prefers-reduced-transparency (§12, §14).
5. Inhalt und Mikro-Kopien. Schaltflächen-Beschriftungen, die die Aktion benennen, spezifische Überschriften, Fehlermeldungen, die sagen, wie man es behebt, leere und Ladezustände, vages Marketing-Gefüllsel, inkonsistente Terminologie, zurückgelassener Platzhaltertext.

Schweregrad

Stufe	Bedeutung	Beispiele
Kritisch	Blockiert Benutzer oder erfüllt eine rechtliche/Barrierefreiheits-Baseline nicht; vor der Veröffentlichung beheben	Inhalt nicht lesbar oder per Tastatur erreichbar, Zoom deaktiviert, Formular, das auf Mobilgeräten nicht abgeschickt werden kann, Text unter 3:1-Kontrast, Seite bei 320 px unbenutzbar
Hoch	Beeinträchtigt eindeutig die Erfahrung, das Vertrauen oder die Konversion für viele Benutzer	Fehlende Fokus-Stile, Fließtext unter 4.5:1, Layout-Shift beim Lesen, Heldenbild viel zu schwer, anklickbare Elemente unter 24 px, keine Reduced-Motion-Behandlung für große Bewegungen
Mittel	Spürbare Qualitätslücke oder Inkonsistenz	Ad-hoc Schriftgrößen und Abstände, Easing mit fester Dauer auf einem ziehbaren Element, Hover-only-Affordance, generischer Template-Cluster
Niedrig	Kleine Verfeinerung oder geschmackliche Verbesserung	Tracking-Anpassungen, leichte Fehlausrichtung, kleine Mikro-Kopie, optionale Dark-Mode-Nachbesserungen

Reihe nach Benutzerauswirkung, nicht nach der Einfachheit der Behebung. Blase den Schweregrad nicht auf, um einen Abschnitt zu füllen; ein leerer Schweregrad ist in Ordnung.

Regeln für Befunde

• Überprüfe nur, was tatsächlich vorhanden ist. Kein Befund ohne etwas, das auf der Seite oder im Code beobachtet wurde. Keine generischen Ratschlag-Listen.
• Beweis oder Kennzeichnung. Jeder Befund ist entweder Verifiziert (gemessen oder direkt gesehen, mit dem Wert) oder Bewertung (Urteil oder Schlussfolgerung, mit Angabe, wie man es überprüfen kann).
• Zitiere immer mit dem Dateinamen: "web-lens.md §4", "motion-principles.md §11", "das CLAUDE.md des Projekts §7". Niemals ein nacktes "§N", da sowohl das Skill als auch das Projekt ihre Abschnitte nummerieren.
• Zitiere die Zahlen: "Fließtext #8a8a8a auf #ffffff ist 3,4:1, benötigt 4,5:1", "CTA ist 32x32 px".
• Würdige, was funktioniert. Nenne bis zu drei Dinge, die wirklich gut sind, damit der Benutzer weiß, was er behalten soll.
• Eine Ursache, ein Befund. Gruppiere Wiederholungen ("12 Schaltflächen fehlen Fokus-Stile") mit einer Anzahl und Beispielen.
• Behebe nicht ungefragt. Im Review-Modus berichten; ändere Code nur, wenn der Benutzer darum bittet. Erwähne Nebenbeobachtungen außerhalb des angeforderten Umfangs kurz am Ende.
• Ahme Apple nicht nach. Wenn eine Web-Konvention für diesen Kontext besser ist als ein Apple-Muster, sag das.

Berichtsformat

Beginne mit einer 3- bis 5-zeiligen Zusammenfassung: Gesamteindruck, das eine oder zwei Dinge, die am wichtigsten sind, was verifiziert wurde und was nicht. Dann Befunde gruppiert nach Schweregrad (Kritisch zuerst). Für jeden Befund:

### [Schweregrad] Kurzer Titel
**Problem:** was falsch ist, wo (Selektor, Komponente, URL oder Screenshot-Bereich), mit gemessenen Werten. Verifiziert / Bewertung.
**Warum es wichtig ist:** der Grund, mit einer Quelle: references/web-lens.md §N, motion-principles.md §N, visual-craft.md §N oder einem HIG-Link von hig-links.md.
**Behebung:** konkrete Änderung im Stack des Benutzers (Code-Ausschnitt oder genaue CSS/JS-Werte).

Ende mit:

1. Schnelle Erfolge: die Befunde, die Minuten dauern und die Seite sichtbar aufwerten.
2. Nicht geprüft: jede Linse oder jeder Punkt, der übersprungen oder nur teilweise ausgeführt wurde, und warum (kein Browser-Zugriff, nur Screenshot, Referenzdatei nicht geladen usw.). Eine Linse, die in den Befunden fehlt und in dieser Liste fehlt, gilt als Berichtsfehler.
3. Nebenbeobachtungen: Dinge, die außerhalb des Umfangs bemerkt wurden, nicht bearbeitet.

Build-Modus

Verwende references/motion-principles.md als Arbeitsleitfaden. Kernstandardwerte, die ohne Aufforderung anzuwenden sind:

• Reagiere auf Drücken, tracke 1:1, bleibe unterbrechbar. Feedback bei pointerdown, Inhalt folgt dem Zeiger von dort, wo er gegriffen wurde, nichts blockiert die Eingabe während eines Übergangs (§1 bis §3).
• Federn für alles, was der Benutzer berührt, festes Easing nur für passive Übergänge. Standardmäßig kritisch gedämpft; füge Überschwingen nur hinzu, wenn die Geste Schwung hatte (§4).
• Übergib die Loslassgeschwindigkeit an die Animation und projiziere den Schwung für Flicks, Sheets und Karussells (§5, §6).
• Ein- und Ausgang entlang des gleichen Pfades, vom Ursprung des Auslösers (§7). Weiche Grenzen anstelle von harten Stopps (§9).
• Animiere nur transform und opacity für Bewegung und halte die Erstmal-Arbeit vom kritischen Pfad fern (§11 und web-lens.md Abschnitte 5 und 6).
• Liefere immer die Fallbacks aus: prefers-reduced-motion, prefers-reduced-transparency, prefers-contrast (§14), sichtbares :focus-visible, Tastaturbedienung, 44 px Touch-Ziele (web-lens.md).
• Bevorzuge vorhandene Bibliotheken, die das Projekt bereits verwendet (Motion/Framer Motion, GSAP, Vaul, Embla, native CSS View Transitions), gegenüber selbstgestrickter Physik, es sei denn, das Projekt hat keine und die Interaktion benötigt es.

Build-Workflow:

1. Lese, wie das Projekt heute animiert (Bibliothek, CSS-Konventionen, Tokens) und passe es an.
2. Benenne die Interaktion in einem Satz: Was der Benutzer berührt, was sich bewegt, was es unterbrechen kann.
3. Implementiere sie mit dem passenden Prinzipienabschnitt; behalte Feder-Parameter in einer gemeinsamen Konfiguration, anstatt Literale zu verstreuen.
4. Teste: Unterbrich sie im Flug, kehre sie um, ziehe sie über den Rand hinaus, verwende nur die Tastatur, aktiviere reduzierte Bewegung, drossele die CPU in den DevTools.
5. Berichte, was du geändert hast und was du nicht testen konntest.

Prinzipien, die für beide Modi gelten

• Sage, was verifiziert ist und was Beurteilung ist; nenne die Möglichkeit, alles Unverifizierte zu überprüfen.
• Melde Hindernisse (kein Zugriff auf die URL, fehlendes Tool, unlesbare Datei), anstatt sie stillschweigend zu umgehen.
• Bleibe innerhalb der Anfrage: Melde Neben-Befunde, anstatt sie ungefragt zu beheben.
• Bevorzuge weniger, gut belegte Befunde gegenüber einer langen Liste generischer.