umairmsm/wp-design

Phase 2: Design

Ziel: Der Owner hat einen Look freigegeben, den er auf einem Telefon und einem Laptop gesehen hat. Er ist als Tokens dokumentiert, sodass er durch Kopieren in eine WordPress-Skin umgewandelt und später ersetzt werden kann, ohne Funktionen zu verlieren.

Schritte

1. Richtung. Befülle docs/DESIGN_DIRECTION.md des Projekts: Leitstern, Zielgruppe, wie wir nicht aussehen dürfen (Wettbewerber, Templates) und die unverhandelbaren Anforderungen. Biete höchstens zwei oder drei Richtungen an, als kleine Moodboards oder Hero-Mockups, nicht als vollständige Websites.
2. Prototyp in static/. Reines HTML und CSS. css/tokens.css verwendet dieselben Namen wie die skins/default/tokens.css des Themes. Komponenten nutzen ausschließlich Tokens. Echte Struktur (Header, Hero, Karten, Formular, Footer), Platzhaltertexte, keine Preise und keine Rechtstexte.
3. Barrierefreiheit von Anfang an:
   • Kontrast ≥ 4,5:1 für Text;
   • sichtbarer Fokus;
   • eine H1;
   • ein Skip-Link;
   • Tastaturnavigation;
   • prefers-reduced-motion wird respektiert. Überprüfe den Prototyp mit axe (Browsererweiterung), bevor du ihn zeigst.
4. Owner-Review. Screenshots jeder Seite bei Telefonbreite (375 px) und Laptopbreite (1440 px). Halte das Freigabedatum in DESIGN_DIRECTION.md fest und speichere die Screenshots in docs/design/.
5. Schriftarten: Selbst hosten als .woff2-Dateien, auf die benötigten Sprachen beschränken, die Lizenz prüfen und die ein oder zwei Schriftarten für den ersten Bildschirm vorladen (benenne sie *-preload.woff2). Keine Google Fonts-Anfragen irgendwo.
6. Übertragung nach WordPress (references/design-system.md):
   • Kopiere die Tokens in die Skin;
   • Verschiebe das Komponenten-CSS in skin.css;
   • Lege Templates mit den Render-Funktionen des Cores an;
   • Füge Skin-Part-Überschreibungen nur dort hinzu, wo das Markup abweichen muss. Das Aussehen ändert sich; die Daten- und Markup-Verträge des Cores bleiben bestehen.
7. Spätere Neugestaltungen sind neue Skins: Kopiere skins/default nach skins/<name>, ändere Tokens, Vorschau mit ?skin=<name> (Admins) und Umschaltung über die Option <prefix>_skin nach Freigabe.

Tor (abgehakt in SITE_STATUS.md)

• DESIGN_DIRECTION.md geschrieben; Owner-Freigabe mit Screenshots dokumentiert
• Tokens definiert; Komponenten verwenden ausschließlich Tokens
• Schriftarten selbst gehostet; 0 Anfragen an Google Fonts

Lektionen

• Das festgelegte Design änderte sich, als der Geschäftspartner seinen eigenen Redesign-Entwurf einreichte. Da der Look eine Skin war, blieb beim Wechsel jedes Feature erhalten. Baue jedes Design als Skin, selbst das erste.
• Kopiere nicht die Farbpalette, Schriftkombination oder das Layout eines Wettbewerbers. Owners bemerken es, und Besucher erinnern sich nicht an dich.
• Eine reine Test-Skin (dev-*) zum Ausprobieren von Ideen erscheint nie auf der Produktionsseite.
• Falls die Skills frontend-design oder design-motion-principles installiert sind, verwende sie für Richtung und Bewegung.