designdifferently/design-differently

Design Differently (kostenlose Edition)

Du überprüfst ein Frontend, das höchstwahrscheinlich mit einem KI-Agenten erstellt wurde. Deine Aufgabe ist es, herauszufinden, was es generiert aussehen und anfühlen lässt, und es im Code zu beheben. Du änderst Präsentation, Text und Interaktion. Du änderst keine Geschäftslogik, Daten, Routing oder Backend.

Inhalt

1. Arbeitsablauf: Schritte 1 bis 6
2. Regeln: Typografie, Text, Visuelles, Bewegung und Effekte, Overlays, Tooltips, Tastatur, Komponenten, Bilder, Landingpage, Vorschläge für den Eigentümer, Trefferbereiche
3. Erkennungsmuster
4. Fallstricke
5. Bericht

Wie streng jeder Teil zu befolgen ist:

• Exakt: Erkennungsmuster, die Frage in Schritt 3, das Berichtsformat und dessen Fußzeile. Ändere sie nicht.
• Fest: die Regeln. Wende sie an, wie sie geschrieben stehen; überspringe eine Regel nur, wenn sie nicht zum Projekt passt, und erkläre warum im Bericht.
• Dein Ermessen: Auswahl der Ersatzschriftarten, Formulierung von leichten Textbearbeitungen, welche Bewegungen beibehalten werden.

Kopiere diese Checkliste in deine Antwort und hake sie ab, während du fortschreitest:

- [ ] 1. Projekt kartieren
- [ ] 2. Scannen und "Vorher" erfassen
- [ ] 3. Korrekturen auflisten und den Benutzer wählen lassen
- [ ] 4. Die ausgewählten Punkte beheben
- [ ] 5. Überprüfen und "Nachher" erfassen
- [ ] 6. Regeln im Repository verankern und Bericht erstatten

---

1. Projekt kartieren

Bevor du etwas anfasst, finde heraus:

• Framework und Styling-Ansatz (Tailwind, CSS Modules, styled-components, reines CSS, ein UI-Kit wie shadcn oder MUI).
• Wo die Design-Token leben (CSS-Variablen, Tailwind-Konfiguration, Theme-Datei). Wenn es keine gibt, notiere es.
• Wo die gemeinsamen Komponenten leben (Button, Dialog, Tooltip, Dropdown, Badge, Banner). Liste Duplikate auf, die dir auffallen.
• Ob das Projekt eine App (Tools, Dashboards, Editoren) oder eine Site (Landingpage, Marketing, Blog) ist. Einige Regeln gelten nur für eine davon.
• Wie man es ausführt und wie man seine Überprüfungen (Lint, Typecheck, Tests, Build) ausführt.
• Ob du hier Screenshots machen kannst (Playwright, ein Browser-Tool, ein Vorschaufenster) und ob du Bilder in diesem Chat zeigen kannst.

Verwende, was das Projekt bereits hat, und passe dich an dessen Codestil an. Füge in dieser Edition keine Bibliotheken hinzu, außer Schriftdateien.

2. Scannen und "Vorher" erfassen

Führe die Suchen aus den Erkennungsmustern aus und lese die Hauptbildschirme. Wenn deine Umgebung keine Shell-Befehle ausführen kann (gehostete Builder wie Lovable, v0, Bolt), öffne die Dateien und suche nach denselben Mustern durch Lesen. Notiere für jeden Treffer Datei, Zeile und welche Regel er verletzt. Ein Treffer ist ein Kandidat, kein Urteil: Lies den Kontext, bevor du ihn zählst.

Wenn du Screenshots machen kannst, erfasse jetzt, vor jeder Änderung, die Hauptbildschirme: Home oder Landingpage, den geschäftigsten App-Bildschirm, einen Dialog, ein Formular. Verwende 1440×900 und 375×812. Speichere sie in .design-differently/before/ mit Namen wie home-1440.png. Notiere die genaue Route und den Zustand von jedem, damit du sie später wiederholen kannst. Committe diesen Ordner nicht.

3. Korrekturen auflisten und den Benutzer wählen lassen

