7 Schriftgrößenskala-Fehler, die ein Design-System zerstören

Prüfe die Schriftgrößen in einem zwei Jahre alten Produkt, und du findest selten die sechs Größen, die die Dokumentation des Design-Systems verspricht. Du findest gut zwanzig: die sechs, plus 15px „für die Seitenleiste“, 17px „weil 16 in dieser Karte klein wirkte“, 30px „nah genug an 28“ — jede von einer vernünftigen Person ausgeliefert, die ein lokales Problem löste.

Die meisten Schriftgrößenskala-Fehler teilen einen Mechanismus: Die Skala ist nicht länger die Quelle, aus der Größen, Zeilenhöhen und Abstände tatsächlich abgeleitet werden, sondern wird zu einer Dokumentation, von der die Produktion still abweicht. Die folgenden sieben sind die häufigsten Wege in diesen Zustand — jeder benannt als der Fehler, den du beobachten kannst, dann der Mechanismus dahinter, dann eine Lösung in einem Satz.

Das sind Typografie-Fehler auf der Ebene des Design-Systems, keine Geschmacksfragen; sie setzen voraus, dass du weißt, was eine modulare Skala ist. Falls noch nicht, beginne mit unserem Leitfaden zur Schriftgrößenskala.

1. Größen außerhalb der Skala schleichen sich ein — „nur dieses eine Mal, 17px“

Der Fehler: Die Codebasis sammelt Größen an, die die Skala nie erzeugt hat, eine vernünftige Ausnahme nach der anderen, bis die Skala nichts mehr beschreibt und niemanden mehr einschränkt — Dekoration in der Dokumentation.

Der Mechanismus: Jede Ausnahme ist lokal rational und global zersetzend. Die erste 17px löst ein echtes Problem; sie legt zugleich fest, dass die Skala verhandelbar ist, und jede folgende Ausnahme lässt sich leichter rechtfertigen als die letzte. Die traditionelle typografische Skala, die der Druck über Jahrhunderte trug — 6, 7, 8, 9, 10, 11, 12, 14, 16, 18, 21, 24 Punkt und aufwärts —, hielt zum Teil, weil sie physisch geschlossen war: Schrift war Metall, gegossen in genau diesen Größen, und es gab kein 17pt, nach dem man greifen konnte. Digitale Schrift hat die Beschränkung entfernt, aber nicht das Bedürfnis danach, also muss die Disziplin ausdrücklich sein.

Die Lösung: Behandle die Skala als geschlossen — wenn eine benötigte Größe fehlt, ändere die Skala (passe das Verhältnis an, unterteile einen Schritt), füge nie einen Wert daneben hinzu.

2. Das Verhältnis ist zu steil für das Produkt

Der Fehler: Das Team überspringt regelmäßig Ebenen — Seiten springen von h1 zu h4, und die obere Hälfte der Skala bleibt stillschweigend ungenutzt.

Der Mechanismus: ein Verhältnis, das danach gewählt wurde, wie es in einem Schriftmuster aussieht, statt nach der Textdichte des Produkts. Vergleiche eine Skala im Goldenen Schnitt mit einer flachen, beide auf einer 16px-Basis:

In einem textdichten Produkt versagt die Spalte mit 1,618 fast sofort: Zwischen 16 und 26 existiert nichts, dort wo der meiste Interface-Text lebt, und eine h1 mit 110px gehört auf ein Plakat, nicht auf ein Dashboard. Damit konfrontiert, geben Teams nicht die Hierarchie auf — sie geben die Skala auf.

Die Lösung: Wähle das Verhältnis nach der Textdichte — grob 1,125–1,25 für dichte UI, steiler für redaktionelle Arbeit — und unterteile Intervalle, wenn du Zwischengrößen brauchst, statt Lücken zu dulden.

3. Größen folgen einer Skala, Zeilenhöhen werden geraten

Der Fehler: Spalten, die anfangs ausgerichtet sind, driften auseinander; der Abstand nach Überschriften sieht auf jeder Seite anders aus; Layouts wirken unruhig, und niemand kann sagen, warum.

Der Mechanismus: Die Zeilenhöhe, nicht die Schriftgröße, ist das, was tatsächlich vertikalen Raum einnimmt. Wenn Größen systematisch sind, aber die Zeilenhöhe jedes Elements ein spontanes 1,3, 1,45 oder „28px sah richtig aus“ ist, dann ist die Höhe jedes Textblocks willkürlich — vertikale Beziehungen können nicht aufgehen, weil es keine Einheit gibt, in der sie gezählt werden.

Die Lösung: Leite Zeilenhöhen aus einer Grundlinien-Einheit von der Hälfte der Basis ab — 8px auf einer 16px-Basis — und erlaube nur ganze oder halbe Vielfache: Fließtext 16px auf einer 24px-Zeile (drei Grundlinien), h2 38px auf 48px (sechs).

