Designer MCP – Research-First Design

Was macht Designer MCP – Research-First Design?

Jedes Design vor der Umsetzung auf reale Produktbelege stützen. Dieses Skill kombiniert eine forschungszentrierte Methodik mit einer lokalen, kostenlosen Bibliothek von 1.342 extrahierten Designsystemen.

Die Forschungsbibliothek hat eine Ebene:

1. Styles – Visuelle Richtung und Geschmack, extrahiert aus echten Web-Marketing-/Produktseiten.

Screens und Flows existieren im kostenpflichtigen Refero-Produkt, sind aber nicht in dieser Bereitstellung enthalten. Bei Fragen auf Screen- oder Journey-Ebene die gebündelten Craft-Referenzen und das Material desder Nutzerin verwenden und dies klar sagen, anstatt Präzedenzfälle zu erfinden.

Nicht verhandelbar

• Recherche vor Designarbeit. Jedes Design muss vor der Umsetzung durch Referenzen belegt sein. Verlasse dich nicht auf den generischen Designgeschmack des Modells.
• Styles zuerst für visuelle Arbeit verwenden. Ist der MCP-Server nicht verfügbar, die gebündelten Craft-Referenzen nutzen und denselben referenzbasierten Workflow beibehalten.
• Nicht eine einzelne Referenz kopieren. Mehrere starke Referenzen studieren und eine neue Richtung für das Produkt desder Nutzerin synthetisieren.
• Referenzen nicht zu einer sicheren Mitte mitteln. Stehen Referenzen im Konflikt, eine dominante Richtung wählen und ihre scharfen Merkmale bewahren. Sekundäre Referenzen dürfen nur schmale Details beisteuern.
• Token-Bedeutungen nicht ändern. Wenn eine Referenz angibt, dass eine Farbe, Schriftart, Radius, Schatten, Verlauf oder Komponente für eine bestimmte Rolle vorgesehen ist, sie nur für diese Rolle verwenden oder weglassen.
• Bildrichtlinien respektieren. Hängt ein Stil von Fotografie, Illustration, Produktaufnahmen oder Grafiken ab, die Medienrolle beibehalten. Echte/generierte/Stock-Assets verwenden, wenn verfügbar; andernfalls einen bewussten Platzhalter mit Art Direction erstellen. Keine komplexen Bilder mit schwachem CSS, dekorativen Texten oder Boxen vortäuschen.
• Keine generischen Frontend-/Produktdesign-Skills als parallele Designautorität verwenden, wenn dieses Skill verfügbar ist. Dies ist die Designmethodik; generische Design-Skills neigen dazu, die Arbeit zurück zu generischem KI-Design zu ziehen.
• Forschungsergebnisse müssen spezifisch sein. Die Referenzen nennen, konkrete Entscheidungen beschreiben und erklären, was adaptiert wird.
• Kein Design aus dem Bauchgefühl. Jede wesentliche visuelle, Layout-, Inhalts- oder Interaktionsentscheidung muss auf Recherche, dem Brief desder Nutzerin oder einer Craft-Referenz zurückgehen.
• Vor der Umsetzung synthetisieren. Recherche in ein Konzept, eine Token-Richtung und ein konkretes Entscheidungsprotokoll umwandeln, bevor gezeichnet oder codiert wird.
• Ein Brief ist kein Build-Ziel. Vor der Umsetzung entweder eine nutzerbereitgestellte visuelle Quelle, ein bestehendes Produkt-/Designsystem-Ziel, ein ausgewähltes generiertes Mockup oder eine explizite referenzgesicherte Richtung festlegen, die für den direkten Build freigegeben ist.
• Bildgenerierung nur verwenden, wenn sie das Ergebnis ändert. Bildgenerierung kann langsam sein und existiert möglicherweise nicht in jeder Codierungsumgebung. Sie für visuelle Exploration, Mockups, Bilder, Illustrationen, Texturen und schwierige Assets verwenden; bei kleinen Korrekturen, offensichtlichen Produktionsänderungen oder code-nativer UI-Arbeit überspringen.
• Nach dem Erstellen visueller Arbeiten validieren. Die gerenderte Implementierung mit dem festgelegten Ziel/der Referenz vor der Übergabe vergleichen. Korrigierbare Designabweichungen beheben, anstatt die Recherche als ausreichend zu betrachten.

MCP-Setup

Dieses Skill ist auch für sich allein als forschungszentrierte Designmethodik und Craft-Referenz nützlich. Recherche ist in jedem Fall verpflichtend – die MCP-Tools für Live-Stil-Recherche verwenden, wenn verfügbar, andernfalls mit den gebündelten Craft-Referenzen und allen nutzerbereitgestellten Referenzen recherchieren.