Ändere keine Datei, bevor dieser Schritt beantwortet ist.

Zeige die Ergebnisse als eine nummerierte Liste, gruppiert unter Bereichsüberschriften (Typografie, Text, Visuelles, Bewegung, Overlays, Tooltips, Tastatur, Komponenten, Bilder, Landingpage). Die Nummern laufen kontinuierlich über die Gruppen hinweg. Eine Zeile pro Punkt: Was ist falsch, wo und was wirst du ändern. Lasse Bereiche ohne Ergebnisse weg.

### Typografie
1. Inter wird als einzige Schriftart verwendet (app/layout.tsx). Ersetze durch eine weniger verbreitete serifenlose Schrift.
### Text
2. 14 Gedankenstriche im Landingtext (components/Hero.tsx, Features.tsx). Ersetze durch Punkte, Kommas oder Doppelpunkte.
3. Trennlinie "Schnell · Privat · Open Source" im Hero (components/Hero.tsx). Verwandle in eine FUD-Zeile mit Symbolen.
4. Optionsbeschreibungen wiederholen ihre Bezeichnungen in den Einstellungen (settings/page.tsx). Entfernen.

Beende die Liste mit genau dieser Frage:

Antworte "alle", um alle Korrekturen anzuwenden, oder liste die Nummern, die du möchtest (z.B. 1, 3, 5-9).

Dann stoppe und warte auf die Antwort.

4. Die ausgewählten Punkte beheben

Wende nur die Punkte an, die der Benutzer ausgewählt hat, einen Bereich nach dem anderen, in dieser Reihenfolge: Komponenten, Overlays, Typografie, Visuelles, Bewegung, Tooltips, Tastatur, Bilder, Text, Landingpage.

Ändere zuerst gemeinsame Komponenten und Token, damit eine Korrektur jeden Bildschirm repariert, der sie verwendet.

Nach jedem Bereich führe die Projekt-Checks aus (Lint, Typecheck, Tests, Build). Wenn ein Check fehlschlägt, behebe ihn, bevor du zum nächsten Bereich übergehst. Wenn die Korrektur Backend- oder Logikänderungen erfordern würde, mache diesen Punkt rückgängig und markiere ihn als übersprungen.

5. Überprüfen und "Nachher" erfassen

Dein erster Durchlauf ist ein Entwurf. Überprüfe ihn anhand externer Beweise, nicht anhand deiner Erinnerung daran, was du geändert hast:

• Wenn du Screenshots machen kannst, wiederhole jeden "Vorher"-Screenshot mit derselben Route, demselben Zustand und derselben Größe und speichere ihn in .design-differently/after/ unter demselben Namen. Mache auch Screenshots von jedem anderen Bildschirm, den du berührt hast. Sieh dir jeden an. Wenn etwas abgeschnitten, überlappend, unleserlich oder springend ist, gehe für diesen Bereich zurück zu Schritt 4.
• Führe die Erkennungsmuster erneut aus. Wenn ein Muster außerhalb einer zulässigen Ausnahme immer noch zutrifft, gehe zurück zu Schritt 4.
• Lesen jeden von dir bearbeiteten String erneut anhand der Textregeln. Wenn einer immer noch eine Regel verletzt oder wenn du mehr geändert hast, als die Regel erforderte, gehe zurück zu Schritt 4.

6. Regeln im Repository verankern und Bericht erstatten

Die Korrekturen müssen zukünftiges Vibecoding überleben. Jeder Agent, der später dieses Projekt bearbeitet, muss die Regeln sehen, bevor er Code schreibt, sonst bringt er die Artefakte zurück.

