WithZeng/design-skills

Webseiten-Design

Lektionen aus dem Scientify-Redesign (2026-10): Das Design funktionierte erst, nachdem Entwürfe gezeigt und freigegeben wurden, ein einheitliches Seitensystem in jedem Abschnitt erzwungen wurde und die Überprüfung Kontrast- und Markup-Fehler aufdeckte, die Bewegungsbibliotheken mit sich bringen.

Arbeitsablauf und Gate-Meilensteine

1. Briefing. Produkt, Zielgruppe, Abschnitte, echte Beispieldaten und 1–2 Referenzseiten sammeln, die der Nutzer mag. Hat er keine, wähle 2–3 passende zum Seitentyp aus references/ui-references.md (Galerien, UI-Bibliotheken echter Produkte, Komponentenquellen) und zeige sie zur Freigabe. Mache Screenshots der Referenzen und speichere sie als --ref-Bilder; bei Empfehlungen zeige nummerierte Screenshots plus 2–3 Kombinationen zur Auswahl (Methode: ui-references, „Referenzen erfassen“).
2. Entwürfe vor Code. Bearbeite niemals Code für eine visuelle Änderung, bevor der Nutzer einen Entwurf freigegeben hat. Verwende den image-gen-Skill. Reihenfolge:
   1. Bei offener Richtung: ein Übersichtsbild pro Richtung (meist 2); der Nutzer wählt eine aus, bevor Detailarbeit beginnt. Dann ein ganzseitiges langes Bild (1024x1536), um das Seitensystem festzulegen.
   2. Ein Detailbild pro Abschnitt/Panel in voller Auflösung.
   3. Unterseiten, dann Interaktions-Storyboards (3–4 Bilder pro Interaktion) für Bewegungen. Zeige jede Runde, sammle Feedback, iteriere. Prompt-Vorlagen: references/draft-prompts.md.
3. Entwicklung nur der freigegebenen Entwürfe, hinter einer Vorschau-Route, bis der Nutzer sagt, die Live-Seite zu ersetzen. Muster: references/build-patterns.md.
4. Überprüfung vor jedem Commit/PR: references/verification.md.
5. Halte Entwürfe und Screenshots im gitignorierten Scratch-Ordner des Projekts (z.B. tmp/design/vN/), ein Ordner pro Runde, Prompts neben den Bildern gespeichert.

Seitensystem (was die „Zerrissenheit“ beseitigt hat)

Eine Seite fühlt sich wie ein Ganzes an, wenn jeder Abschnitt dasselbe System wiederverwendet. Lege die Werte des Systems aus den freigegebenen Entwürfen fest und schreibe sie in jeden Prompt und in die Code-Token:

• Einheitliche Hintergrundbehandlung für die gesamte Seite; vermeide Abschnitte, die jeweils eigene Bänder oder Verläufe erfinden.
• Ein Modul für Abschnitte (Container, Radius, Füllung, Rand, Abstand, Breite) und eine kleine Menge von Layouts darin, Abschnitt für Abschnitt wiederverwendet.
• Eine Typografie-Skala: dieselbe Größe und Stärke für jeden Abschnittstitel, ein Textstil für Fließtext, konsistente Abstände.
• Ein charakteristisches Element trägt die künstlerische Richtung (meist im Hero); alles andere bleibt zurückhaltender im Layout, reagiert aber dennoch auf Interaktion. Was dieses Element ist, ergibt sich aus dem Briefing, nicht aus einer Vorlage: siehe „Art Direction“ unten.
• Alle gezeigte Produkt-UI stammt aus DERSELBEN App (gleiche Navigation, gleiches Theme, gleiche Daten), sodass die Seite wie ein Produkt wirkt.
• Eine Palette, die ausreichend zurückhaltend ist, um das System kohärent zu halten (eine Seite verwendete reines Monochrom); das Logo behält seine Originalfarben. Verwende überall das echte Markenlogo, nie einen Buchstaben-in-einem-Quadrat-Platzhalter.
• Inhalt: realistische Daten aus der Domäne des Produkts (plausible Namen, Zahlen und Zeitangaben) und eine Namenskonvention für Dateien und Objekte, pro Projekt entschieden; kein Lorem ipsum, keine gefälschten Testimonials oder Statistiken, keine Schlagwort-Slogans.

App-UI und Authentifizierungsseiten

Dieselben Gate-Meilensteine gelten innerhalb eines Produkts, mit anderen Referenzen und Token:

• Referenzen stammen aus echter Produkt-UI (z.B. Refero, Produktscreenshots auf vergleichbaren Produktseiten, Komponentendokumentationen für Chat/Agent-Bildschirme), nicht aus Landingpage-Galerien.
• Verwende die eigenen Token und Komponenten der App; importiere nicht die Palette der Marketingsseite. Lege zuerst eine kleine Menge gemeinsamer Grundelemente fest (Panel, Seitencontainerbreiten, Dialogbreiten, Segmentierte Steuerung), dann gestalte die Bildschirme mit ihnen um.
• Login/Signup mit einem gehosteten Auth-Widget (z.B. Clerk): Gestalte es über dessen Erscheinungs-API und Lokalisierung und beachte die Fallstricke in build-patterns („Auth-Seiten“).

