Design-Brief

Was macht Design-Brief?

Ein Coding-Agent allein entwirft aus dem Gedächtnis, und das Gedächtnis liefert den Durchschnitt von allem: das zentrierte Hero, den lila Farbverlauf, drei Karten mit je einem Icon. Echte Produkte haben bereits jeden Bildschirm gelöst, den du gleich bauen wirst, und fertige Komponenten existieren bereits, die besser sind als alles, was in einer Sitzung improvisiert wurde. Behandle also deine eigenen Design-Instinkte als durchschnittlich und hör auf zu erfinden. Die Aufgabe ist es, zu finden, zu vergleichen, auszuwählen und anzupassen.

Zwei Quellen erledigen die Arbeit, und sie haben unterschiedliche Aufgaben:

Quelle	Was sie dir gibt	Wofür du sie nutzt
Refero	Screens, Flows und Styles von echten ausgelieferten Produkten	Entscheiden, was ein Screen tun und wie er aussehen soll
21st.dev	Fertige Komponenten von Menschen erstellt und von der Community bewertet	Die tatsächliche Komponente, die in den Code kommt

Refero sagt dir, was du bauen sollst; 21st.dev reicht dir das Bauteil. Nutze beide. Eine ohne Referenz ausgewählte Komponente ist oft hübsch, aber falsch für den Screen, und eine Referenz ohne Komponente wird von Hand neu gebaut – schlecht.

Einrichtung

# Refero (ein MCP-Server). Dann /mcp ausführen und anmelden.
claude mcp add --transport http refero https://api.refero.design/mcp

# 21st.dev CLI
npx @21st-dev/cli login     # öffnet den Browser; danach lautet der Befehl `21st`
21st whoami                 # prüfen, ob du angemeldet bist

Suchen und Vorschauen sind auf 21st.dev kostenlos. Das Abrufen des Codes einer Komponente verbraucht ein tägliches Kontingent (21st usage zeigt, was übrig ist). Vergleiche also zuerst und hole nur das, was du ausgewählt hast.

Falls ein Tool fehlt oder nicht angemeldet ist, teile dem Benutzer einmal mit, welcher Befehl das Problem behebt, und arbeite mit dem funktionierenden Tool weiter. Falle nicht stillschweigend auf handgebaute UI zurück.

Arbeitsreihenfolge

1. Richtung festlegen: Farben und Schrift.
2. Das Muster für jeden Screen und Flow in Refero finden.
3. Die Komponente für jeden Abschnitt aus 21st.dev auswählen.
4. Alles an ein Token-Set anpassen.
5. Das Ergebnis an der Qualitätslatte prüfen – in der laufenden App.

Für alles, was größer als eine Komponente ist, schreibe den UI-Plan vor dem Coden auf (Vorlage am Ende). Es ist eine kleine Tabelle, und sie verhindert, dass ein Screen während des Baus improvisiert wird.

1. Richtung

• Farben und Schrift kommen von dem, was der Benutzer bereits hat: seiner DESIGN.md, seinem bestehenden Designsystem oder einer von ihm genannten Referenz. Überschreibe sie nicht.
• Falls er nichts angegeben hat, begründe die Richtung mit Refero-Styles von erstklassigen Produkten: refero_search_styles, dann refero_get_style für die zwei bis drei stärksten. Verwende nicht das Standard-Theme des Frameworks oder die Markenpalette der Plattform, auf der du baust. So würde jedes Projekt auf dieser Plattform gleich aussehen.
• Wähle einen dominanten Stil und behalte seine markanten Merkmale. Leihe dir ein oder zwei Details von den anderen aus. Das Mitteln mehrerer Referenzen ergibt die sichere Mitte, die du vermeiden wolltest.
• Unterstütze Hell- und Dunkelmodus.
• Liefere ein Design. Gib dem Benutzer nicht drei Optionen zur Auswahl, es sei denn, er bittet darum; das Auswählen ist die Arbeit, die er dir gegeben hat.
• Schreibe das Ergebnis als Tokens auf (Farbrollen, Schrift-Skala, Abstände, Radien, Schatten), bevor du eine Komponente installierst, damit jede spätere Entscheidung auf ein Token zurückgeführt werden kann.

2. Patterns von Refero

Tool	Antwortet auf	Beispielabfrage
refero_search_styles, dann refero_get_style	Wie soll es aussehen und sich anfühlen?	premium fintech website mit zurückhaltender Typografie
refero_search_screens, dann refero_get_screen	Was gehört auf diesen Screen und in welchen Zuständen?	Dashboard-Leerzustand, Datentabelle-Filter
refero_search_flows, dann refero_get_flow	Was sind die Schritte dieser Journey?	Anmelde-Onboarding, Abonnement-Kündigung

Screen- und Flow-Suchen benötigen eine platform: web oder ios.