Der lokale Server läuft in Docker:

# MCP-Server registrieren (Hermes / jeder stdio MCP-Client)
hermes mcp add designer \
  --command docker \
  --args run --rm -i -v "$HOME/.refero-cache:/cache:ro" \
         designer-mcp:latest node scripts/mcp-entry.mjs

Dann das Gateway neu starten (oder /reload-mcp), damit die Tools registriert werden.

Für eine Browser-Galerie derselben Daten – Miniaturansichten, Farbmuster, Schriftgrößen:

cd designer-mcp-docker && docker compose up -d   # http://127.0.0.1:8787

Alle Tool-Details sind in references/mcp-tools.md zu finden.

Discovery

Vor der Recherche einen kurzen Design-Brief erstellen. Nur nach fehlenden Informationen fragen, die das Ergebnis wesentlich verändern würden; andernfalls vernünftige Annahmen treffen und fortfahren.

Klären:

• was designt wird
• Plattform: Web, iOS oder beides
• Zielgruppe und technisches Niveau
• primäres Nutzer*innenziel
• gewünschtes Gefühl oder Markenrichtung
• Geschäfts-/Nutzer*inneneinwände, die es zu überwinden gilt
• Einschränkungen: bestehende Marke, Framework, Frist, Barrierefreiheit, Inhalt
• ob die Aufgabe visuelle Richtung, konkrete UI-Muster, Journey-Logik oder eine Mischung benötigt
• ob die Aufgabe direkt zu Code gehen, zuerst visuelle Optionen produzieren oder während der Implementierung generierte Assets erstellen soll

Brief-Format:

Design von [WAS] für [WEN] auf [PLATTFORM].
Ziel: [PRIMÄRES NUTZER*INNENZIEL].
Tonalität: [GEWÜNSCHTES GEFÜHL].
Haupteinwand/-risiko: [EINWAND].
Muss beachten: [HOOK ODER UNTERSCHEIDUNGSMERKMAL].
Einschränkungen: [EINSCHRÄNKUNGEN].
Recherchebedarf: [Styles/Screens/Flows].
Weg: [direkter Build / visuelle Exploration / Audit / Asset-Generierung].

Workflow-Routing

Den leichtesten Workflow wählen, der ein hochwertiges Ergebnis liefern kann.

• Direkter Build: Für kleine UI-Korrekturen, klare Produktionsänderungen, Arbeiten an bestehenden Designsystemen oder Aufgaben mit einer konkreten Quelle, die es zu treffen gilt. Richtung recherchieren und festlegen, dann codieren.
• Visuelle Exploration: Verwenden, wenn derdie Nutzerin nach Varianten, einer neuen visuellen Sprache, einem großen Redesign, einer Landingpage oder einer anderen stark frequentierten Oberfläche mit mehreren plausiblen Richtungen fragt. Standardmäßig drei referenzgesicherte Optionen anbieten und dendie Nutzerin wählen lassen; siehe references/visual-workflow.md.
• Audit: Aufgenommene Screenshots oder Stil-Referenzen als Belege vor der Kritik verwenden.
• Asset-Generierung: Generierte Bilder nur verwenden, wenn der Referenz-Lock Bitmap-Medien erfordert, die Code, Icons oder vorhandene Assets nicht originalgetreu bereitstellen können; siehe references/visual-workflow.md.

Tool-Routing

Styles zuerst für visuelle Arbeit verwenden

refero_search verwenden, wenn derdie Nutzerin darum bittet, etwas mit einer visuellen Komponente zu designen, redesignen, verbessern, polieren oder zu erstellen.

Ein Style ist eine semantische Design-Referenz, die aus einer echten Web-Marketing-/Produktseite extrahiert wurde. Es ist kein Screenshot und keine Komponentenbibliothek. Suchergebnisse liefern Vorschauen; vollständige Style-Referenzen von refero_get bieten Design-Anleitungen wie visuelle These, Tokens, Typografie, Layout/Komposition, Abschnitts-Rhythmus, Abstände, Höhe, Oberflächen, Komponenten, Bildbearbeitung, Implementierungshinweise und Do's/Don'ts-Regeln.

Abdeckung: Web-Marketing-/Produktseiten – Landingpages, Preisseiten, Produkt-Marketing-Websites, redaktionelle Marken-Websites und SaaS-Websites. In-App-Dashboards, Auth-Screens, Einstellungs-Screens und iOS-App-Screens sind als Style-Systeme nicht abgedeckt. Bei Produkt-UI-Aufgaben die visuelle Sprache aus Styles etablieren, dann die Craft-Referenzen für die Produktlogik verwenden.

