MonoKelvin/mono-ui-prototype

Hochwertiges UI-Prototypen-Design

1. Kernziel

Alles dafür, ein ansprechendes Produktinterface zu schaffen, das gleichzeitig gut bedienbar ist.

Die Auslieferung sollte wie ein echtes Produkt eines erfahrenen Designers wirken, nicht wie ein einfacher Prototyp, der nur Vorlagen stapelt, Karten anordnet oder Farben austauscht. Der Fokus liegt auf der Gesamtausstrahlung, der visuellen Hierarchie, der Schriftdarstellung, der Komposition, den Farbbeziehungen, der Grafiksprache, den Animationen und der Detailgenauigkeit.

• Ästhetik hat Priorität, aber nicht auf Kosten der Benutzerfreundlichkeit: Visuelles und Funktion werden gemeinsam entworfen; es werden keine Funktionen geopfert, um eine trügerische Schlichtheit zu erreichen.
• Der Stil wird vom Produkt bestimmt: Zurückhaltung, Eleganz, Lebendigkeit, Avantgarde, Opulenz oder Experimentierfreude sind erlaubt – „edle Schlichtheit“ ist nicht die einzige Antwort.
• Mut zum eigenständigen Design: Warte nicht darauf, dass der Nutzer Farben, Schriften, Layouts oder Animationsparameter vorgibt. Erforsche aktiv bessere Lösungen, nachdem du die Anforderungen verstanden hast.
• Keine Vorlagenästhetik: Verwende nicht standardmäßig gängige SaaS-Layouts, festgelegte Farbschemata, einheitliche Karten und sich wiederholende Komponentenkombinationen.
• Eigenständige Herleitung: Selbst bei derselben Produktkategorie sollte sich auf Basis des Inhalts und der Positionierung ein eigener Ausdruck entwickeln; die visuelle Lösung der vorherigen Runde wird nicht mechanisch wiederverwendet.

Referenzen für Designprinzipien

Die Designentscheidungen können sich an den folgenden etablierten Prinzipien orientieren, aber kopiere nicht deren Beispiele oder übersetze sie in feste Parameter:

• Visuelle Hierarchie, Proportionen, Gleichgewicht, Kontrast, Gestaltgesetze und visueller Fokus.
• Raster, Komposition, Rhythmus, Weißraum, Einheitlichkeit und Markenidentität.
• Konsistenz, Auffindbarkeit, progressive Offenlegung, Feedback und Barrierefreiheit.
• Schriftcharakter, Schriftqualität, Leseszenarien und Schriftkombinationen.
• Kontinuität von Animationen, natürliche Beschleunigung/Verzögerung, räumliche Beziehungen und Interaktionsfeedback.

Referenzen: NNGroup Visuelle Designprinzipien · Figma UI-Designprinzipien · IBM Design Language · Apple HIG Motion

Keine Wiederverwendung vorhandener Seiten

• Neue Seiten lesen keine vorhandenen Seiten im ui/-Verzeichnis aus, machen keine Screenshots davon, analysieren sie nicht und kopieren deren HTML / CSS / JS nicht als Ausgangspunkt.
• Verwende nicht die Farben, Schriften, Layoutstrukturen, Komponentenkombinationen und Animationsparameter der vorherigen Runde wieder. Designunterschiede dürfen nicht nur durch Farb-, Text- oder Bildaustausch entstehen; die Informationsarchitektur und der visuelle Ausdruck müssen neu durchdacht werden.
• Es darf nur auf dieses Skill, skills/ui-metadata/SKILL.md, die Nutzungsanleitung von tools/ und die vom Nutzer aktuell bereitgestellten Referenzen zugegriffen werden.
• Wenn der Nutzer ausdrücklich die Änderung einer vorhandenen Seite verlangt, darf nur diese Seite gelesen werden.

2. Verstehe das Produkt, bevor du das Design festlegst

Bestimme zuerst die Produktpositionierung, die Zielgruppe, das Nutzungsszenario, die Inhaltsmerkmale und die Markenidentität, bevor du die visuelle Richtung festlegst. Betrachte die folgende Kategorisierung nicht als Vorlage, sondern nur als Denkanstöße:

Produktcharakter	Mögliche Designausdrücke
International / Englische Marke	Knappe Textinhalte, ausdrucksstarke Schriften, großzügiges Layout, Zeichenabstand und Weißraum, Fotografie und Symbole
Trend / Kreativ / Jung	Mutige Komposition, starker Schriftcharakter, ikonische Symbole, geometrische Formen, visuelle Zahlen und flexible Farbbeziehungen
Professionelles Werkzeug / Desktop-Software	Klare Informationsorganisation, hochwertige Schriften, angenehme Informationsdichte, feines Status-Feedback und zurückhaltende Farben
Technologie / KI / Datenprodukte	Moderne Schriften, Datenvisualisierung, strukturelle Grafiken, dynamisches Feedback und wiedererkennbare Tech-Visuals
Kultur / Kunst / Content-Marke	Editorisches Layout, Serifen- oder charakteristische Schriften, Fotografie, Materialität, Weißraum und stimmungsvolle Farben
Hochpreisiger Konsum / Lifestyle	Hochwertige Schriften, Produktbilder, Material und Licht/Schatten, detaillierte Haptik und zurückhaltende, aber deutliche Markenausdrücke

Verschiedene Richtungen können kombiniert werden, oder es kann eine originelle Richtung entwickelt werden, die besser zum aktuellen Produkt passt. Wende keine Stilbezeichnungen mechanisch an.

Auslieferungsbehälter

Typ	Entscheidungskriterium	Rahmen und Scrollen	Zeichenflächenbegrenzung
A Software	Backend, Werkzeug, Dashboard	Vollständige Fensteransicht; lange Listen und Texte scrollen lokal	Innerhalb des Fensters fixiert; Overlays überschreiten den Rand nicht
B Webseite	Marke, Landingpage, Content-Seite, Portfolio	Natürlicher Dokumentenfluss; gesamte Seite vertikal scrollbar	Viewport ist die Zeichenfläche; keine Randbegrenzung
C App	Mobile-first, benannte App / Handy / Mini-Programm	Handy-Proportionen als Rahmen; nur innerhalb des Rahmens scrollbar	Im Handy-Rahmen fixiert
D Komponente	Player, Lightbox, Upload-Feld etc. einzelnes Steuerelement	Natürliche Größe je nach Inhalt; intern lokal scrollbar	Im Komponenten-Rahmen fixiert

