entro314-labs/ui-declutter

UI declutter (UI entrümpeln)

Bearbeite eine Oberfläche so, dass jedes Wort und jedes Ornament auf ihr für die Person da ist, die sie nutzt. Generierte Bildschirme neigen dazu, sich selbst zu erklären: eine Beschriftung über dem Titel, ein Satz darunter, ein Hinweis neben dem Button. Jede Ergänzung wirkt harmlos, und zusammen begraben sie die drei Wörter, für die der Benutzer gekommen ist.

Das Ziel ist ein Bildschirm, der seinem Benutzer dient. Es ist kein Bildschirm, der vermeidet, generiert auszusehen. Der Unterschied ist wichtig, wenn eine Regel und das Bedürfnis des Benutzers nicht übereinstimmen: Das Bedürfnis des Benutzers gewinnt, und du sagst das im Bericht.

Ziel: die Datei, den Ordner oder die Komponente, die der Benutzer genannt hat. Wenn er keine genannt hat, verwende die Oberflächendateien, die in dieser Konversation geändert wurden. Wenn es keine gibt, frage nach.

Umfang: Text, Aktionen, Zustände, erfundene Inhalte, Dekoration und Diagramme. Die visuelle Oberfläche (Regeln X1 bis X4) wird nur bearbeitet, wenn der Benutzer darum bittet, in Worten oder mit --surface.

Schritt 1: Sage, wer an diesem Bildschirm ist

Bevor du auch nur einen String liest, schreibe eine Zeile:

Wer: ein Spieler mittendrin, der Esc gedrückt hat. Was er tut: sich entscheiden, ob er zurück ins Spiel geht, eine Einstellung ändert oder neu startet.

Diese Zeile ist der Maßstab, an dem du alles misst. Ohne sie werden die folgenden Regeln als Musterabgleich angewendet, und ein Musterabgleich streicht die Passwortanforderungen zusammen mit dem Füllmaterial. Ein Erstbesucher auf einer Preisseite braucht mehr Wörter als ein täglicher Nutzer einer Admin-Tabelle. Ein Spiel kann Fließtext haben, den ein Steuerformular nicht haben kann.

Wenn der Code dir nicht sagt, wer der Benutzer ist, leite es vom Produkt ab und gib die Ableitung an. Frage nur, wenn zwei plausible Interpretationen zu unterschiedlichen Bearbeitungen führen würden.

Schritt 2: Der Test

Für jedes sichtbare Textelement und jedes dekorative Element frage:

Ohne dies, würde diese Person zögern, einen Fehler machen oder überrascht sein von dem, was als Nächstes passiert?

• Nein → entfernen.
• Nein, aber jemand braucht es woanders → verschieben. Ein Fakt für Entwickler kommt in einen Code-Kommentar. Ein Fakt, den wenige Benutzer suchen, kommt in einen Tooltip oder die Dokumentation. Ein Name, den nur assistive Technologie braucht, kommt in aria-label.
• Ja, aber es ist schlecht formuliert → umschreiben, und zwar nur mit Fakten, die du im Code, im Inhalt oder in der Konversation finden kannst.
• Ja → behalten und in Ruhe lassen.

Die folgenden Regeln sind die üblichen Arten, wie generierte Bildschirme diesen Test nicht bestehen. Sie helfen dir, Kandidaten schnell zu finden. Wenn ein Bildschirm den Test auf eine Weise nicht besteht, die keine Regel benennt, gilt der Test trotzdem. Wenn eine Regel etwas markiert, das den Test besteht, behalte es.

Text, der einen vollständigen Satz verdient

Diese bestehen den Test fast immer. Kürze sie nicht zu einem Etikett und entferne sie nicht:

• Einschränkungen, die der Benutzer erfüllen muss: Passwortregeln, akzeptierte Dateitypen und -größen, Datums- und Zahlenformate, Zeichenbegrenzungen.
• Konsequenzen: Was eine zerstörerische oder nicht rückgängig zu machende Aktion entfernt, was eine Zahlung berechnet und wann, was eine Berechtigung gewährt, wer etwas sehen wird, sobald es geteilt wird.
• Fehler: Was schiefgelaufen ist und was als Nächstes zu tun ist.
• Leere Zustände: Was hierher gehört und wie man den ersten hinzufügt.
• Einwilligungs-, Rechts- und Regulierungstexte. Bearbeite niemals den Wortlaut. Melde es, wenn es falsch aussieht.
• Anleitungen für eine Aufgabe, die der Benutzer selten ausführt und nicht rückgängig machen kann.