Styles verwenden für:

• Look & Feel
• Markenrichtung
• Landingpages und Marketingseiten
• Typografie, Palette, Layout, Abschnittsstruktur, Abstände, Radius, Höhe, Oberflächen
• Komponentenbehandlungen und manchmal Komponenten-/Code-Beispiele
• Bild- und Produkt-Screenshot-Behandlung
• Designsystem-Inspiration
• um ein generisches Interface geschmackvoller zu gestalten

Nach dem Finden starker Styles:

• refero_get für vollständige Details verwenden
• refero_design_md verwenden, um ein portables DESIGN.md-Artefakt zu rendern
• refero_facets verwenden, um zu sehen, welche Schriftarten, Farben, Themen und Branchen der Katalog tatsächlich enthält, bevor man sich auf eine Richtung festlegt

Für Produktmuster und Journeys

Diese Bereitstellung hat keine Screens- oder Flows-Ebene. Wenn die Aufgabe konkrete UI-Muster (einen bestimmten Bildschirmtyp, einen Formularstatus, ein Preisseiten-Layout) oder Journey-Logik (Onboarding, Checkout, Kündigung) benötigt:

• die gebündelten Craft-Referenzen verwenden – sie decken Formulare, Fokus, Leerzustände, Onboarding-Muster und Conversion-Handwerk ab
• das bestehende Produkt, Screenshots oder Designsystem desder Nutzerin verwenden, wenn bereitgestellt
• explizit angeben, dass diese handwerklich und nicht referenziell begründet sind

Keine Präzedenzfälle erfinden, die nicht nachgeschlagen wurden.

Visuellen Workflow für Bilder und Qualitätssicherung verwenden

Für Bildgenerierung, visuelle Optionen, generierte Assets und visuelle Qualitätssicherung references/visual-workflow.md lesen, wenn die Aufgabe dies benötigt.

Forschungs-Workflow

1. Visuelle Richtung mit Styles recherchieren

Für jede visuelle Designaufgabe hier beginnen.

Empfohlene Schleife:

1. 3-5 verschiedene visuelle Winkel durchsuchen.
2. Eine breite ästhetische Abfrage einbeziehen.
3. Eine Domänen-/Kategorieabfrage einbeziehen.
4. Eine Abfrage zu bekannten Marken oder starken Produkten einbeziehen, wenn relevant.
5. 3-4 starke Styles mit refero_get abrufen; vollständige Styles sind groß, daher größere Recherchen auf mehrere Chargen aufteilen.
6. Vergleichen, was jeder Style beiträgt.
7. Ein primäres Fundament wählen und 1-2 spezifische Details aus anderen Styles übernehmen.
8. Die charakteristischen Merkmale der primären Referenz vor der Implementierung festlegen.

Gute Style-Abfragen und die vollständige Extraktions-Checkliste (was aus jedem Style herauszuziehen ist: These, Schriftart, Farbrollen, Abstände, Layout, Komponenten, Bilder, Medienstrategie, Do's/Don'ts-Regeln) sind in references/research-playbook.md aufgeführt.

Synthese-Regel:

• Primärer Style: Gesamtstimmung, Dichte und Struktur.
• Sekundäre Styles: spezifische übernommene Details.
• Nutzer*innenkontext: alles an das Produkt, die Zielgruppe und die Aufgabe anpassen.
• Nicht den Durchschnitt/Überschneidungen aller Referenzen verwenden. Wenn eine Referenz dunkel, eine säuerlich und eine serifenbetont ist, ist die Antwort nicht warmes Creme + gedämpftes Orange + höfliche Serife.

Das Ergebnis niemals als „Kopie von X“ präsentieren. Als neue Richtung präsentieren, die von mehreren Referenzen inspiriert ist.

Vor der Implementierung einen Referenz-Lock erstellen:

Primäre Referenz/Richtung: [eine dominante Quelle]
Beibehalten: [3-5 Merkmale, die erhalten bleiben müssen: Canvas, Schrift, Akzent, Layout, Dichte, Medien]
Nur übernehmen: [1-2 spezifische sekundäre Details]
Rollenregeln: [Bedeutung von Quell-Token/Komponenten, die erhalten bleiben müssen, z. B. nur CTA, nur Code, nur dekorativ]
Medienstrategie: [echt/generiert/Stock/code-native/Platzhalter, mit Seitenverhältnis und Art Direction]
Ablehnen: [Standards/Durchschnittswerte, die die Richtung kollabieren würden]
Token-Verpflichtungen: [Hintergrund, Schrift, Akzent, Radius, Rahmen/Schatten, Bildbehandlung, mit Rollen]