• Suche nach dem, was buchstäblich auf dem Screen ist („Preisseite Jahres-Monats-Umschalter“), nicht nach Adjektiven. Adjektive gehören in eine Style-Suche.
• Probiere drei bis fünf Blickwinkel pro Screen aus, einschließlich eines bekannten Produkts, das es gut macht. Das erste Ergebnis ist selten das beste.
• Sieh dir auch die Zustände an, nicht nur den Happy Screen: leer, laden, Fehler, Erfolg.
• Wenn ein Screen nah dran ist, findet refero_get_similar_screens schnell Verwandte.
• Behalte zwei bis drei Referenzen pro Screen und notiere, was du von jeder nimmst: Struktur, Hierarchie, Zustände, Wortlaut. Referenzen informieren den Screen. Sie sind keine Vorlage zum Kopieren.

3. Komponenten von 21st.dev

21st.dev ist ein kuratierter Katalog fertiger Komponenten, keine KI-Generierung. Für jedes UI-Element (Header, Eingabefelder, Karten, Dropdowns, Chat, Ladezustände, Animationen) suche, vergleiche und verwende die beste.

21st search "<Komponente>" --type c --limit 10     # nur Komponenten
21st get <id>                                       # Code und Demo der ausgewählten ausgeben
21st add <author>/<slug>                            # installieren (unter der Haube shadcn)
npx shadcn@latest add "https://21st.dev/r/<author>/<slug>"   # gleiche Installation mit normalem shadcn
21st logo <marke>                                   # echte Markenlogos als SVG, kostenlos

So wählst du aus:

1. Suche nach dem Slot, nicht nach der Stimmung. „Preistabelle“, „Befehlsmenü“, „Dateiupload“, nicht „moderner sauberer Abschnitt“. Probiere zwei bis drei Formulierungen.
2. Vergleiche mehrere und nimm nie den ersten Treffer. Öffne die Vorschauen. Ein Name und eine Beschreibung sagen dir nicht, wie eine Komponente aussieht oder sich bewegt.
3. Bevorzuge die am häufigsten heruntergeladenen oder mit Lesezeichen versehenen. Die Zählungen stehen auf der Seite jeder Komponente auf 21st.dev. Beliebtheit ist ein Beleg dafür, dass eine Komponente in echten Projekten funktioniert. Sie beweist nicht die Passung – das ist der nächste Check.
4. Prüfe die Passung gegen die Refero-Referenz für diesen Screen. Sie sollte die gleiche Aufgabe mit der richtigen Dichte erfüllen und die benötigten Zustände haben (Hover, Fokus, deaktiviert, laden, leer). Prüfe, ob sie bei Telefonbreite und mit Tastatur funktioniert, und sieh dir die Abhängigkeiten an, die sie mitbringt.
5. Passe ein oder zwei Dinge an deine Tokens an: Farbe, Radius, Schrift. Wenn du feststellst, dass du die Komponente umschreiben musst, hast du die falsche ausgewählt. Geh zurück und wähle neu.
6. Halte Geschwister konsistent. Komponenten von verschiedenen Autoren müssen sich wie ein Produkt lesen, sobald sie neu eingefärbt sind.
7. Baue nur den Klebstoff von Hand, für den es keinen Kandidaten gibt, und sag es.

Melde jede Auswahl, damit der Benutzer sie austauschen kann: Abschnitt · Komponente · Autor · einzeiliges Warum.

4. Qualitätslatte

• Echte Logos, keine generischen Icons und farbigen Punkte.
• Wenig Text. Keine Textwände; lass die Schnittstelle die Arbeit machen.
• Echte UI-Patterns: Tabs, Dropdowns, Modals, Toggles, Diagramme. Nicht alles ist ein Stapel von Karten.
• Gute Lade-, Leer- und Fehlerzustände mit Fortschritt für langsame Aktionen.
• Bewegung, und Ton und Haptik, wo sie passen.
• Alles auffindbar: Jede Seite von dort erreichbar, wo die Leute bereits sind, und alles Klickbare sieht klickbar aus.
• Reibungsloses Onboarding.
• Flows bleiben innerhalb der App, anstatt Leute auf Drittanbieter-Seiten zu schicken.
• Responsiv, und mobil fühlt sich nativ an statt wie ein verkleinerter Desktop.
• Eine Beschwerde ist ein Muster. Wenn der Benutzer eine Sache beanstandet, finde und behebe ihre Geschwister in der gesamten App.

Mittelmäßigkeit ist nie eine Option.

5. In der laufenden App prüfen

Öffne die App im Browser oder Simulator und benutze sie: Hell und Dunkel, Desktop- und Telefonbreite, die Leer- und Ladezustände. Vergleiche jeden Screen mit seinen Referenzen und behebe die Abweichungen. Die Recherche ist nicht die Ziellinie; der gerenderte Screen ist es.

UI-Plan-Vorlage

**Richtung:** <die DESIGN.md des Benutzers oder Refero-Styles: Name, Name> · Hell und Dunkel
**Tokens:** <Farbrollen, Schriftarten, Radius, Abstände>

| Screen oder Flow | Refero-Referenzen | Was wir nehmen | 21st.dev-Komponente |
|---|---|---|---|
| Onboarding | <App: Screen>, <App: Flow> | Drei Schritte, Fortschrittsbalken, Überspringen | <Autor>/<Slug> |

**Von Hand gebaut (kein Kandidat):** <was, und warum>