s0xDk/refactoring-ui-skill

Refactoring UI

Visuelles Design ist kein Talent. Es besteht aus einer kleinen Anzahl systemischer Entscheidungen, die einmal getroffen werden, plus einigen Techniken zur Schaffung von Hierarchie. Diese Fähigkeit umfasst genau diese Systeme und Techniken.

Der Hauptgrund für amateurhaft wirkende UIs ist das ad-hoc-Festlegen von Werten – 17px hier, #3B82F6 dort, lighten(5%) für einen Hover-Zustand. Designe immer mit einer Skala.

---

Die Systeme – verwende sie, leite sie nicht neu ab

Wähle aus diesen Listen. Erfinde niemals einen Wert, der nicht in einer Liste vorkommt.

Abstand und Größe

Basis 16px, aufgebaut aus Faktoren und Vielfachen davon:

4  8  12  16  24  32  48  64  96  128  192  256  384  512  640  768

Am unteren Ende eng, am oberen Ende weit auseinander. Keine zwei benachbarten Werte dürfen näher als ~25% beieinander liegen – das macht die Entscheidung offensichtlich. Eine lineare „Vielfache von 4“-Skala versagt: Sie hilft dir nicht bei der Wahl zwischen 120px und 124px.

Verwende sie für Ränder, Padding, Breite, Höhe, Icon-Größen, Rahmenbreite – alles Räumliche. Lege auch einen kleinen Satz von Deckkraftwerten fest (z. B. .05 .1 .2 .4 .6 .8) für deaktivierte Zustände, Overlays und Hover-Tönungen, anstatt jedes Mal einen Regler nach Augenmaß einzustellen. Gleiche Logik wie bei den anderen Skalen: einmal entscheiden, überall wiederverwenden.

Schriftgrößen-Skala

12  14  16  18  20  24  30  36  48  60  72

Keine modulare Skala, die auf einem Verhältnis basiert (4:5, 2:3, Goldener Schnitt). Diese erzeugen gebrochene Pixelwerte, die in verschiedenen Browsern inkonsistent gerundet werden und für die Dichte von Benutzeroberflächen zu grob sind – stattdessen gewinnen handverlesene Werte, die nach ihrem Gefühl ausgewählt wurden.

Einheiten: nur px oder rem. Niemals em. em ist relativ zur aktuellen Schriftgröße, daher ergibt .875em innerhalb eines 1.25em-Elterns 17,5px – ein Wert, der nicht in deiner Skala vorkommt. Die Skala hört stillschweigend auf zu existieren.

Schriftstärke

Zwei Stärken reichen aus:

• 400 oder 500 – Fließtext und der meiste UI-Text
• 600 oder 700 – alles Hervorgehobene

Nichts unter 400 in der UI. Zum Abschwächen verwende eine hellere Farbe oder eine kleinere Größe – niemals eine geringere Schriftstärke.

Farbe

Du brauchst weit mehr Farben, als dir ein Fünf-Farbfelder-Palettengenerator gibt.

• Grautöne: 8–10 Abstufungen. Fast eine gesamte UI ist grau – Text, Hintergründe, Panels, Ränder, Formularsteuerelemente. Drei oder vier Abstufungen reichen immer nicht aus. Beginne mit einem sehr dunklen Grau, nicht mit echtem Schwarz (echtes Schwarz wirkt unnatürlich).
• Primär: 5–10 Abstufungen, eine oder vielleicht zwei Primärfarben.
• Akzente: 5–10 Abstufungen – destruktives Rot, Warn-Gelb, positives Grün, plus alles, was das Produkt zur Unterscheidung benötigt (Diagrammreihen, Kalenderereignisse, Tags). Zehn Farben × 5–10 Abstufungen ist für eine komplexe UI normal.

Benenne sie 100 (hellste) → 900 (dunkelste), Basis 500.

Erstelle die Skala in dieser Reihenfolge: Wähle zuerst 500 aus (für eine Primärfarbe/ einen Akzent sollte es ein Farbton sein, der als Button-Hintergrund funktioniert). Finde dann die Ränder – 900 ist normalerweise deine Textfarbe, 100 eine Hintergrundtönung; eine Alarm-Komponente verwendet beide, also entwirf eine und lies die beiden Werte daraus ab. Fülle dann 700 und 300 als perfekten Kompromiss zwischen ihren Nachbarn, dann auf die gleiche Weise 800 600 400 200.

Schreibe Farben als HSL, nicht als Hex. hsl(220, 95%, 34%) und hsl(220, 65%, 61%) sind sichtbar verwandt; #03369E und #507DD7 nicht.

Generiere Farbstufen niemals zur Laufzeit mit lighten() / darken(). So endet man mit 35 leicht unterschiedlichen Blautönen.