Wenn die Implementierung vom Lock abweicht, anhalten und korrigieren. Charakteristische Merkmale nicht in sicherere Farben, sicherere Schriftarten, weicheren Radius oder generische Abschnittslayouts aufweichen. Referenz-Lock ist kein Klonen; es bewahrt ausgewählte Merkmale, während Inhalte, Marke und Interaktionsdetails an das Produkt desder Nutzerin angepasst werden.

Beim Kombinieren von Styles jeder Quelle eine begrenzte Aufgabe zuweisen. Beispielsweise: Eine Quelle kann Canvas/Schrift besitzen, eine andere die Code-Fenster-Behandlung und eine dritte den primären CTA. Niemals ein Token außerhalb seiner Quell-Rolle verschieben: CTA-Farben bleiben nur für CTA, Syntaxfarben bleiben innerhalb von Code, dekorative Verläufe bleiben dekorativ, und Karten-/Button-Regeln behalten ihren spezifizierten Radius, Schatten und Zustandsverhalten.

Wenn der primäre Style bildgeführt ist, ihn nicht durch ein textbasiertes Layout ersetzen. Wenn das benötigte Bild oder Grafik nicht produziert werden kann, den Slot mit stabilen Abmessungen, Seitenverhältnis, Bildunterschrift/Alt-Text und einer kurzen Art-Direction-Notiz erhalten. Einfache Diagramme, Icons, Code-Fenster oder geometrische Primitive nur dann bauen, wenn sie zum Quell-Style passen.

Für umfangreiche visuelle Explorationen, generierte Mockups, Bitmap-Assets oder visuelle Qualitätssicherung nach dem Build references/visual-workflow.md befolgen.

2. Produktmuster ohne Screens-Ebene

Die Craft-Referenzen verwenden, wenn die Aufgabe wissen muss, was ein Interface enthalten sollte oder wie reale Produkte ein bestimmtes UI-Problem lösen.

Bedarf	Referenz
Formulardesign, Fokuszustände, Leerzustände, Tabellen, Onboarding-Muster	references/craft-details.md
CTA-Texte, Vertrauenssignale, Einwandbehandlung, Conversion-Struktur	references/copywriting.md
Komponenten-/Icon-Auswahl	references/icons.md
Schriftrollen und Hierarchieentscheidungen	references/typography.md
Farbrollen, Kontrast, Palettendisziplin	references/color.md

Daraus extrahieren:

• Layout-Struktur
• Informationshierarchie
• Komponentenauswahl
• CTA-Muster
• Inhalts-/Textmuster
• Zustände und Randfälle
• Vertrauens- oder Conversion-Taktiken
• konkrete Details, die eine Adaption wert sind

3. Journey-Logik ohne Flows-Ebene

Wenn die Aufgabe mehrere Schritte umfasst oder eine Nutzerin im Laufe der Zeit den Zustand ändert, auf Basis des Interaktionsmusters argumentieren, anstatt einen Präzedenzfall zu behaupten:

• Einstiegspunkt und Ausstiegszustand
• Anzahl der Schritte
• Entscheidungen, die derdie Nutzerin trifft
• Reibungsminderer
• erforderliche Bestätigungen
• Speicher-/Wiederherstellungszustände
• Fehlerbehandlung
• Bindungs- oder Überzeugungsmomente
• Systemantwort bei jedem Schritt

Forschungstiefe und Synthese

Die Tiefe an das Aufgabenrisiko anpassen, dann die Ergebnisse in drei Kategorien aufteilen: visuelle Richtung (aus Styles), Produktmuster (aus Craft-Referenzen und nutzereigenem Material) und Journey-Logik (aus Interaktionslogik).

Für die Tiefenleiter pro Aufgabentyp, die Ausgabeformate für jede Kategorie, die Forschungszusammenfassungsvorlage und die Entscheidungsprotokolltabelle references/research-playbook.md lesen.

Design-Handwerk

Nach der Recherche wie eine Senior-Produktdesignerin ausführen. Die gebündelten Referenzen nur dann verwenden, wenn sie relevant sind; nicht jede Datei standardmäßig laden.

• Typografie: references/typography.md
• Farbe: references/color.md
• Bewegung: references/motion.md
• Icons: references/icons.md
• Formulare, Fokus, Bilder, Berührung, Leistung, Barrierefreiheit: references/craft-details.md
• Copywriting und Überzeugung: references/copywriting.md
• Anti-AI-Slop-Checks: references/anti-ai-slop.md (Fortsetzung folgt...)

(Hinweis: Der Originaltext wurde aus Platzgründen gekürzt; weitere Referenzen können bei Bedarf übersetzt werden.)