Art Direction (Dimension und Bewegung)

Gestalte die dimensionalen und beweglichen Teile aus den eigenen Anforderungen der Site, dann entwerfe sie wie jedes andere visuelle Element. Verwende nicht das Rezept oder feste Werte einer vorherigen Site.

1. Leite es aus dem Briefing ab. Was ist die eine Idee, die ein Besucher mitnehmen muss (das Produkt in Aktion, eine Transformation, Maßstab, Präzision, Ruhe)? Wer ist die Zielgruppe, welchen Ton hat die Marke, welche Geräte und welches Performance-Budget gibt es? Das charakteristische Element sollte diese Idee zeigen, idealerweise mit dem echten Produkt.
2. Erkunde 2–3 Optionen, die zum Seitensystem und Ton passen, z.B. ein Produktfenster in Perspektive, geschichtete Tiefe mit Parallaxe, eine scrollgesteuerte Szene, die den Workflow erzählt, eine Illustration oder ein 3D-Objekt, eine Daten-/visuelle Metapher oder eine ruhige flache Seite mit reichhaltigen Mikrointeraktionen. Erstelle für jede ein Bild und, bei Bewegung, ein Storyboard; der Nutzer wählt.
3. Spezifiziere, dann baue. Schreibe für die gewählte Option auf: Was bewegt sich, was löst es aus (Laden, Scrollen, Cursor, Zeit, Klick), der Ruhezustand, die reduzierte Bewegungsversion und die mobile Version. Justiere Winkel, Zeitabläufe und Intensitäten im Browser anhand der freigegebenen Entwürfe, nicht nach Vorlage.
4. Überprüfe die Kosten. Es darf Lesbarkeit, Kontrast, Layoutstabilität oder Ladezeit nicht beeinträchtigen; es muss ohne JS und bei reduzierter Bewegung anmutig abschalten.

Reichhaltige Interaktion aus Bibliotheken

Statische Seiten wirken billig. Verwende aktiv Komponenten- und Animationsbibliotheken, um jede Interaktion lebendig wirken zu lassen:

• Jeder Zustand erhält Feedback: Hover, Drücken, Fokus, Laden/Ausführen, Erfolg/Fehler, Erscheinen/Verschwinden, Layoutänderung. Plane diese in den Interaktions-Storyboards, nicht als nachträglichen Gedanken.
• Bevorzuge eine gut gebaute fertige Komponente gegenüber einem handgeschriebenen Effekt. Ordne jede Interaktion einem Muster zu und wähle dann die Komponente aus den für dieses Projekt gewählten Bibliotheken (references/ui-references.md, „Interaktionsmuster“).
• Produkt-Demos bewegen sich: echte Aufgaben, die ablaufen, Ergebnisse, die eintreffen, Zahlen, die sich ändern, Szenenwechsel.
• Halte es zweckdienlich: Bewegung erklärt den Zustand oder lenkt den Blick auf das, was sich geändert hat. Schwere dekorative Effekte gehören auf Marketingsseiten, nicht in Arbeitsbildschirme. Beachte überall reduzierte Bewegung.

Auswahl von Bibliotheken

Wähle Komponenten- und Animationsbibliotheken für das Projekt; keine ist zwingend erforderlich.

• Bestehendes Projekt: verwende, was bereits vorhanden ist; füge eine Bibliothek nur für eine Lücke hinzu und niemals eine, die eine vorhandene überlappt.
• Neues Projekt: wähle nach Projekttyp, Framework und Anforderungen (Kriterien und Kandidaten in references/build-patterns.md, „Bibliotheken auswählen“). Behalte ein Basiskomponentensystem und eine Hauptanimationsbibliothek, es sei denn, es gibt einen klaren Grund für mehr.
• Bevorzuge Quellen, die als bearbeitbarer Quellcode ins Projekt installiert werden (Registry/CLI oder Kopie), gegenüber undurchsichtigen Paketen, damit Komponenten den Projekt-Token folgen.

Hart erkämpfte Regeln (Details in build-patterns)

• Jeder Textton muss 4,5:1 auf der darunterliegenden Oberfläche erreichen; überprüfe den blassesten Token auf der Panel-Füllung, nicht nur auf dem Seitenhintergrund.
• Keine Deckkraft-Überblendung bei Eingängen über der Falz und keine Deckkraft-Abdunkelung für „inaktive“ Zustände – Axe-Prüfungen während der Animation erkennen dies und beanstanden den Kontrast. Verwende Transformations-Eingänge und Farbänderungen.
• Animations-Wrapper dürfen nicht zwischen <ul>/<ol> und <li> sitzen; animiere innerhalb des <li>.
• Schiebende Pillen: platziere das Label in einem relative-Span über einer absoluten Pille; kein -z-10 + isolate.
• Zähler rendern den Endwert auf dem Server und animieren nur beim Sichtbarwerden.
• Auf mehrsprachigen Seiten läuft jeder sichtbare Text durch i18n, einschließlich Demo-UI in Mock-Fenstern und wiedergegebenen Sitzungen.
• Grids benötigen eine explizite Einzelspalte / minmax(0,1fr)-Spuren und der Seitenstamm benötigt horizontalen Überlauf abgeschnitten, um Mobilüberlauf zu vermeiden.