Schatten – fünf Ebenen

0 1px 3px  hsla(0,0%,0%,.2)   /* kaum hervorgehoben – Buttons */
0 4px 6px  hsla(0,0%,0%,.2)   /* Dropdowns */
0 5px 15px hsla(0,0%,0%,.2)
0 10px 24px hsla(0,0%,0%,.2)
0 15px 35px hsla(0,0%,0%,.2)  /* Modals */

Wähle aus, indem du fragst wo auf der Z-Achse befindet sich das?, nicht welcher Schatten sieht gut aus?. Näher am Benutzer = mehr Aufmerksamkeit. Das Verkleinern des Schattens einer Schaltfläche bei :active gibt das Gefühl, sie sei gedrückt; das Vergrößern des Schattens eines Listenelements, wenn es zum Ziehen und Neuanordnen aufgenommen wird, bewirkt das Gegenteil – es wird als „jetzt über den Geschwistern“ gelesen und fungiert gleichzeitig als Drag-Hinweis.

Diese fünf sind die Standardeinstellung und überall in Ordnung. references/techniques.md enthält eine verfeinerte zweiteilige Version derselben Skala – parallel, aber nicht identische Werte (ihre oberste Stufe ist schwerer). Verwende sie, wenn Schatten im Design dominant sind; verwende diese, wenn sie es nicht sind. Mische die beiden nicht in einem Projekt.

Zeilenhöhe und Zeilenlänge

Die Zeilenhöhe ist umgekehrt proportional zur Schriftgröße und proportional zur Zeilenbreite:

• kleiner Text / breite Spalten → 1.5 bis 2
• große Überschriften → 1 ist in Ordnung

Zeilenlänge: 45–75 Zeichen, d. h. max-width: 20em–35em. Dies gilt für den Absatz, selbst wenn der umgebende Container breiter ist – gemischte Breiten in einem Inhaltsbereich sehen polierter aus, nicht weniger.

(em ist hier korrekt – das Maß sollte mit dem umschlossenen Text skaliert werden. Die „niemals em“-Regel gilt für die Schriftgrößen-Skala, wo em durch Verschachtelung aufgezinst wird. „Repariere“ das nicht.)

Rahmenradius

Wähle einen aus und bleibe konsistent. Kleiner Radius = neutral. Großer Radius = verspielt. Keiner = ernst/formell. Das Mischen von eckigen und abgerundeten Ecken in einer Benutzeroberfläche sieht immer schlechter aus.

---

Das Vorgehen

1. Beginne mit einer Funktion, nicht mit einem Layout. Gestalte nicht „die App“ – du kannst nicht zwischen Top-Navigation und Sidebar entscheiden, bevor du weißt, was im Produkt ist. Gestalte eine reale Funktionalität (das Suchformular, den Nachrichten-Editor) und lass die Hülle daraus entstehen.

2. Details kommen später. Ignoriere Schriftarten, Schatten und Icons frühzeitig. Arbeite zuerst in Graustufen – das erzwingt, dass Hierarchie aus Abstand, Kontrast und Größe und nicht aus Farbe entsteht. Füge Farbe hinzu, sobald das Layout funktioniert.

3. Investiere nicht zu viel in niedrige Wiedergabetreue. Skizzen, Wireframes und Mockups sind Wegwerfmaterial – niemand kann ein statisches Bild einer App nutzen. Sie dienen der Ideenfindung; verwerfe sie, sobald die Entscheidung gefallen ist, und baue das Echte.

4. Gestalte die kleinste nützliche Version und baue sie dann. Arbeite in kurzen Design→Code-Zyklen. Impliziere keine Funktionalität, die du noch nicht umsetzen kannst – ein Kommentarfeld mit einem Anhängebereich, den du noch nicht ausliefern kannst, blockiert die gesamte Funktion. Nice-to-haves werden später designt.

5. Wähle durch Ausschluss. Wenn du einen Wert aus einer Skala auswählst: rate den, der deiner Meinung nach richtig ist, und vergleiche ihn dann mit den beiden Nachbarn. Zwei werden offensichtlich falsch sein. Wenn eine äußere Option gewinnt, wiederhole den Vergleich mit diesem als neuem Mittelpunkt.

6. Beginne mit zu viel Weißraum und entferne ihn. Das Hinzufügen von Platz, bis etwas nicht mehr schlecht aussieht, ergibt das Minimum. Großzügig zu beginnen und zu trimmen ergibt die richtige Menge. Dichte UIs (Dashboards) sind legitim – aber als bewusste Entscheidung, nicht als Standard.