Wenn der Nutzer es vorgibt, folge seiner Anforderung; wenn nicht, leite es aus der Funktion ab. Der Behälter bestimmt nur die Darstellungsweise, nicht den visuellen Stil.

Wichtige Punkte zum Behälterdesign

A Software

• Lasse Fenster, Hintergrund und Inhalt eine vollständige Darstellungsbeziehung bilden; der Rahmen dient dem Produkt, füge keine unnötige Dekoration für Schwebe-Effekte hinzu.
• Priorisiere, dass Hauptinformationen und häufig verwendete Aktionen natürlich koexistieren können; komplexe Inhalte werden durch sinnvolle Bereichsaufteilung und lokales Scrollen bewältigt.
• Lege zuerst die Raumnutzung und das responsive Layout fest, bevor du Scrollbereiche bestimmst; kaschiere keine Layout-Probleme durch Beschneiden, Ausblenden von Scrollleisten oder skalieren des gesamten Bildschirms.
• Bei schmalen Bildschirmen priorisiere Neuordnung, Gruppierung und Anpassung der Informationsdarstellung; Kernfunktionen dürfen nicht verschwinden.
• Die Softwarebreite beträgt nicht mehr als 85 % des gesamten Fensters, die Höhe nicht mehr als 90 %; lasse rundherum Abstand und zentriere die Anzeige.

B Webseite

• Wähle je nach Inhalt eine lange Seiten-Erzählung, modulare Navigation, immersiven ersten Bildschirm oder eine andere geeignete Struktur.
• Die Seite sollte einen visuellen Rhythmus und Inhaltsebenen haben; vermeide, dass jeder Block dasselbe Layout wiederholt.
• Scrolling-getriebene Animationen können je nach Erzählbedarf hinzugefügt werden; erzwinge keine Scrolling-Effekte, nur um eine Regel zu erfüllen.

C App

• Verwende Navigation, einspaltige oder szenengerechte Layouts und leicht bedienbare Steuerelemente, die für mobile Geräte geeignet sind.
• Passe native Steuerelemente visuell an, wo nötig, aber beeinträchtige nicht die Barrierefreiheit und Bedienbarkeit.
• Touch-Bereiche, untere Navigation und Inhalts-Scrolling sollten den echten Nutzungsgewohnheiten auf Mobilgeräten entsprechen.
• Es wird empfohlen, das Design auf iPhone-Abmessungen zu basieren (keine Dynamic Island oder Frontkamera-Komponenten erstellen).

D Komponente

• Forme die Komponente je nach Verwendungszweck und Inhalt natürlich; verwende keine vollständige Software-Hülle.
• Konzentriere dich auf die Gestaltung von Zuständen wie Leer, Hover, Fokus, Laden, Abgeschlossen und Fehler; alle Zustandsänderungen sollten klar, kohärent und verständlich sein.

Die Overlay-Grenzen für die oben genannten vier Typen sind im nächsten Abschnitt einheitlich festgelegt.

Behältergrenzen: Sperre die Oberfläche in der Zeichenfläche (für Software / App / Komponente verpflichtend)

Dies ist eine harte Einschränkung, keine Stilpräferenz. Die Grenze einer Webseite ist der Browser-Viewport; Software, Apps und Komponenten haben ihre eigenen Grenzen. Außerhalb der Zeichenfläche gibt es nur die „Bühne“ (den Hintergrund). Sobald Dialoge, Drawer, Overlays oder Weichzeichner außerhalb der Zeichenfläche landen, degradiert die Oberfläche von „einer Software“ zu „einem Webseiten-Screenshot“ – das ist die häufigste Schwachstelle dieser Art von Prototypen.

Drei-Schichten-Struktur

Das Produkt selbst wird im canvas platziert; die stage dient nur der Zentrierung und dem Hintergrund. Keine Produktsemantik wird auf der stage platziert.

body > .stage          Bühne: Zentrierung + Hintergrund, trägt keine Produktinhalte
       └ .canvas      Zeichenfläche: Grenze der Produktoberfläche
          ├ Produktinhalt (Titelleiste / Hauptbereich / Seitenleiste …)
          └ .layer     Overlay-Gruppe: Dialog, Drawer, Dropdown, Toast
              ├ .scrim  Overlay: Abdunklung + Weichzeichner
              └ .dialog Dialog-Körper

Wichtige Eigenschaften (Pseudo-Code):

.canvas {
  position: relative;    /* Basis für Overlay-Positionierung */
  contain: paint;        /* Beschneidung + fixed-Nachkommen an die Zeichenfläche binden, nicht weglassbar */
  overflow: hidden;      /* Überlaufenden Inhalt abschneiden */
  isolation: isolate;    /* Stacking- und Hintergrund-Sampling innerhalb der Zeichenfläche isolieren */
  container-type: size;  /* Optional: Ermöglicht interne cqw/cqh für Größenangaben */
  width: min(1440px, 100%);
  height: min(900px, calc(100svh - 2 * var(--stage-pad))); /* Bei container-type muss explizite Breite/Höhe angegeben werden */
}

.layer  { position: absolute; inset: 0; }              /* Bezieht sich auf die Zeichenfläche, niemals fixed */
.scrim  { position: absolute; inset: 0;               /* Größe entspricht Zeichenfläche → Weichzeichnerbereich exakt = Zeichenfläche */
          background: rgb(8 10 14 / .45); backdrop-filter: blur(10px); }
.dialog { position: relative; width: min(720px, 78cqw); max-height: 82cqh;
          display: flex; flex-direction: column; }