Regeln

IDs sind stabil. Zitiere sie im Bericht.

Text (Copy)

• C1. Augenbrauen-Labels. Kleine Großbuchstaben oder gesperrter Text über einer Überschrift („FEATURES“, „HOW IT WORKS“, „OPERATION ON HOLD“ über „PAUSED“). Die Überschrift nennt bereits den Abschnitt, also entferne das Augenbrauen-Label. Wenn das Augenbrauen-Label die bessere Zeile ist (Fließtext in einem Spiel, ein eigener Begriff des Produkts), befördere es zur Überschrift und entferne die generische. Eines von beiden, niemals beide.
• C2. Dekorative Nummerierung. „01 02 03“, „01 // Features“, „§“ und „//“-Präfixe. Entfernen, es sei denn, die Reihenfolge ist echt und der Benutzer folgt ihr, wie bei Checkout-Schritten oder einer Installationsanleitung.
• C3. Untertitel-Reflex. Ein Satz unter jeder Überschrift, eine Beschreibung unter jedem Menüpunkt („Einstellungen: Aktualisieren Sie Ihre Einstellungen“). Behalte einen nur, wenn er einen Fakt nennt, den die Überschrift nicht nennt.
• C4. Erzählung. Hilfstexte und Bildunterschriften, die beschreiben, was das Element sichtbar ist oder tut („Klicken Sie auf den untenstehenden Button, um loszulegen“, „Diese Karte zeigt Ihre aktuellen Aktivitäten“). Entfernen.
• C5. Durchgesickerte Implementierungsdetails. Text darüber, wie der Bildschirm unter der Haube funktioniert, oder eine Anforderung aus dem Prompt, die als Text wiedergegeben wird: „Resume recaptures the mouse“, „(updates in real time)“, „(powered by AI)“, „Daten werden für 5 Minuten zwischengespeichert“. Der Benutzer handelt nicht danach. Verschiebe es in einen Code-Kommentar oder entferne es.
• C6. Status-Strings. Fakten, die mit „·“ oder „|“ verknüpft sind („12 Elemente · Aktualisiert vor 2 Min. · Synchronisiert · v2.1“). Behalte den Fakt, nach dem der Benutzer handelt. Verschiebe die anderen dorthin, wo sie gebraucht werden, oder entferne sie.
• C7. Doppelte Hinweise. Ein Label, das den Platzhalter, das Icon, den Button-Text oder die Abschnittsüberschrift wiederholt. Behalte eines. Bei Formularfeldern behalte das sichtbare Label: Ein Platzhalter verschwindet bei der Eingabe und ist kein zugänglicher Name.
• C8. Slogans. „One. Big. Thing.“, „Built different.“, „Ship faster. Think less.“ Schreibe als einen Satz um, der das Ding und seine Funktion nennt, wenn die Quelle dir diese Fakten gibt. Andernfalls markiere es für den Eigentümer.
• C9. Generische Abschnittsüberschriften. „Why choose us“, „Everything you need“, „Built for teams like yours“. Eine Überschrift, die auf der Seite jedes Produkts stehen könnte, sagt nichts über dieses hier aus. Benenne sie nach dem, was der Abschnitt enthält, oder entferne die Überschrift, wenn der Inhalt auch ohne sie auskommt.
• C10. Hinweis-Überladung. Tooltips auf Steuerelementen, die bereits ein Textlabel haben, Tastenkombinations-Chips auf jeder Aktion, „Tipp:“ und „Profi-Tipp“-Hinweise, Coach-Marks auf einem gewöhnlichen Bildschirm. Behalte einen Hinweis, wenn das Steuerelement sonst mehrdeutig ist (ein reines Icon-Button) oder die Tastenkombination die Hauptmethode zur Nutzung ist.

Aktionen