7. Verkleinere die Arbeitsfläche. Eine kleine Komponente, die auf einer 1400px großen Zeichenfläche entworfen wird, neigt zur Ausuferung, weil der Platz zum Füllen da ist. Beginne bei ~400px und gestalte zuerst das mobile Layout, wo die Einschränkungen real sind – bringe es dann auf einen großen Bildschirm und lockere nur das, was sich wirklich beengt anfühlte. Du wirst weniger ändern, als du erwartest.

---

Hierarchie – die Technik, die am meisten bewirkt

Alles auf dem Bildschirm sitzt in einer Pyramide: primär, sekundär, tertiär. Wenn alles konkurriert, liest sich die UI als Rauschen. Das macht ein Design „designt“ aus – nicht das Styling.

Größe ist nicht alles. Sich allein auf die Schriftgröße zu verlassen, ergibt primäre Inhalte, die zu groß sind, und sekundäre Inhalte, die zu klein sind. Verwende stattdessen Schriftstärke und Farbe, um die Betonung zu tragen, und halte die Größen angemessen.

Maximal drei Textfarben:

• dunkel – primärer Inhalt
• grau – sekundärer Inhalt
• helleres Grau – tertiärer Inhalt (Fußnoten, Urheberrechte)

Alle drei tragen Text in Körpergröße, daher müssen alle drei 4,5:1 erreichen. „Helleres Grau“ bedeutet die hellste Abstufung, die diesen Wert noch erfüllt – ungefähr die Mitte einer 9-stufigen Rampe, nicht das blasse Ende. Die blassen Abstufungen sind nur für deaktivierte Zustände und große Texte gedacht.

Betonung durch Abschwächung. Wenn das wichtige Element nicht hervorsticht und du ihm nichts mehr hinzufügen kannst, schwäche stattdessen das ab, was mit ihm konkurriert. Blende die inaktiven Navigationspunkte aus; reduziere die Hintergrundfarbe der Seitenleiste, damit der Hauptinhalt nach vorne rückt.

Aktionen: Gestalte nach Hierarchie, nicht nach Semantik.

• Primär → volle Deckkraft, hoher Kontrast. Normalerweise genau eine pro Seite.
• Sekundär → Kontur oder ein Hintergrund mit geringem Kontrast.
• Tertiär → wie ein Link gestaltet.

Destruktiv ≠ großer roter Button. Wenn „Löschen“ nicht die primäre Aktion auf der Seite ist, gib ihm die tertiäre Behandlung – mache es dann zu einem großen roten primären Button innerhalb des Bestätigungsdialogs, wo es tatsächlich die primäre Aktion ist.

Labels sind das letzte Mittel. label: value gibt jedem Datenpunkt das gleiche Gewicht. Die meisten Daten identifizieren sich selbst durch Format ($19.99, eine E-Mail-Adresse) oder durch Kontext. Wo ein Label wirklich nötig ist, füge es in den Wert ein („12 auf Lager“, nicht „Auf Lager: 12“) oder füge es als sichtbar sekundären Inhalt hinzu. Ausnahme: Auf Seiten mit Spezifikationstabellen, auf denen Benutzer nach dem Label suchen, betone stattdessen das Label.

Balancieere Stärke gegen Kontrast. Solide Icons sind visuell schwer und übertönen den danebenstehenden Text – mildere ihre Farbe, um das auszugleichen. Es funktioniert auch umgekehrt: Wenn ein 1px-Rahmen in einer weichen Farbe zu subtil ist, aber zu hart, sobald du ihn abdunkelst, behalte die weiche Farbe und gehe auf 2px. Füge Stärke hinzu, um geringen Kontrast zu beheben; reduziere Kontrast, um übermäßige Stärke zu beheben.

Visuelle Hierarchie ≠ Dokumentenhierarchie. Semantisches Markup und visuelles Gewicht sind getrennte Entscheidungen. Abschnittstitel sind normalerweise Labels, keine Überschriften – eine h1 mit 16px ist in Ordnung, und manchmal sollte der Titel komplett visuell versteckt werden, weil der Inhalt für sich selbst spricht.

---

Harte Regeln

Abweichungen von diesen erzeugen einen bestimmten, erkennbaren Fehler.