1. Erstelle DESIGN_RULES.md im Projektstammverzeichnis. Schreibe es für einen KI-Agenten, kurz und im Imperativ, unter 150 Zeilen. Füge nur das ein, was für dieses Projekt gilt:
   • Die ausgewählten Schriftarten, ihre Dateien und wo sie deklariert sind, und den Logo-Schriftartpfad (A oder B), falls zutreffend.
   • Wo Token leben und die Regel, dass Farben, Radien, Abstände, Schatten und Schriftgrößen nur von ihnen kommen. Die primären, sekundären und optionalen Akzentfarben nach Token-Namen und die Regel, dass destruktive und Erfolgsfarben nur für diese Zustände sind.
   • Wo die gemeinsamen Komponenten leben (Button, Dialog, Tooltip, Dropdown, Badge, Banner) und die Regel, sie wiederzuverwenden, niemals zu duplizieren.
   • Jede Regel aus dieser Fähigkeit, die du angewendet hast, als eine Zeile, mit dem konkreten Detail aus diesem Projekt (z.B. "Tooltips: verwende components/ui/Tooltip.tsx, 2 oder 3 Wörter plus Tastenkombination").
   • Die Verbotsliste: Schriftarten, Emojis, Gedankenstriche, dekorative Trennzeichen, Anführungszeichen für Betonung, Glas auf großen Flächen, standardmäßiges Ein- und Unschärfeeinblenden, getönte Icon-Boxen, Akzentbalken-Callouts, mit Abstand geschriebene Großbuchstaben-Eyebrows, Live-Statuspunkte, Browser-Standard-Steuerelemente und Scrollleisten.
   • Eine letzte Zeile: "Bevor du eine UI-Änderung abschließt, überprüfe sie anhand dieser Datei."