.dialog-body { flex: 1; min-height: 0; overflow: auto; }  /* Nur den Inhaltsbereich scrollen lassen */

Warum contain: paint explizit gesetzt werden muss

Getestet (Edge, 1400×1200): Wenn nur overflow: hidden gesetzt ist, werden position: fixed-Elemente innerhalb der Zeichenfläche weiterhin relativ zum Browser-Viewport positioniert und entweichen; erst mit contain: paint (oder transform / filter / will-change: transform / contain: layout) werden fixed-Elemente an die Zeichenfläche gebunden und beschnitten. container-type: size allein wirkt nicht, es muss zusammen mit contain: paint verwendet werden. Wenn cqw/cqh nicht benötigt werden, kann container-type weggelassen werden.

Verboten

• Verwendung von position: fixed für Overlays innerhalb der Zeichenfläche – das Bezugssystem ist der Viewport, was von Natur aus über die Grenzen geht.
• Verwendung von vw / vh / dvh für die Größenangabe von Elementen innerhalb der Zeichenfläche – Viewport-Einheiten sprengen die Zeichenfläche zwangsläufig.
• Anwendung von Overlay, Weichzeichner oder Schatten auf body, .stage oder Elemente außerhalb der Zeichenfläche.
• Verwendung von transform: scale() zur Gesamtskalierung der Zeichenfläche, um sie „in den Bildschirm zu quetschen“ – Text, Weichzeichner und Schatten werden unscharf. Die korrekte Methode ist min() für die Größenangabe + interne Selbstanpassung.
• Anzeige von produktsemantischen Inhalten (Beschreibungstexte, Schaltflächen, dekorative Grafiken sind nicht erlaubt) auf der Bühne außerhalb der Zeichenfläche.

Maßvorgaben für Dialoge (für Software verpflichtend)

Standardmäßig querformat: Breite > Höhe. Software-Dialoge sollten vorzugsweise im Breitbildformat gestaltet werden.

Inhaltsmenge	Seitenverhältnis	Empfohlene Größe (relativ zur Zeichenfläche)	Beschreibung
Viel (Tabellen, Diagramme, lange Formulare, Editoren)	Breite > Höhe, 16:9 oder 4:3	Breite 60%–80% der Zeichenflächenbreite, Höhe max. 75% der Zeichenflächenhöhe	Bei viel Inhalt priorisiere 16:9, dann 4:3; nur bei nebeneinander Anordnung wird der horizontale Raum nicht verschwendet
Mittel (Einstellungsfelder, mehrfeldrige Formulare)	Breite > Höhe	Breite 480–640px, Höhe 320–420px	Querformat beibehalten, aber nicht ausfüllen
Wenig (Bestätigung, Einzelfeld, Hinweis)	Kann annähernd quadratisch sein	Breite 320–420px, Höhe 220–320px	Hochformat ist auch sinnvoll; das Seitenverhältnis nicht um jeden Preis in die Breite ziehen
Vertikale Liste (lange Liste, Baum, Selektor)	Höhe > Breite	Breite 320–400px, Höhe 60%–80% der Zeichenflächenhöhe	Hochformat ist eine erlaubte Ausnahme: Einzellisten sind von Natur aus vertikal
Arbeitsbereich (Kalender, Kanban, Vollbild-Editor)	Nahezu volle Zeichenflächengröße	16–24px Rand innerhalb der Zeichenfläche lassen	Immer noch nicht fixed, immer noch innerhalb der Zeichenfläche

Reihenfolge der Entscheidung: Zuerst fragen: „Muss der Inhalt nebeneinander angeordnet werden?“ Wenn nebeneinander angeordnet werden muss (Tabellen, Diagramme, Code, Zeitleisten) → Querformat; Einzellisten / Baumstrukturen / mehrschrittige Formulare → Hochformat.

Umsetzung: aspect-ratio für das Seitenverhältnis, max-height als Fallback, Breite mit cqw, Höhe mit cqh.

.dialog--wide   { width: min(72cqw, 860px); aspect-ratio: 16 / 9; max-height: 78cqh; }  /* Viel Inhalt */
.dialog--panel  { width: min(56cqw, 680px); aspect-ratio: 4 / 3;  max-height: 78cqh; }  /* Viel Inhalt, kompakt */
.dialog--compact{ width: min(32cqw, 380px); aspect-ratio: 5 / 4; }                        /* Wenig Inhalt */
.dialog--tall   { width: min(30cqw, 360px); height: min(72cqh, 620px); }                   /* Einzelliste vertikal */

Wenn der Inhalt zu hoch ist, wird max-height wirksam und das Seitenverhältnis kann durchbrochen werden – das ist beabsichtigt: Lieber das Seitenverhältnis leicht verändern, als den Inhalt über die Zeichenfläche hinausragen zu lassen.

Weitere Einschränkungen:

• Dialoge werden zentriert in der Zeichenfläche platziert, mit einem Rand von mindestens 24px auf allen Seiten; sie dürfen nicht am Rand kleben oder die Zeichenfläche überschreiten.
• Bei überlaufendem Inhalt sollte nur .dialog-body scrollen, Kopf- und Fußzeile bleiben fixiert.
• Abdunkelungs-Overlay mit rgb(0 0 0 / .35) bis rgb(0 0 0 / .5), Weichzeichner 8–16px; der Wirkungsbereich ist exakt die Zeichenfläche.
• Dialoge in derselben Software, die gruppiert auftreten, sollten einheitliche Größen haben (gleiche Klasse, gleiche Größe); nicht einen 16:9 und einen schmalen hohen Dialog verwenden.

3. Designprozess

Lies vor dem Start skills/ui-metadata/SKILL.md und schreibe gemäß dessen Vorgaben eine metadata.json in das Seitenverzeichnis.

0. Quellenangabe für Bildeingabe (imageToUI)