1. Nie grauen Text auf einem farbigen Hintergrund. Grau auf Weiß funktioniert, weil es den Kontrast reduziert; Grau auf Farbe sieht einfach schmutzig aus. Weiß mit reduzierter Deckkraft wirkt ausgewaschen und deaktiviert und lässt Muster durch die Glyphen hindurchscheinen. Wähle stattdessen eine Farbe handverlesen mit dem Farbton des Hintergrunds aus und passe Sättigung und Helligkeit an.
2. Nie em für die Schriftgrößen-Skala. px oder rem.
3. Nie Farbstufen zur Laufzeit generieren. Definiere sie im Voraus.
4. Nie eine prozentuale Breite für etwas verwenden, das nicht skalieren soll. Seitenleisten erhalten feste Breiten; der Hauptbereich dehnt sich. Elemente erhalten eine max-width und schrumpfen nur, wenn der Bildschirm tatsächlich kleiner ist – eine Login-Karte sollte bei mittleren Bildschirmen nicht breiter sein als bei großen.
5. Nie Dinge proportional über Breakpoints hinweg skalieren. Große Elemente müssen schneller schrumpfen als kleine. Eine 2,5em-Überschrift auf 14px mobilem Fließtext berechnet sich zu 35px – viel zu groß; sie sollte dort 20–24px betragen. Ebenso sollte das Padding eines Buttons proportional enger werden, wenn der Button schrumpft, nicht mit seiner Schriftgröße skalieren.
6. Immer mehr Platz um eine Gruppe herum als innerhalb von ihr. Das ist die Lösung für „welches Label gehört zu welchem Feld“, gequetschte Aufzählungslisten und Überschriften, die am falschen Absatz zu kleben scheinen. Mehrdeutiger Abstand ist ein funktionaler Fehler, nicht nur ein ästhetischer.
7. Nie Farbe als einziges Signal verwenden. Füge ein Icon, eine Form oder einen Texthinweis hinzu. Für Diagramme unterscheide Reihen durch Kontrast (helle→dunkle Abstufungen einer Farbe) anstatt durch Farbton – farbenblinde Benutzer lesen Helligkeit zuverlässig, Farbton weniger.
8. Mindestkontraste: 4,5:1 für normalen Text. Die 3:1-Grenze gilt nur für großen Text, den WCAG als 24px normal oder 18,66px fett definiert – nicht 18px. Gehe von 4,5:1 aus, es sei denn, der Text ist wirklich so groß. Wenn Weiß-auf-Farbe scheitert, drehe es um: dunkler farbiger Text auf einem hellen Farbton (siehe references/systems.md). Separat: 3:1 gilt auch für Nicht-Text (WCAG 1.4.11): Wenn ein Rand das Einzige ist, das ein Steuerelement identifiziert – eine Eingabeumrandung, eine Checkbox-Kante – benötigt er 3:1 gegenüber seinem Hintergrund. Ein Haarstrich, der lediglich Inhalt trennt, nicht. Dies sind zwei verschiedene Tokens, nicht einer.
9. Nie ein Icon weit von seiner beabsichtigten Größe skalieren. Ein 16–24px großes Icon sieht bei 48px klobig und detailarm aus. Setze es stattdessen in einen farbigen Kreis.

---

Referenzen

assets/tokens.css – ein vollständiger, kontrastgeprüfter Startsatz aller oben genannten als CSS Custom Properties: Abstand, Schriftgrößen, Stärken, Rahmenbreite, eine feste Deckkraft-Skala, eine 9-stufige kühle Grau-Rampe, eine 9-stufige Primärfarbe, drei Akzent-Trios, fünf Erhebungen, eine semantische Rollenschicht (--surface, --text-primary, --action…) und ein Dark-Mode-Block, der nur diese Rollen überschreibt. Kopiere es ein und stimme die Farbtöne neu ab, anstatt die Skalen aus dieser Prosa neu abzuleiten. Referenziere die Rollen in Komponenten, nicht die rohen Rampen – das ist es, was den Dark Mode zum Funktionieren bringt. Jedes Text-/Flächen-Paar ist in beiden Modi mit ≥4,5:1 und jeder funktionale Rand mit ≥3:1 überprüft; die bewussten unterschwelligen Abstufungen (deaktiviert, dekorative Trennlinien, der nur-für-große-Texte-Schritt) sind nach Kriterium ausgenommen und inline kommentiert.

Lade diese, wenn die Arbeit sie erfordert:

• references/systems.md – Aufbau einer Palette von Grund auf: Auswahl der Basisfarbe, Sättigung an den hellen und dunklen Enden lebendig halten, Farbtonrotation, warme/kühle Grautöne und die beiden Ausweichlösungen, um Kontrastverhältnisse ohne hässliche Farbe zu erreichen.
• references/diagnose.md – Symptom → Lösungstabelle. Lade sie zuerst, wenn die Aufgabe darin besteht, bestehende UI zu verbessern, anstatt Neues zu bauen.
• references/techniques.md – Tiefen- und Lichtsimulation, zweiteilige Schatten, Grundlinienausrichtung, Buchstabenabstand, Ausbrechen aus Standard-Komponentenformen und Umgang mit benutzerhochgeladenen Bildern.