Diese Grundlinien-Disziplin lässt sich am leichtesten anhand einer funktionierenden Referenz beurteilen. Öffne eine kohärente Skala im Scale Composer — Basis 16, Quarte, jede Zeilenhöhe am 8px-Grundlinienraster eingerastet, Abstände aus derselben Progression abgeleitet. Die vier verbleibenden Fehler sind alle als Abweichungen von diesem Bild sichtbar.

4. Tokens sind nach Werten benannt — und lügen nach einer Neujustierung

Der Fehler: Das System justiert sein Verhältnis von 1,333 auf 1,25 neu, und font-24 gibt jetzt 21px aus. Oder, häufiger, niemand justiert neu — weil font-24 über Hunderte von Aufrufstellen umzubenennen mehr kostet, als mit dem falschen Verhältnis zu leben.

Der Mechanismus: Ein wertbasierter Name verschweißt jede Aufrufstelle mit der heutigen Ausgabe statt mit der Aufgabe der Größe. Rollennamen beschreiben die Aufgabe, und die Aufgabe überlebt eine Neujustierung — was überhaupt erst der Sinn davon ist, Größen aus zwei Parametern zu erzeugen.

Die Lösung: Benenne Tokens nach Rollen (body, heading-lg), niemals nach Werten.

5. Die Schrift ist skaliert, die Abstände nicht

Der Fehler: Der Text ist proportioniert, aber die Abstände darum herum sind über den Daumen gepeilt — Karten, Stapel und Abschnitte wirken subtil daneben, selbst dort, wo die Typografie selbst sorgfältig ist.

Der Mechanismus: Proportion wird aus Größe und Raum zusammen wahrgenommen. Wenn Schriftgrößen einem Verhältnis folgen, aber Ränder und Innenabstände der Gewohnheit folgen — 12px hier, 20px dort —, spricht die Hälfte des Systems eine andere Sprache, und das Auge muss zwei Regelsätze in Einklang bringen statt einen.

Die Lösung: Leite die Abstands-Schritte aus derselben Basis und Skala ab wie die Schrift — im Scale Composer stammen die Abstands-Schritte aus derselben Progression, sodass beide nicht auseinanderdriften können.

6. Überschriftengrößen werden pro Seite gewählt, nicht einmal abgeleitet

Der Fehler: Die h2 ist 32px auf der Marketing-Website, 28px in der Dokumentation und 30px in der App — sichtbar in jedem Nebeneinander-Screenshot, unsichtbar in jeder Einzelseiten-Prüfung.

Der Mechanismus: Jede seitenweise Entscheidung ist eine Abzweigung, und jede Abzweigung ist in ihrem eigenen Kontext vertretbar. Aber was Typografie zu einem System macht, ist Wiedererkennung — das Gefühl der Leserin und des Teams, dass dies ein Produkt ist — und Wiedererkennung verstärkt sich nur, wenn die Leiter einmal abgeleitet und überall wiederverwendet wird.

Die Lösung: Leite die Überschriften-Leiter einmal aus der Skala ab und lass seitenweise Entscheidungen Rollen wählen, niemals Pixelwerte.

7. Alles wird in px ausgeliefert

Der Fehler: Eine Leserin erhöht die Standard-Schriftgröße ihres Browsers — eine Einstellung, auf die manche sehbehinderte Menschen angewiesen sind — und die Website ignoriert es vollständig.

Der Mechanismus: px ist absolut, während rem sich an der Standard-Schriftgröße des Nutzers auflöst (16px, sofern er sie nicht geändert hat). Seiten-Zoom funktioniert weiterhin bei px-gesetztem Text, aber die Schriftgrößen-Voreinstellung ist ein anderer Barrierefreiheits-Kanal — sie vergrößert Text, ohne das ganze Layout zu vergrößern — und reines px-CSS schaltet diesen Kanal ab.

Die Lösung: Drück die Skala in rem aus — teile jeden px-Wert durch 16 — und lass px nur in Design-Tool-Mockups leben.

Stress-teste deine Skala, bevor es die Produktion tut

Diese Schriftgrößenskala-Probleme teilen noch einen Zug: Jedes ist früh billig zu erkennen und teuer rückgängig zu machen, nachdem hundert Seiten davon abhängen. Die schnellste Diagnose ist bewusster Missbrauch — treib das Verhältnis in seine Extreme und beobachte, welche Ebenen zuerst brechen. Richtung 1,1 fallen benachbarte Schritte zu Beinah-Duplikaten zusammen, die niemand auseinanderhalten kann; jenseits von 1,6 wachsen die Display-Größen über jeden realistischen Container hinaus. Führe dieses Experiment mit der Stresstest-Skala im Scale Composer durch — die Ebenen, die dort zuerst brechen, sind die, die die Produktion für dich gebrochen hätte.