• A1. Vage Aktionslabels. „Get started“, „Learn more“, „Submit“, „Continue“, „OK“, „Click here“. Ein Button sagt, was passiert, wenn er gedrückt wird: ein Verb und ein Objekt, wenn das Verb allein mehrdeutig ist („Konto erstellen“, „CSV exportieren“, „Einladung senden“). „Weiter“ und „Nächster“ sind in einem geführten Ablauf in Ordnung.
• A2. Eine Aktion, mehrere Namen. „Löschen“ auf einem Bildschirm, „Entfernen“ auf dem nächsten und „Papierkorb“ im Menü für denselben Vorgang, oder „Anmelden“ neben „Einloggen“. Wähle die Bezeichnung, die das Projekt am häufigsten verwendet, und wende sie überall im Ziel an. Wenn zwei Bezeichnungen unterschiedliche Vorgänge benennen (aus einer Liste entfernen versus dauerhaft löschen), behalte beide.
• A3. Bestätigungsdialoge. „Sind Sie sicher?“ mit „OK“ und „Abbrechen“. Der Titel nennt die Aktion und ihr Objekt („3 Projekte löschen?“), der Haupttext gibt die Konsequenz an, falls vorhanden („Dadurch werden auch die 14 zugehörigen Aufgaben entfernt. Dies kann nicht rückgängig gemacht werden.“), und der Bestätigungsbutton wiederholt das Verb („Projekte löschen“). Eine Bestätigung für eine Aktion, die trivial rückgängig gemacht werden kann, ist selbst Unordnung: Markiere es für den Eigentümer.

Zustände

Lade-, Erfolgs-, Leer- und Fehlertexte sind Orte, an denen sich Füllmaterial sammelt, weil niemand diese Zustände ansieht, wenn er einen Bildschirm überprüft. Lies references/states.md, bevor du einen von ihnen bearbeitest: Es sagt, was jeder Zustand enthalten sollte, was mehr ist als das, was entfernt werden soll.

• S1. Lade-Füllmaterial. „Hang tight!“, „Crunching the numbers…“, „Just a moment while we get things ready“. Nenne nur, was geladen wird, wenn die Wartezeit lang genug ist, um es zu lesen. Ansonsten reicht ein Spinner oder Skelett.
• S2. Erfolgs-Füllmaterial. „Successfully saved!“, „Your changes have been saved successfully.“ Gib das Ergebnis in so wenigen Worten an, wie es trägt („Gespeichert“, „Einladung an [email protected] gesendet“). Wenn der Bildschirm das Ergebnis bereits zeigt, kein Toast.
• S3. Leerzustands-Füllmaterial. „Nothing here yet!“, „Looks like you haven't created any projects yet. Get started by creating your first project!“ Sage, was hierher gehört, und gib die eine Aktion an, die es hinzufügt.
• S4. Vage oder niedliche Fehler. „Oops! Something went wrong“, „An error occurred. Please try again later.“ Sage, was fehlgeschlagen ist und was der Benutzer tun kann. Wenn der Code nicht wissen kann, was fehlgeschlagen ist, sage das klar und gib den Wiederholungsversuch an.

Erfundene Inhalte

• F1. Erfundene Beweise. Benutzerzahlen, Betriebszeitangaben, Sternbewertungen, Testimonials mit einem Namen und einer Berufsbezeichnung, „Trusted by“-Logoreihen, „As seen in“. Wenn das Projekt keine Quelle dafür hat, handelt es sich um eine falsche Behauptung auf einer veröffentlichten Seite. Schreibe es nicht in eine kleinere falsche Behauptung um. Entferne es und liste es im Bericht auf, damit der Eigentümer die echten Daten liefern kann.
• F2. Platzhalterdaten in ausgelieferten Bildschirmen. „John Doe“, „Acme Corp“, Lorem Ipsum, example.com-Adressen, Standard-Avatar-Dienste. In Fixtures, Tests und Stories ist das in Ordnung. In einem ausgelieferten Bildschirm melde es als Aufgabe. Du kannst keine echten Daten liefern.

Dekoration

• D1. Badges ohne Status. „NEW“, „LIVE“, „AI“, „Beta“, „Pro“, „Popular“ aus Stilgründen hinzugefügt. Behalte ein Badge nur, wenn es etwas widerspiegelt, das die App verfolgt.
• D2. Status-Punkte. Pulsierende oder farbige Punkte neben Text. Behalte nur, wenn sie an einen echten Status gebunden sind, und gib ihnen einen zugänglichen Namen.
• D3. Dekorative Emojis und Icons. In Überschriften, Buttons, Labels und Listenelementen. Entfernen. Ein Icon bleibt, wenn es das Steuerelement ist (ein Icon-Button mit aria-label) oder wenn es eine Bedeutung trägt, die der Text nicht hat.