2. Verweise jede Agenten-Anweisungsdatei im Projekt darauf. Füge eine Zeile, Befolge DESIGN_RULES.md für jede UI-, Text- oder Styling-Änderung., zu jeder dieser vorhandenen Dateien hinzu: CLAUDE.md, AGENTS.md, .cursorrules, .cursor/rules/*.mdc, .windsurfrules, .github/copilot-instructions.md, replit.md. Wenn keine existiert, erstelle AGENTS.md und CLAUDE.md mit dieser Zeile. Ändere nichts anderes in diesen Dateien.
3. Wenn DESIGN_RULES.md bereits von einem früheren Durchlauf existiert, aktualisiere es, anstatt ein neues zu erstellen. Behalte Regeln bei, die der Benutzer von Hand hinzugefügt hat.

Poste dann den Bericht aus Bericht als deine letzte Chat-Nachricht.

Wenn der Benutzer eine deiner Korrekturen während der Sitzung korrigiert, füge eine Zeile zu Fallstricke in dieser Datei hinzu, die die Korrektur beschreibt, damit der nächste Durchlauf sie nicht wiederholt.

---

Regeln

Typografie

KI-Tools greifen auf dieselbe Handvoll Schriftarten zurück, daher lassen diese Schriftarten allein ein Projekt als generiert erscheinen. Verwende keine Schriftart aus dieser Liste, in keiner Rolle, es sei denn, sie ist Teil einer Markenrichtlinie, die der Benutzer dir gegeben hat, oder die folgenden Logo-Schriftartregeln gelten:

Rolle	Verbotene Schriftarten
Serifenlos	Inter, Inter Tight, Geist, Roboto, Open Sans, Poppins, Montserrat, Lato, Manrope, DM Sans, Plus Jakarta Sans, Outfit, Figtree, Urbanist, Sora, Lexend, Nunito, Nunito Sans, Raleway, Work Sans, Rubik, Onest, Space Grotesk, Satoshi, General Sans, Cal Sans, Bricolage Grotesque, Syne, IBM Plex Sans, Source Sans 3, Arial, Helvetica als gewählte Schriftart
Serif	Playfair Display, Instrument Serif, Fraunces, DM Serif Display, Lora, Merriweather, Cormorant Garamond, EB Garamond, Libre Baskerville
Mono	JetBrains Mono, Geist Mono, Fira Code, Fira Mono, Space Mono, Roboto Mono, IBM Plex Mono, Source Code Pro, Ubuntu Mono
Standard	Ein bloßes system-ui oder Tailwind-Standardstapel, der verwendet wird, weil nichts ausgewählt wurde

Primäre Schriftart. Die primäre Schriftart ist die Schriftart, die im Logo festgelegt ist, oder eine Schriftart, die der Benutzer definiert hat. Das restliche Schriftsystem leitet sich daraus ab.

Logo-Schriftart. Wenn das Logo in einer Schriftart gesetzt ist (ein Textlogo, eine Wortmarkenkomponente oder eine Schriftart, die im CSS oder SVG des Logos genannt ist), bleibt diese Schriftart im Logo, auch wenn sie auf der Verbotsliste steht. Wähle dann einen von zwei Pfaden und sage im Bericht, welchen:

• A. Dem Logo folgen. Die Logo-Schriftart wird zur primären Schriftart für die Site und du musst genau diese Schriftart verwenden.
  • Logo in einer Serifenschrift: Verwende genau dieselbe Serifenschrift für Überschriften. Der Fließtext ist eine serifenlose Schrift.
  • Logo in einer serifenlosen Schrift: Überschriften dürfen eine Serifenschrift nur verwenden, wenn der Markencharakter eindeutig dazu passt, was eine riskante Wahl ist. Ansonsten bleiben Überschriften serifenlos, idealerweise genau die Logo-Schriftart oder eine, die ihr sehr nahe kommt.
• B. Nur Logo. Die Logo-Schriftart bleibt allein im Logo und du wählst die Schriftarten für den Rest aus. Die Logo-Schriftart zählt dennoch zum untenstehenden Schriftartenlimit.

Die Logo-Schriftartregeln gelten nur für ein Logo, das absichtlich gestaltet wurde. Wenn das Logo codegeneriert ist (siehe Vorschläge für den Eigentümer), ist sein Text nur die Standardschriftart, gib ihm daher deine neue Überschriftenschriftart und füge das Logo zum Abschnitt "Für dich" hinzu.

Paarungsregeln.

• Ein oder zwei Schriftarten auf der gesamten Site, inklusive Logo. Niemals mehr.
• Niemals zwei Serifenschriften.
• Primäre Schriftart ist eine Serifenschrift: Jede Serifenschrift auf der Site ist dieselbe Serifenschrift, und der Fließtext ist eine serifenlose Schrift. Maximal zwei Schriftarten.
• Primäre Schriftart ist eine serifenlose Schrift: Jeder Text auf der Site verwendet dieselbe serifenlose Schrift. Du darfst eine zweite serifenlose Schrift nur als Unterscheidung für einige Überschriften hinzufügen.
• Codeblöcke, falls das Produkt sie hat, verwenden den System-Monospace-Stapel (ui-monospace, SFMono-Regular, Menlo, monospace), der nicht als gewählte Schriftart zählt.

Schriftarten auswählen. Wenn es keine Logo-Schriftart und keine Schriftart vom Benutzer gibt, wähle die primäre Schriftart selbst und wende die Paarungsregeln an:

• Lies zuerst das Produkt: Was es tut, wer es verwendet, welchen Ton der Text hat. Wähle eine Schriftart, deren Charakter dazu passt, und schreibe einen Satz im Bericht, warum.
• Vermeide die offensichtliche zweite Wahl. Wenn eine Schriftart die erste ist, die dir für diese Art von Produkt einfällt, ist sie wahrscheinlich auf dem Weg zur Verbotsliste. Wähle eine weniger verbreitete Schriftart mit derselben Aufgabe.
• Die Lizenz muss die kostenlose kommerzielle Nutzung im Web erlauben (SIL Open Font License oder ähnlich). Quellen: Google Fonts jenseits der Top-Ergebnisse, Fontshare, Velvetyne, Collletttivo, The League of Moveable Type, Foundry-kostenlose Familien.

Für jede Schriftart auf der Site:

• Maximal drei Gewichte pro Familie.
• Schriftarten leben im Repository. Lade die woff2-Dateien in das Projekt herunter (z.B. public/fonts/) und lade sie mit @font-face, next/font/local oder @fontsource/*-Paketen, die zur Build-Zeit gebündelt werden. Lade Schriftarten niemals zur Laufzeit von Google Fonts, Adobe Fonts, Bunny oder einem anderen externen Host, da jeder Seitenaufruf dann Besucherdaten an diesen Host sendet. Entferne jeden fonts.googleapis.com-, fonts.gstatic.com-, use.typekit.net-Link, @import und next/font/google-Import, auch für Schriftarten, die du behältst. Verwende font-display: swap.
• Behalte einen sinnvollen Fallback-Stapel nach der gewählten Schriftart.
• Setze die Schriftarten an einer Stelle (Token, Tailwind fontFamily, root CSS) und entferne jede andere Schriftartdeklaration.

Text

Bearbeite Texte mit leichter Hand. Schreibe Texte nicht um, ändere nicht ihre Bedeutung, ihren Ton oder ihre Länge und füge keine neuen Sätze hinzu. Entferne die unten aufgeführten KI-Markierungen und glätte die Syntax nur dort, wo die Entfernung sie kaputt macht. Wenn ein Satz nach Entfernung der Markierung immer noch gut lesbar ist, höre dort auf.

Was zu entfernen ist:

• Gedankenstriche und mit Leerzeichen gesetzte Bindestriche (—, –). Ersetze durch einen Punkt, ein Komma oder einen Doppelpunkt, je nachdem, was den Satz am nächsten am Original hält.
• Anführungszeichen, die zur Betonung, Ironie oder Paraphrasierung verwendet werden. Entferne sie und behalte die Wörter. Anführungszeichen bleiben nur um ein exaktes, wortwörtliches Zitat.
• Dekorative Trennzeichen wie ·, •, | oder /, die verwendet werden, um Phrasen aneinanderzureihen. Entferne sie vollständig. Ersetze sie niemals durch Punkte oder andere Satzzeichen. Was mit den Phrasen passiert, hängt davon ab, wo sie sind:
  • Hero, Preiskarten, wichtige Verkaufszeilen: Verwandle die Phrasen in eine FUD-Zeile, eine horizontale Zeile mit kurzen Elementen, jedes mit einem kleinen Symbol vor seiner Bezeichnung. Verwende das Symbolset des Projekts oder Inline-SVG, wenn es keines hat. Eine Größe und eine durchgehende Farbe für alle Symbole, kein Hintergrundfeld dahinter (siehe Visuelle Regeln). Die Zeile bricht auf Mobilgeräten sauber um.
  • Sekundäre Absätze, Hilfstexte, Bildunterschriften, Fußzeilen: Lösche die Trennzeichen. Behalte die Phrasen nur, wenn sie auch ohne sie noch wie normaler Text lesbar sind; behalte ansonsten die wichtigste Phrase und verwerfe den Rest.
• "Nicht nur X, sondern Y"-Konstruktionen und ihre Verwandten: "Es ist nicht X, es ist Y", "Mehr als X", "X, ohne das Y". Behalte die positive Hälfte.
• Beschreibungen, die die Bezeichnung wiederholen, und Beschreibungen unter Optionen, die keine brauchen. Entferne sie.
• Verkaufs- oder suggestive Beschreibungen auf funktionalen UI-Elementen. Mache sie kurz und neutral, wie in macOS oder Photoshop: Sage, was es ist oder tut.

Beispiele:

Vorher	Nachher
Entwickelt für Teams — nicht nur für Einzelpersonen.	Entwickelt für Teams.
Hero: Schnell · Privat · Open Source	FUD-Zeile mit drei Elementen: Blitz-Symbol + Schnell, Schloss-Symbol + Privat, Code-Symbol + Open Source. SVG-Symbole aus dem Projekt-Set, niemals Emojis
Hilfstext: Täglich aktualisiert · 2 Minuten Lesezeit	Täglich aktualisiert
Dein "zweites Gehirn" für Notizen	Dein zweites Gehirn für Notizen
Es ist keine To-do-App, es ist ein System.	Ein System für deine Aufgaben.
Dunkelmodus — Wechsle zu einem dunkleren Thema, das nachts angenehmer für die Augen ist.	Dunkelmodus ohne Beschreibung
Auto-Speichern: Nie wieder Arbeit verlieren mit nahtlosem automatischem Speichern!	Auto-Speichern: Speichert Änderungen während der Eingabe.

...