Wenn der Benutzer „ein / mehrere Bilder“ als Eingabe zur Generierung verwendet (d. h. „UI nach Bild erstellen“, „nach Bild wiederherstellen“, „AI erkennt Bild und erstellt 1:1-Kopie“), muss das Feld imageToUI in der metadata.json geschrieben werden, um die Quelle des Bildes zu erfassen, sodass die Galeriekarte auf das ursprüngliche Referenzbild zurückverfolgen und es per Klick anzeigen kann. Die Verarbeitung erfolgt je nach Eingabetyp:

• Eingabe ist eine Bild-URL (http://, https:// oder mit // beginnender Link): Schreibe den Link direkt in imageToUI, z. B. "imageToUI": "https://dribbble.com/shots/15820088-Furniture-Board-Desktop-concept". Die Galerie rendert ein Bildsymbol; ein Klick öffnet die Quelle in einem neuen Tab.

• Eingabe ist eine base64-codierte Zeichenfolge oder ein lokaler Bildpfad: Die KI muss zuerst den Benutzer nach einer von zwei Optionen fragen, darf nicht stillschweigend verarbeiten:

  1. Bereitstellung der Quelllink-Adresse des Bildes (empfohlen für Referenzbilder mit öffentlicher Quelle, z. B. Dribbble / Behance / Design-Link); oder
  2. Erlaube der KI, das Bild in das Verzeichnis ui/<slug>/assets/ zu kopieren als Quellarchiv (stark empfohlen – stellt sicher, dass die Quelle nachvollziehbar, offline betrachtbar und zusammen mit dem Prototypen veröffentlicht werden kann). Anschließend wird imageToUI als relativer Pfad geschrieben, z. B. "./assets/source-<slug>.png".

  ⚠️ Verboten, den base64-String oder den absoluten lokalen Pfad direkt in imageToUI zu schreiben: Lokale Pfade sind auf dem Galerieserver nicht erreichbar, base64 kann vom Browser nicht geöffnet werden, das Kartensymbol wird ungültig. Schreibe das Feld nicht, bevor der Benutzer sich nicht klar entschieden hat.

Wertzuweisungsregeln (die Galerie catalog.mjs wertet dies aus, siehe skills/ui-metadata/SKILL.md):

• Beginnt mit http:// / https:// / // → wird als externer Link betrachtet, Klick führt zur Weiterleitung.
• Sonstiges (./assets/..., assets/...) → wird als Ressource im Prototyp-Verzeichnis betrachtet, aufgelöst zu /prototypes/<slug>/... und das Bild in einem neuen Tab geöffnet.
• Leer / nicht geschrieben → Das Symbol wird auf der Karte nicht angezeigt.

1. Klare Designaufgabe definieren

Bestimme die Produktpositionierung, das Benutzerszenario, die Kernaufgaben, die Informationspriorität und den Schwerpunkt des ersten Bildschirms. Bereite zuerst echte Texte und sinnvolle Daten vor, bevor du die Darstellungsweise festlegst; vermeide leere Platzhalterinhalte.

2. Visuelle Richtung festlegen

Beschreibe den Charakter dieser Seite kurz und prägnant in einem Designbrief; es ist kein festes Format oder Parameterblatt erforderlich. Überlege dir zumindest Folgendes:

• Gesamteindruck und Markenpersönlichkeit.
• Wie Typografie, Komposition und Informationsebene den Inhalt ausdrücken.
• Wie Schriften Persönlichkeit und Qualität aufbauen.
• Wie Farben Atmosphäre, Wiedererkennung und Schwerpunkte schaffen.
• Wie Icons, Grafiken, Fotografie oder Datenvisualisierung zum Ausdruck beitragen.
• Ob Animation das Erlebnis verbessern kann und welche Animationssprache verwendet werden sollte.

3. Designsystem etablieren

Erstelle CSS-Variablen und wiederverwendbare Stile, die auf die aktuelle Seite zugeschnitten sind. Farben, Schriften, Schriftgrößen, Abstände, Radius, Rahmen, Schatten und Animationen sollten einer konsistenten Designlogik folgen, aber es gibt keine feste Anzahl, Werte oder Verhältnisse.

Mach das Designsystem nicht zu einer Parametertabelle, die die Kreativität einschränkt. Du kannst flexibel anpassen, aber jede Entscheidung sollte dem Gesamteffekt dienen.

4. Visuelle Design-Schwerpunkte

4.1 Typografie und Komposition

• Lass den Benutzer auf den ersten Blick erkennen, wo er zuerst hinschauen sollte, und die anderen Informationen dann natürlich verstehen.
• Nutze Schriftgröße, Schriftstärke, Schriftcharakter, Farbe, Position, Weißraum und Ausrichtung, um Hierarchien aufzubauen; verlasse dich nicht auf die Anhäufung von Karten und Rahmen.
• Erforsche je nach Inhalt Raster, Asymmetrie, Versatz, Spalten, Überlagerung, immersive, redaktionelle oder andere Kompositionen.
• Erlaube mutige Größenkontraste, spezielle Zeilenumbrüche und visuelle Spannung, aber das Gesamtbild muss harmonisch und lesbar sein.
• Die Seite sollte Abwechslung in Dichte, Gewichtung und Rhythmus haben; vermeide, dass alle Bereiche gleichmäßig stark sind.
• Setze nicht standardmäßig auf Zentrierung, Symmetrie, gleich breite Karten oder identische Blockanordnungen.
• Das visuelle Design sollte dem Benutzer helfen, den Inhalt zu verstehen und Aufgaben zu erledigen, nicht nur nach einem guten Screenshot aussehen.

4.2 Verhältnis von Funktionalität und Schlichtheit

Funktionsumfang und visuelle Ästhetik müssen gemeinsam realisiert werden. Schlichtheit bedeutet nicht, Funktionen zu streichen.

• Biete die vollständigen Funktionen, die ein Benutzer von einer Produktkategorie vernünftigerweise erwarten kann; entferne nicht eigenmächtig Funktionen, nur um die Seite leerer, einfacher oder besser für Screenshots zu machen.
• Optimiere zuerst die Informationsarchitektur, die Funktionsgruppierung, die Position der Einstiegspunkte, den Interaktionsablauf und den visuellen Ausdruck.
• Verwende progressive Offenlegung, kontextbezogene Aktionen, Schnellzugriffe, ikonische Darstellung, Menüs und Drawer, um die visuelle Belastung zu reduzieren.
• Häufig verwendete Funktionen sollten leicht zu finden und zu bedienen sein; selten verwendete Funktionen können verstaut werden, aber sie sollten nicht unnötig schwer auffindbar versteckt werden.
• Icons können Text reduzieren, müssen aber leicht verständlich sein; wichtige Aktionen sollten bei Bedarf Textbeschriftungen behalten.
• Lösche Funktionen nur, wenn der Benutzer ausdrücklich Priorität auf Minimalismus und das Entfernen von redundanten Funktionen legt, oder eine Funktion eindeutig nicht zum Produktumfang gehört; begründe die Löschung.
• Funktionseinstiegspunkte, Zustände und Feedback müssen vollständig sein; es dürfen keine Steuerelemente geben, die zwar visuell vorhanden sind, aber keine tatsächliche Reaktion zeigen.

4.3 Texte und Informationsdarstellung

• Die Oberfläche ist kein Handbuch. Wenn es kurz ausgedrückt werden kann, schreibe keine langen Erklärungen, aber opfere keine notwendigen Informationen für kürzere Texte.
• In der Oberfläche dürfen keinerlei Texte oder Grafiken erscheinen, die sich auf „Demo / Prototyp / Simulation“ beziehen: Schreibe nicht „Demomodus“, „Beispieldaten“, „Mock-Daten“, „Testkonto“, „Dies ist ein Prototyp“; zeichne keine Sprechblasen, Pfeilhinweise, Nummerierungen, lehrreiche Hervorhebungen; verwende nicht „Schematische Darstellung“, „Platzhalterbild“, „Lorem ipsum“, „Noch offen“. Jedes Wort und jedes Symbol in der Oberfläche muss ein realer Inhalt des Produkts sein.
• Behandle den Prototypen wie eine offiziell veröffentlichte Produktoberfläche: Der Text sollte wie echte Geschäftsdaten wirken, Diagramme sollten glaubwürdige numerische Beziehungen haben, leere Zustände sollten die eigene Produktanleitung enthalten, Fehlermeldungen sollten reale Situationen beschreiben, die der Benutzer tatsächlich erleben könnte. Teile, die nicht implementiert werden können (Serverschnittstellen), werden in den Auslieferungshinweisen erklärt, nicht in die Oberfläche geschrieben.
• Bei englischen Marken oder internationalen Seiten können knappe Wörter, kurze Labels, große Schriftgrößen und visuelle Symbole verwendet werden.
• Trendige, kreative Seiten können mehr Icons, Symbole, Grafiken und visuelle Zahlen verwenden; professionelle Werkzeuge priorisieren zuerst die Klarheit der Informationen.
• Chinesische Texte sollten natürlich und präzise sein; stopfe nicht unnötig Englisch oder bedeutungslose Abkürzungen hinein, nur um zu dekorieren.
• Der Text sollte konkret und informativ sein; vermeide leere Marketingfloskeln, sich wiederholende Überschriften und selbstreferenzielle Anleitungen.
• Zustände, Trends, Prozesse, Kategorisierungen und Verhältnisse können je nach Verständnisaufwand mit Icons, Diagrammen, Strukturgrafiken oder Text dargestellt werden; es ist keine bestimmte Ausdrucksform vorgeschrieben.

4.4 Schriftdesign (Schwerpunkt)

Nimm nicht die Systemstandardschrift als endgültige Lösung. Außer bei langen Fließtexten, dichten Informationen und leseintensiven Szenarien solltest du aktiv nach Schriften suchen.

• Wenn ein Gefühl von Hochwertigkeit / Design / Marke gewünscht ist, suche aktiv nach einer Präsentationsschrift oder Schriftkombination; gib dich nicht mit der Standardschrift zufrieden.
• Überschriften, Wortmarken, wichtige Zahlen, Fließtexte und Hilfsinformationen können unterschiedliche Schriftcharaktere haben, aber die Kombination muss harmonisch sein; verwende nicht zu viele verschiedene Schriften.
• Englisch: Geometrische serifenlose, humanistische serifenlose, Grotesk, Serifen, schmale / breite Schriften, Display-Schriften, Handschrift, experimentelle Schriften; wähle nach Charakter, nimm nicht standardmäßig Inter.
• Chinesisch: Moderne Grotesk (Heiti), Songti / Serifen, runde Schriften (Yuanti), handschriftliche Schriften, charakteristische Display-Schriften; Display-Schriften nur für kurze Überschriftentexte, bei langen Fließtexten priorisiere Lesbarkeit.
• Zahlen: Grundlinie, Glyphenhöhe, Breite, Ausrichtung sollten einheitlich sein; verwende keine künstlerischen Schriften mit unterschiedlichen Breiten.
• Schriftstärke, Schriftbreite, Zeichenabstand, Groß-/Kleinschreibung, Kursiv, Zeilenumbrüche können alle Designgefühl erzeugen; verlasse dich nicht nur auf den Schriftnamen.
• Standardmäßig minimale Schriftgröße 12px (Untergrenze, keine starre Regel); eingebetteter Text in kleinen Logos / Mustern kann je nach Bedarf kleiner sein. Das Layout verlässt sich auf breitenabhängigen automatischen Zeilenumbruch; keine aktiven Zeilenumbrüche.

Siehe Abschnitt 6 „Schriften“ für Schriftquellen, CDN-Referenzen und Handhabung langsamer Ladezeiten.

4.5 Farbdesign

Verwende nicht fest vorgegebene Farbsets, Farbverhältnisse oder Akzentfarben. Bestimme zuerst den Produktcharakter und erkunde dann mutig geeignete Farbbeziehungen.

In Frage kommen: edle Grautöne, Neutraltöne, entsättigte Farben, Naturtöne, Kalt-Warm-Kontraste, Markenfarben, helle Kontraste, dunkle Opulenz, monochrome Systeme usw. Farben können zurückhaltend oder lebendig sein; wichtig sind Harmonie, Hierarchie, Wiedererkennung und Stimmungsausdruck.

Vermeide es, bläuliche Grüntöne wie Nebelgrün, Jadegrün oder Nebelblau an den Anfang der Farberkundung zu setzen – die meisten KI-erstellten Oberflächen haben heutzutage diesen Look, es ist zu leicht, sich zu ähneln; behalte es als letzten Fallback.

• Farben sollten klare Rollen haben; zwischen Hintergrund, Inhalt, Text, Schwerpunkten und Zuständen sollte eine klare Beziehung bestehen.
• Die Akzentfarbe muss nicht festgelegt sein; sie sollte je nach Marke und Seiteninhalt gewählt werden.
• Farbverläufe, Transparenz, Material und Licht/Schatten können verwendet werden, aber sie müssen einen Designzweck haben; betrachte Farbverläufe, Leuchteffekte oder Glaseffekte nicht als standardmäßiges Premium-Gefühl.
• Der Farbkontrast muss die Lesbarkeit von Text und wichtigen Steuerelementen gewährleisten; opfere nicht die Lesbarkeit für die Atmosphäre.
• Verliere nicht die Schwerpunkte, Hierarchie und Lebendigkeit der Seite, indem du nach entsättigten oder edlen Grautönen strebst.

4.6 Icons, Grafiken und Bilder

• Icons, Symbole, geometrische Formen, Illustrationen, Fotografie und Datenvisualisierung können alle zu einer wichtigen visuellen Sprache werden; beschränke dich nicht auf Text und Karten.
• Wähle den Grafikstil je nach Produktcharakter; stelle sicher, dass Linien, Proportionen, Textur und Ausdrucksweise harmonieren.
• Funktionsicons sollten priorisiert leicht erkennbar sein; Marken- oder kreative Grafiken können ausdrucksstärker sein.
• Verwende keine Icon-Bibliotheken mit deutlich unterschiedlichen Stilen gemischt; verwende keine Emojis als Ersatz für offizielle Funktionsicons.
• Grafiken müssen einen Ausdruckzweck haben: Erkennung unterstützen, Beziehungen erklären, Zustände vermitteln, die Marke formen oder die visuelle Spannung erhöhen.
• Bilder sollten eine klare Komposition, Farb- und Inhaltslogik haben; vermeide wahllose Collagen oder das Füllen der Seite mit irrelevantem Material.

4.7 Detailgenauigkeit und Vollständigkeit

• Achte auf Schriftdarstellung, Zeichenabstand, Ausrichtung, Grenzen, Icon-Proportionen, Hierarchie, Interaktionszustände und Inhaltsdetails.
• Verwende Rahmen, Trennlinien, Schatten, Radius, Texturen und Transparenzeffekte nach Bedarf; dekoriere nicht um der Dekoration willen.
• Komponenten sollten sowohl konsistent sein als auch sinnvolle visuelle Unterschiede in Schlüsselbereichen aufweisen.
• Die Seite sollte nicht nur im ersten Bildschirm hochwertig sein; Scrollbereiche, Overlays, Menüs, leere Zustände und Fehlerzustände sollten ebenfalls vollständig gestaltet sein.
• Opfere nicht die Lesbarkeit, Bedienbarkeit und Reaktionsgeschwindigkeit im tatsächlichen Gebrauch, um „wie ein Design-Entwurf“ auszusehen.

4.8 Rahmen dürfen nicht abgeschnitten werden (Pflichtlektüre für beschneidende Container)

Wenn eine Komponente mit Rahmen in einen übergeordneten Container gelegt wird, der Inhalte beschneidet, muss der Innenabstand des übergeordneten Containers ≥ die maximale Rahmenbreite aller Zustände der Komponente sein. Andernfalls wird der Rahmen an einer Seite abgeschnitten, und das Fehlen der Grenze wird direkt als „Rendering-Fehler“ interpretiert.

Mechanismus

overflow: hidden beschneidet die Padding Box (Inhaltsbox + Innenabstand) des Containers:

• Der Innenabstand des Containers kann das Überlaufen von Kindelementen nach außen absorbieren → ausreichender Innenabstand lässt den Rahmen sichtbar werden.
• Aber box-shadow-Ausdehnung und outline werden außerhalb der Rahmenbox gezeichnet; der Innenabstand kann dies nicht retten.

Lösungen (nach Priorität)

1. Globales box-sizing: border-box (bevorzugt) – Beseitigt Überlauf an der Wurzel:

*, *::before, *::after { box-sizing: border-box; }

2. Übergeordneter Container lässt Rahmenreserve – padding ≥ Rahmenbreite + 1px. Getestet: Bei Rahmenbreite 4px wird der rechte Rahmen mit padding ≤ 6px abgeschnitten, mit ≥ 7px ist er vollständig; bei genau 4px Rahmenbreite wird er immer noch abgeschnitten – unbedingt Reserve lassen.

3. Verwende inset-Schatten als Rahmenersatz – Benötigt keinen Platz, wird nie abgeschnitten:

.card { border: 0; box-shadow: inset 0 0 0 1px var(--line); }

Verboten

• Externer box-shadow / outline als dauerhafter Rahmen (wird außerhalb der Rahmenbox gezeichnet und sofort abgeschnitten);
• Negative Margins, um benachbarte Rahmen zu verschmelzen (bei Beschneidung zwangsläufig abgeschnitten).

Wenn Rahmen nur bei Hover erscheinen

Häufigstes Szenario: Standardzustand normal, bei Hover fehlt plötzlich ein Stück Rahmen. Verwende einen transparenten Rahmen als Platzhalter und ändere nur die Farbe; der Wechsel erfolgt ohne Springen oder Überlauf:

.item { border: 1px solid transparent; transition: border-color .18s; }
.item:hover { border-color: var(--line); }

Überprüfe dies für jede Komponente einzeln (siehe Abschnitt 9, Selbstprüfungspunkt 13).

4.9 Native Steuerelemente einheitlich gestalten

Browser-native Steuerelemente (Scrollleisten, select-Dropdowns, input / textarea-Fokus, checkbox / radio / range-Akzentfarben, Datumsauswahl usw.) werden vom System gerendert und ihr Erscheinungsbild stimmt nicht mit dem selbst gestalteten UI überein. Sie sind die am leichtesten zu übersehende und das Gesamtbild am meisten störende Schwachstelle. Alle nativen Steuerelemente, die auf einer Seite vorkommen, müssen in die visuelle Sprache des Produkts integriert werden; das Standard-System-Erscheinungsbild darf nicht beibehalten werden.

• Scrollleisten: Verwende für WebKit die ::-webkit-scrollbar*-Reihe, für Firefox scrollbar-width / scrollbar-color, um die Farben, den Radius und den Hover-Zustand von Laufbahn und Daumen zu vereinheitlichen; nur in lokalen Scrollbereichen einsetzen, Breite zurückhaltend (ca. 8–10px), nicht global verdicken.
• Eingabefelder: Verwende für input / textarea / select appearance: none und zeichne eigene Rahmen, Radius und focus-visible-Fokus; übernimm nicht die Standard-Browser-Rahmen und innere Schatten.
• select-Dropdown: Das native option-Panel kann nicht tiefgehend angepasst werden; verwende appearance: none + selbst gezeichneten Ausklapppfeil und verwende --control-*-Variablen, um Konsistenz mit Schaltflächen und Eingabefeldern zu gewährleisten. Wenn Suche, Gruppierung oder benutzerdefinierte Hervorhebung benötigt werden, ersetze das native select durch ein selbst gezeichnetes Dropdown.
• Akzentfarbe: Verwende für checkbox / radio / range / progress accent-color: var(--brand); behalte nicht das Systemblau.
• Zusammengesetzte Eingaben: Panels für Farbe, Datum, Uhrzeit usw. können nicht angepasst werden; ersetze sie bei wichtigen Produkten durch selbst gezeichnete Alternativen oder schränke das Eingabeformat ein.

Wichtig: Integriere Innenabstand, Schriftgröße, Radius und Fokus-Zustand aller nativen Steuerelemente in Designvariablen (z. B. --control-bg / --control-border / --control-radius / --control-focus) und halte sie mit Karten und Schaltflächen in einer einheitlichen Optik; vermeide „zwei verschiedene Sprachen“.

5. Animationsdesign und -implementierung

Animation ist ein Teil des UI-Designs, nicht nur das Hinzufügen von Hover-Effekten zu Schaltflächen. Bestimme je nach Produktcharakter und Benutzeranforderungen aktiv die Rolle der Animation in der Oberfläche.

5.1 Zuerst den Animationsbedarf bestimmen

• Wenn der Benutzer explizit hervorragende Animationen, anspruchsvolle Effekte, flüssige Animationen, cool, ausgefallen, immersiv, filmisch, dynamisches visuelles Erlebnis oder ähnliches verlangt, sollte die Animation als Schwerpunkt des Designs betrachtet werden. Verwende aktiv professionelle Animationsbibliotheken wie GSAP, um komplexe Effekte zu erzielen; gib dich nicht mit einfachen CSS-Transitions zufrieden.
• Für Marken-Websites, kreative Präsentationen, Produkteinführungen, Portfolios, interaktives Storytelling und andere Seiten, die für dynamische Darstellung geeignet sind, können aktiv rhythmische Einstiege, Scrolling-basierte Erzählungen, Parallaxe, Textanimationen, Formverzerrungen, Maskierungs-Enthüllungen, geschichtete Bewegungen und nahtlose Übergänge entworfen werden.
• Für professionelle Werkzeuge, Backends und häufig bediente Oberflächen sollten Animationen helfen, Zustände zu verstehen, räumliche Beziehungen aufzubauen und Feedback zu geben; sie können elegant und flüssig sein, aber nicht die Effizienz beeinträchtigen.
• Wenn der Benutzer keine expliziten Anforderungen an komplexe Animationen hat, gestalte sie angemessen je nach Produktcharakter; füge keine bedeutungslosen Animationen hinzu, nur um technische Fähigkeiten zu zeigen.
• Vermeide, dass alle Elemente die gleiche Einblendung nach oben haben, und lasse nicht jede Komponente unabhängig agieren.

5.2 Animationsqualität

• Vermeide mechanische lineare Bewegungen: Raumverschiebungen, Skalierungen und Oberflächenübergänge verwenden in der Regel natürliche Beschleunigung, Verzögerung, asymmetrische Easing-Kurven oder Feder-Effekte. Linear sollte nur für gleichmäßige Rotation, Fortschritt, kontinuierliches Scrollen und andere Szenarien verwendet werden, in denen es tatsächlich erforderlich ist.
• Verwende qualitativ hochwertiges Easing: Wähle je nach Bewegungsdistanz, Elementmassegefühl und Szene Kurven wie ease-out, ease-in-out, power, expo, back, spring usw.; übertreibe es nicht mit übermäßiger Elastizität, um billiges, wiederholtes Hüpfen zu vermeiden.
• Füge angemessene Dämpfung hinzu: Große Panels, Overlays, Drag & Drop, Follow-Effekte, Magnetismus und räumliche Übergänge können Trägheit, Dämpfung, Rückfederung oder Federeffekte haben, um die Bewegung natürlicher zu machen.
• Bewegungen sollten eine Ursache haben: Das Ein-, Aus-, Auf-, Zusammenklappen, Wechseln, Ziehen und Zustandsänderungen sollten der Intuition des Benutzers über Raum und Objekte entsprechen.
• Choreografie mit Rhythmus: Verwende gestaffelte, überlappende, kontinuierlich ineinandergreifende und geschichtete Bewegungen, aber es sollte einen Haupt- und Nebencharakter geben; nicht alle Elemente sollten gleichzeitig und planlos bewegt werden.
• Animationen sollten auf Inhalt und Aktionen reagieren: Vermeide bedeutungslose Endlosschleifen, ständig schwebende und die Aufmerksamkeit raubende Hintergrundanimationen.
• Leistung priorisieren: Bevorzuge Eigenschaften wie transform und opacity, die für die Compositing-Pipeline geeignet sind; setze komplexe Filter, Weichzeichner und umfangreiche Echtzeiteffekte zurückhaltend ein, um Ruckeln zu vermeiden.

5.3 Bevorzugt gsap-skills und GSAP verwenden

Bevor du GSAP-Animationen erstellst, prüfe zuerst: Wenn das aktuelle System / der Agent bereits das Skill gsap-skills installiert hat, versuche, es für das Animationsdesign zu verwenden, um die neueste API und Schreibweise zu erhalten; wenn es nicht installiert ist, frage den Benutzer aktiv um Bestätigung und empfehle ihm, npx skills add https://github.com/greensock/gsap-skills auszuführen (der Benutzer entscheidet, ob er es installieren möchte), und verwende es dann für das Animationsdesign. Schreibe keine veralteten GSAP-Verwendungen aus dem Gedächtnis.

Komplexe Animationen (Einstiegs-Erzählungen, scrollgesteuerte, Timeline-Choreografie, interaktives Drag & Drop, mehrere Elemente koordiniert) sollten bevorzugt GSAP verwenden:

• Verwende Timeline, um eine Gruppe von Animationen einheitlich zu choreografieren (Labels, Überlappungen, Verschachtelungen, Callbacks); verlasse dich nicht auf eine Reihe von nicht miteinander verbundenen delays.
• Verwende ScrollTrigger für scrollgesteuerte Animationen; füge bei Bedarf Plugins für sanftes Scrollen, Buchstabe für Buchstabe, Pfade, Flip usw. hinzu.
• Einfaches Status-Feedback mit CSS-Transitions / Keyframes ist ausreichend; importiere keine Bibliothek, nur um eine zu verwenden.
• Binde über CDN ein (z. B. gsap@3), befolge die technischen Konventionen in Abschnitt 8; verwalte Animationen modular für einfaches Abspielen / Pausieren / Umkehren / Zurücksetzen / Bereinigen.

5.4 Fortlaufende Aktionen, Unterbrechung und Wiederherstellung

Interaktionsanimationen müssen die fortlaufende Bedienung durch den Benutzer berücksichtigen: Bei einer neuen Aktion nahtlos vom aktuellen visuellen Zustand aus fortsetzen, ohne zu flackern, zur Ausgangsposition zurückzuspringen oder den Animationszustand vom tatsächlichen UI-Zustand zu entkoppeln.

• Reversible Zustände (Auf-/Zuklappen, Ein-/Aus): Wiederverwende dieselbe Timeline, reverse() / play() für die natürliche Umkehrung, erstelle keine neue.
• Kontinuierlich ändernde Zielwerte (Drag & Drop, Cursor-Follow): Verwende gsap.quickTo(), damit die Bewegung immer der neuesten Eingabe folgt, ohne jedes Mal eine neue Tween-Instanz zu erstellen.
• Mehrere Sequenzen verketten: Verwende Timeline / verschachtelte Timeline / Callbacks / Zustandsmaschinen zur einheitlichen Verwaltung; erstelle keine unabhängigen Animationen, die um dieselbe Eigenschaft konkurrieren.
• Unterscheide nach Interaktionssemantik zwischen „Sequenz fortsetzen / rückwärts abspielen / zu neuem Ziel wechseln / parallel andere Eigenschaften“; hänge nicht immer alles an oder beende immer alles; überschreibe nur wirklich konfligierende Eigenschaften (GSAP verwendet overwrite: "auto", nicht beliebig kill() oder global overwrite: true).

5.5 Barrierefreiheit und Leistung

• Beachte prefers-reduced-motion: reduce; biete dem Benutzer eine Lösung mit reduzierten dynamischen Effekten an; bei reduzierten Animationen müssen Informationen und Funktionen dennoch vollständig sein.
• Verwende keine Animationen, um wichtige Inhalte zu verstecken oder die Bereitstellung von Informationen zu verzögern, die der Benutzer sofort benötigt.
• Vermeide hochfrequentes Blinken, schnelle großflächige Skalierungen und Parallax-Effekte, die Unbehagen verursachen könnten.
• Scrolling-Animationen dürfen das normale Scrollen, die Tastaturbedienung und die Touch-Bedienung nicht beeinträchtigen.
• Bereinige beim Verlassen der Seite oder beim Zerstören von Komponenten korrekt Ereignis-Listener, ScrollTrigger-Instanzen und nicht mehr benötigte Animationsinstanzen.
• Wichtige Inhalte im ersten Bildschirm dürfen nicht erst nach dem vollständigen Laden der Animationsbibliothek angezeigt werden.

Referenzen:

• GSAP Documentation
• GSAP Timeline
• GSAP Tween / overwrite
• Apple HIG Motion
• Material Motion

6. Materialien

Verwende einheitlich tools/resource-getter/get.py zum Abrufen von Materialien; bastle keine URLs von Websites von Hand zusammen und verstreue keine externen Links unklarer Herkunft in der Seite. Die vollständige Matrix der Quellen, Lizenzen und Fehlerbehebung findest du in tools/resource-getter/README.md.

Auswahlpriorität

1. Transparente Vektor-Illustrationen: unDraw / Storyset / DiceBear / Doodle Ipsum
2. Freigestellte PNGs: Pixabay (--transparent) / pngimg
3. Fotografie: Pixabay / Picsum / Unsplash / Pexels
4. Handgezeichnete SVGs (geometrisch, dekorativ, diagrammatisch)
5. KI-Bildgenerierung (letzte Wahl, Regeln siehe unten)

Standardmäßig Hotlinking, bei Langsamkeit lokal speichern. Der auto-Modus von get misst die tatsächliche TTFB: > 0,9s oder Lesezeit > 2,5s wird als langsam eingestuft; das Material muss dann in ui/<page>/assets/ heruntergeladen werden; selbst wenn es schneller geht, staple nicht zwanzig entfernte große Bilder in den ersten Bildschirm.

...