Diagramme und Dashboards

• V1. Titel, die den Diagrammtyp nennen. „Balkendiagramm des monatlichen Umsatzes“ wird zu „Monatlicher Umsatz“. Gib stattdessen die Erkenntnis an („Umsatz seit März verdoppelt“), nur wenn die vorliegenden Daten es zeigen.
• V2. Leseanleitungen. „Jeder Balken repräsentiert einen Monat“, „Für Details schweben“. Entfernen.
• V3. Doppelte Kodierung. Eine Kodierung pro Größe. Ein KPI mit einem Pfeil, einem Prozentsatz, dem Wort „↑“ und einem Satz, der alle drei wiederholt, behält die Zahl und einen Vergleich.
• V4. Gerüst, das mit den Daten konkurriert. Plot-Rahmen, dunkle oder dichte Gitterlinien, dicke Achsenränder, 3D, Schatten und Leuchteffekte auf Markierungen. Entfernen oder auf einen haarfeinen Strich reduzieren. Gleicher Diagrammtyp, gleiche Daten, gleiche Serienfarben.
• V5. Legende, wo eine direkte Beschriftung funktioniert. Bei vier oder weniger Serien und ausreichend Platz, um sie zu beschriften, benenne jede Serie an ihrem Linienende oder neben ihrem Balken und entferne die Legende.

Oberfläche (nur auf Anfrage)

Lies zuerst references/surface.md. Es beginnt mit einer Prüfung auf Designabsicht, die entscheidet, ob diese Regeln überhaupt angewendet werden: Ein Spiel, eine Marketingseite oder ein redaktionelles Layout mit bewusster Schriftgestaltung ist kein Defekt, der normalisiert werden muss.

• X1. Verläufe und Leuchteffekte. Farbverläufe auf Oberflächen und Buttons, Textverläufe, farbige Leuchteffekte, unscharfe Farbblobs.
• X2. Abstände außerhalb des Rasters. Einzelne Werte wie mt-[13px] oder gap: 7px, wo Geschwister das Raster verwenden.
• X3. Schwere Schriftgewichte in Standard-UI. 800 und 900 auf Fließtext, Labels, Tabellenzellen und Steuerelementen. Überschriften außerhalb des Bereichs.
• X4. Dekorative Bewegungen. transition-all, Karten, die beim Hover skalieren, Bounces und Loops, die nichts erklären.

Für stilistische Details auf Textebene in dem, was du behältst oder umschreibst (Groß-/Kleinschreibung, Zeichensetzung, Füllwörter, Konsistenz), lies references/writing.md. Für durchgearbeitete Vorher-Nachher-Paare, einschließlich Fälle, in denen die richtige Bearbeitung darin besteht, den Text zu behalten, lies references/examples.md, wenn du dir unsicher bist, wie weit du kürzen sollst.

Leitplanken

• Füge niemals einen Fakt hinzu. Eine Umschreibung verwendet das, was im Code, in den Inhaltsdateien, in den Daten oder in der Konversation ist. „Bearbeitungen synchronisieren sich innerhalb von Sekunden“ ist eine Produktbehauptung, und du weißt nicht, dass sie wahr ist. Wenn die ehrliche Umschreibung einen Fakt benötigt, den du nicht hast, entferne die Zeile oder liste sie als Aufgabe für den Eigentümer. Dies ist die am leichtesten zu brechende Regel, weil eine erfundene, spezifische Formulierung besser klingt als die vage Zeile, die sie ersetzt.
• Ändere nur sichtbaren Text und dekorative Elemente. Lasse Logik, Daten, Farben, Schriftarten und Layoutstruktur unberührt. Die Ausnahmen sind Diagrammgerüst unter V4 und die Oberflächenregeln auf Anfrage.
• Behalte zugängliche Namen. Lösche niemals aria-label, alt, title auf Icon-Buttons oder Screenreader-Only-Text. Wenn der sichtbare Text, den du entfernt hast, der einzige zugängliche Name war, verschiebe ihn in aria-label.
• Bearbeite Text an seiner Quelle. Strings aus i18n-Dateien, Props, Fixtures oder einem CMS werden dort bearbeitet oder gemeldet. Härte keinen Ersatz in der Komponente. Wenn du einen String in einer Locale-Datei änderst, liste die anderen Locales als Aufgaben auf; übersetze sie nicht selbst, es sei denn, du wirst darum gebeten.
• Räume nach einem Schnitt auf. Entferne den Wrapper, der jetzt leer ist, sowie den Abstand, der nur für das entfernte Element existierte.
• Lasseeinen sauberen Bildschirm in Ruhe. Wenn nichts den Test nicht besteht, ändere nichts.
• Folge dem Projekt. Wo das Projekt einen eigenen Sprachleitfaden, ein Glossar, Tokens oder ein Designsystem hat, richte dich danach und nicht nach den Standards dieses Skills.

Vorgehen

Verfolge diese Schritte:

- [ ] 1. Wer und was: eine Zeile
- [ ] 2. Zählen: python3 scripts/count_tells.py <Ziel> (füge --surface hinzu, wenn gefragt)
- [ ] 3. Ansehen: mache einen Screenshot des Bildschirms, wenn möglich
- [ ] 4. Lese jeden sichtbaren String und jedes Ornament in jedem Zustand; wende den Test an; kennzeichne Fehler mit einer Regel-ID
- [ ] 5. Bewertung: stark, leicht oder keine
- [ ] 6. Bearbeiten
- [ ] 7. Erneut zählen, erneut ansehen
- [ ] 8. Bericht

scripts/ befindet sich im Ordner dieses Skills. Führe das Skript mit seinem vollständigen Pfad aus.

Zählen. count_tells.py ist ein Regex-Durchlauf über die Quelle. Es findet Kandidaten und gibt eine Vorher-Nachher-Zahl für die Muster, die eine Codesignatur haben. Es kann C3, C4, C5, C7, A2, V3 oder alles, was von der Bedeutung abhängt, nicht sehen und markiert legitime Verwendungen. Behandle seine Ausgabe als Liste von Stellen, die du dir ansehen solltest. Eine Zahl, die nicht Null erreicht, ist in Ordnung, wenn das, was übrig bleibt, absichtlich behalten wird.

Ansehen. Die Quelle verbirgt, was der Benutzer sieht: welche Strings zusammen erscheinen, was aus Daten kommt, was eine Löschung mit dem Layout macht. Wenn du einen Browser oder ein Screenshot-Tool hast, erfasse den Bildschirm vorher und nachher. Wenn du keins hast, macht python3 scripts/screenshot.py <url-or-html-file> <out.png> es, wenn Playwright installiert ist. Überprüfe das Nachher-Bild auf verwaiste Lücken, eine Überschrift, die ihre Hierarchie verloren hat, und Steuerelemente, die sich bewegt haben. Wenn du den Bildschirm nicht rendern kannst, sage das im Bericht.

Lese jeden Zustand. Die Standardansicht ist ein Bruchteil der Oberfläche. Durchsuche das Ziel nach Lade-, Leer-, Fehler-, Erfolgs- und Deaktiviert-Zweigen, Toasts, Dialogen und Validierungsnachrichten. Alle sind Quellen für Füllmaterial und vage Formulierungen. Wenn ein entfernter Zustand im Ziel nicht definiert ist (eine leere Tabelle, die nur eine rotierende Plakette zeigt), melde ihn als fehlendes Design.

Bericht. Gib am Ende deine Ergebnisse in einem kurzen Bericht. Nenne:

• Die Anzahl der gefundenen und entfernten oder geänderten Elemente
• Die wichtigsten Regel-IDs, die angewendet wurden
• Alle Fälle, in denen der Test ergab, dass du etwas behalten hast, das eine Regel markiert hätte
• Alle offenen Aufgaben (fehlender Inhalt, nicht definierte Zustände, andere Locale-Dateien)
• Wenn du dir nicht sicher bist, ob eine Änderung die Absicht des Designs respektiert, dokumentiere den Zweifel

Der Bericht ist für den ursprünglichen Benutzer oder den nächsten Rezensenten gedacht. Schreibe ihn in der Sprache der Konversation.