Modulare Typografie-Skala: So erstellen Sie ein konsistentes Typografie-System

Eine modulare Schriftgrößenskala ist ein Verhältnis, das auf eine Basisgröße angewendet wird und alle Schriftgrößen im Produkt generiert. Das ist die Grundidee. Sie wählen das Verhältnis, fixieren die Basis, generieren die einzelnen Schritte, liefern diese als Tokens aus und verwenden diese Tokens überall anstelle einzelner Pixelwerte. Im Idealfall wirkt jede Größe im Produkt harmonisch, weil sie es mathematisch auch ist.

Im schlimmsten Fall erhalten Sie 17 Schriftgrößen, die niemand rechtfertigen kann, Überschriften, die mit dem Fließtext um die Hierarchie konkurrieren, und vierteljährliche Redesign-Meetings, in denen jemand vorschlägt, die Größen zu standardisieren – ohne dass jemand weiß, worauf man sich konzentrieren soll. Die Skala selbst ist der Bezugspunkt für die Standardisierung. Dieser Artikel beschreibt, wie man eine Skala erstellt, die in einem realen Produkt Bestand hat – mit echten Verhältnissen, einer echten Token-Struktur und den notwendigen Figma- und Tailwind-Übersetzungen.

Was eine modulare Schriftskala eigentlich ist

Eine modulare Schriftskala ist ein einzelnes Verhältnis, das auf eine Basisgröße angewendet wird und alle Schriftgrößen des Produkts erzeugt. Genau dieses Verhältnis ist der Kern der Skala.

Wählen wir eine Basisgröße, beispielsweise 16 Pixel, und ein Verhältnis, beispielsweise 1,25. Multipliziert man 16 mit 1,25, erhält man 20. Multipliziert man 20 mit 1,25, erhält man wieder 25. So weiter, erhält man 31, 39, 49, 61. Dividiert man 16 durch 1,25, erhält man 12,8. Dividiert man das durch 1,25, erhält man 10,24. Das ist die Skala. Acht Größen, eine Basis, ein Verhältnis – vollkommene mathematische Konsistenz.

Der Grund dafür ist psychophysischer Natur. Die menschliche visuelle Wahrnehmung reagiert auf Verhältnisse, nicht auf absolute Unterschiede. Ein Sprung von 12 auf 14 fühlt sich ungefähr so ​​an wie ein Sprung von 24 auf 28, da beides annähernd denselben multiplikativen Schritt darstellt. Eine lineare Skala (12, 14, 16, 18, 20, 22) wirkt oben beengt und unten zu weitläufig. Eine modulare Skala hingegen wirkt gleichmäßig, weil sie es relativ gesehen auch ist.

Dieselbe Logik liegt musikalischen Intervallen zugrunde (Oktaven sind doppelt so groß, Quinten doppelt so groß, Quarten doppelt so groß), fotografischen Blendenöffnungen und einem Großteil der architektonischen Proportionslehre. Die Typografie hat sie sich einfach abgeschaut. Die in diesem Artikel genannten Verhältnisse (kleine Sekunde, reine Quarte, Goldener Schnitt) stammen aus gutem Grund aus der Musik: Sie beschreiben dieselbe Art von Wahrnehmungsbeziehung.

Die fünf Verhältnisse, die reale Produkte beschreiben

Die meisten Produkte liegen zwischen 1,125 und 1,618, und jedes Verhältnis vermittelt ein spezifisches Dichtesignal.

Die fünf Verhältnisse, die nahezu jede reale Benutzeroberfläche abdecken:

| Verhältnis | Name | Dichtesignal | Reale Implementierung |

------:|------|----------------|---------------------|

| 1,125 | Kleine Sekunde | Kompakt, dicht, datenintensiv | Vercel, Geist, die meisten Admin-Dashboards |

| 1,2 | Kleine Terz | Kompakt, ausgewogen | Tailwind-Standardskalierung |

| 1,25 | Große Terz | Standard-Redaktionsseiten | Stripe, Material-3-Textrollen |

| 1,333 | Perfekte Quarte | Großzügig, Magazin-Charakter | Redaktionelle Websites, längere Blogs |

| 1,618 | Goldener Schnitt | Dramatisch, displayorientiert | Marketingseiten, Hero-basierte Websites |

Zwei weitere kommen gelegentlich vor. 1,414 (die vergrößerte Quarte, die der Quadratwurzel aus 2 entspricht und dem Verhältnis hinter A4-Papier entspricht) liegt zwischen der perfekten Quarte und der perfekten Quinte und ist eine gute Wahl für Produkte im Magazin-Stil, die etwas mehr Dramatik als mit 1,333 erreichen sollen. 1,5 (die perfekte Quinte) ist auffälliger als 1,333 und dezenter als 1,618 und wird von vielen Marketingseiten-Generatoren standardmäßig verwendet.

Sie können zwar auch Verhältnisse außerhalb dieses Bereichs verwenden, sollten dies aber in der Regel vermeiden. Unter 1,1 sind die Abstände so gering, dass sie ineinander übergehen; Überschrift 3 und 4 lassen sich nicht auf den ersten Blick unterscheiden. Über 1,7 steigt die Skala so schnell an, dass keine brauchbaren mittleren Größen mehr vorhanden sind. Designer, die einen größeren Bereich als 1,618 benötigen, lösen in der Regel das falsche Problem: Sie brauchen zwei Skalen, nicht eine größere.

Wählen Sie das passende Verhältnis für Ihre Datendichte

Eine App mit vielen Daten benötigt ein enges Verhältnis, eine redaktionelle Website ein breites – die falsche Wahl wirkt sich überall negativ aus.

Wenn es sich bei Ihrem Produkt um ein Dashboard, ein Admin-Panel, ein CRM-System, ein Analysetool oder etwas anderes handelt, bei dem der Nutzer stundenlang lange Textzeilen liest, wählen Sie standardmäßig 1,125 oder 1,2. Das enge Verhältnis sorgt dafür, dass die Überschriften nicht von den Daten ablenken. Die Hierarchie bleibt erhalten, da sie in diesem Maßstab hauptsächlich durch Gewichtung, Farbe und Abstände und nicht durch die Größe bestimmt wird.

Wenn es sich bei Ihrem Produkt um eine SaaS-Marketingseite, eine Content-Website, eine Produktseite oder eine Dokumentationsseite handelt, wählen Sie standardmäßig 1,25 oder 1,333. Die mittleren Verhältnisse verleihen den Überschriften genügend Ausdruckskraft, um Abschnitte voneinander abzugrenzen, ohne dass der Fließtext im Vergleich dazu zu kurz wirkt. In diesem Bereich bewegen sich die meisten B2B-Produkte, und hier haben sich Tailwind, Material und Stripe angeglichen.

Bei redaktionellen, zeitschriftenartigen oder displayorientierten Produkten wie längeren Publikationen, Mode-Websites oder Kampagnen-Microsites empfiehlt sich ein Standard-Seitenverhältnis von 1,414 oder 1,618. Dieses breite Seitenverhältnis sorgt dafür, dass Überschriften wie solche wirken, die einen eigenen Hero-Block verdienen. Der Fließtext bleibt übersichtlich, da der Abstand zwischen Hero- und Fließtext für optimale Lesbarkeit sorgt.

Der Fehler liegt darin, ein Seitenverhältnis nur aufgrund seines beeindruckenden Klangs zu wählen (der Goldene Schnitt ist ein bekanntes Beispiel) und es einem Produkt aufzuzwingen, das diese Wirkung nicht benötigt. Ein Seitenverhältnis von 1,618 ist auf einem CRM-System unleserlich. Ein Seitenverhältnis von 1,125 wirkt auf einer redaktionellen Website blass. Wählen Sie das Seitenverhältnis, das Ihr Produkt tatsächlich benötigt, und legen Sie es fest.

Legen Sie die Basisgröße fest, bevor Sie skalieren

Die Basisschriftgröße ist der Bezugspunkt für alle Skalierungsschritte. Ist sie falsch, sind alle Schritte fehlerhaft.

Standardmäßig wird für Fließtext im Web eine Schriftgröße von 16 Pixeln verwendet. Die Standardeinstellung im Browser ist 16, das Stylesheet des User-Agents ist ebenfalls 16, die durchschnittliche bevorzugte Lesegröße für Erwachsene liegt bei 16, und die Richtlinien zur Barrierefreiheit (WCAG) und die Human Interface Guidelines (BRAND17) legen 16 als Mindestgröße für Fließtext fest. Bei einer älteren Zielgruppe oder einem Produkt mit hohem Leseanteil können Sie auf 17 oder 18 gehen, aber die Schriftgröße sollte im Fließtext niemals unter 16 fallen.

Diese Basisgröße dient als Multiplikator. Jeder Schritt darüber ergibt sich aus der Basisgröße multipliziert mit einem bestimmten Faktor. Jeder Schritt darunter ergibt sich aus der Basisgröße geteilt durch einen bestimmten Faktor. Wenn Sie die Basisgröße ändern, verschiebt sich jede Stufe. Das ist normal und entspricht der Funktionsweise des Systems. Die Änderung der Basisgröße ist jedoch eine strukturelle Änderung und keine Anpassung für einzelne Bildschirme. Sie sollte daher einmalig und bewusst vor der Veröffentlichung der Skalierung vorgenommen werden.

Für Mobilgeräte können Sie die Basisgröße reduzieren (z. B. auf 15 oder 16) und relative Einheiten verwenden. Für den Druck beträgt die Basisgröße üblicherweise 11 oder 12 Punkt, und die Seitenverhältnisse bleiben gleich. Für Dokumentationsoberflächen mit Codeblöcken legen Sie die Schriftgröße des Fließtextes auf 16 und die des Codeblocks auf 14 fest, wobei dasselbe Seitenverhältnis für die Code-Skalierung gilt. Die Basisgröße ist medienspezifisch, das Seitenverhältnis produktspezifisch – beides sind Entscheidungen, die Sie nur einmal treffen.

Eine weitere Regel: Legen Sie die Basisgröße im Web in rem fest, nicht in Pixeln. Die gesamte Skala sollte in rem angegeben werden, damit die Schriftgrößeneinstellungen der Nutzer und die Barrierefreiheitsfunktionen (Zoom, Lesemodus, Browser-Skalierung) korrekt übernommen werden. Tailwind und Material Design handhaben dies bereits. Die dynamische Typografie von BRAND18 für iOS bietet die entsprechende Funktionalität. Wenn Ihre Skala fest in Pixeln codiert ist, arbeiten Sie mit der Plattform zusammen.

Stufen generieren und nach Funktion benennen

Eine Skala mit sieben bis neun Stufen deckt alle benötigten Produktgrößen ab. Benennen Sie die Stufen nach Funktion, nicht nach Größe.

Nehmen Sie eine Basisgröße von 16 Pixel und ein Seitenverhältnis von 1,25. Die Stufen sind:

• 10 (extra kleine Bildunterschrift, Fußnote)
• 13 (kleiner, sekundärer Text)
• 16 (Textkörper, Basis)
• 20 (Vorspann, großer Textkörper)
• 25 (H4, kleine Überschrift)
• 31 (H3, mittlere Überschrift)
• 39 (H2, große Überschrift)
• 49 (H1, Seitenüberschrift)
• 61 (Display, Hero)

Neun Stufen. Das ist das gesamte Produkt. Manche Produkte verwenden sieben oder acht Stufen, manche zehn, aber ab zehn Stufen wird die Skala dünner und es entstehen Größen, die niemand verwendet.

Nun benennen Sie sie. Nicht „Text-31“ oder „39px“. Benennen Sie sie nach ihrer Funktion: Bildunterschrift, klein, Textkörper, Vorspann, H4, H3, H2, H1, Display. Die Rollenbezeichnungen sind die Vereinbarung mit der Entwicklungsabteilung, nicht die Pixelwerte. Der Pixelwert kann sich ändern, wenn sich die Basis oder das Seitenverhältnis ändert, aber die Rolle bleibt gleich. H1 ist immer die größte Überschrift. Der Textkörper ist immer die Basis. Die Bildunterschrift ist immer der kleinste lesbare Text.

Das macht eine Skala zu einem System und nicht zu einer Tabelle. Ein Designer sagt: „Das ist der Textkörper“, und ein Entwickler liefert den Textkörper. Ändert sich die Skala im nächsten Quartal, bleibt der Textkörper gleich, und jede Komponente übernimmt den neuen Wert automatisch. Niemand muss jede 16 im Quellcode suchen und in 17 ändern.

Material Design 3 liefert seine Skala nach Rolle benannt: Anzeige, Überschrift, Titel, Beschriftung, Textkörper, jeweils mit Größenvarianten (groß, mittel, klein). Apples HIG liefert Großtitel, Titel 1, Titel 2, Titel 3, Überschrift, Textkörper, Hervorhebung, Unterüberschrift, Fußnote, Bildunterschrift 1, Bildunterschrift 2. Tailwind liefert Text-xs bis Text-9xl, was T-Shirt-Größen entspricht und nicht der Rollenbenennung. Hier sind die Standardeinstellungen von Tailwind möglicherweise schwächer als die von Material Design. Die meisten Teams, die Tailwind einsetzen, verwenden schließlich rollenbasierte Aliase zusätzlich zu den T-Shirt-Klassen.

Die Skala in Design-Tokens übersetzen

Tokens machen die Skala aus der Tabelle eines Designers zum Vertragsinhalt des Teams.

Design-Tokens sind benannte Werte, die Designentscheidungen repräsentieren. Für eine Typografie-Skala benötigen Sie drei Ebenen:

1. Roh-Tokens: Die tatsächlichen Größenwerte. font-size-100, font-size-200 usw. oder benannt wie font-size-body, font-size-h1. Diese sind die maßgebliche Informationsquelle.

2. Semantische Tokens: Aliase, die die Absicht ausdrücken. text-heading-page, text-body-default, text-caption. Semantische Tokens verweisen auf Roh-Tokens. Komponenten verwenden semantische Tokens, niemals direkt Roh-Tokens.

3. Komponenten-Tokens. Bindungen innerhalb bestimmter Komponenten. card-title-size verweist auf text-heading-card, welches wiederum auf font-size-200 verweist. Komponenten-Tokens ermöglichen komponentenbezogene Überschreibungen, ohne das System zu beeinträchtigen.

Eine minimale JSON-Token-Datei für eine 16-Bit-Basis mit einem Seitenverhältnis von 1,25:

{
  "font-size": {
    "raw": {
      "100": { "value": "0.625rem" },
      "200": { "value": "0.8125rem" },
      "300": { "value": "1rem" },
      "400": { "value": "1.25rem" },
      "500": { "value": "1.5625rem" },
      "600": { "value": "1.9375rem" },
      "700": { "value": "2.4375rem" },
      "800": { "value": "3.0625rem" },
      "900": { "value": "3.8125rem" }
    },
    "semantic": {
      "caption":  { "value": "{font-size.raw.100}" },
      "small":    { "value": "{font-size.raw.200}" },
      "body":     { "value": "{font-size.raw.300}" },
      "lead":     { "value": "{font-size.raw.400}" },
      "h4":       { "value": "{font-size.raw.500}" },
      "h3":       { "value": "{font-size.raw.600}" },
      "h2":       { "value": "{font-size.raw.700}" },
      "h1":       { "value": "{font-size.raw.800}" },
      "display":  { "value": "{font-size.raw.900}" }
    }
  }
}

Diese Struktur ist portabel. Style Dictionary, Tokens Studio, Specify und Supernova lesen dieses Format und erzeugen Figma-Variablen, CSS-Variablen, Tailwind-Konfigurationen, iOS-Swift-Konstanten, Android-XML – je nachdem, was die Plattformen benötigen. Die Tokens bilden die Grundlage. Alles andere wird generiert.

Skalierung in Figma-Variablen speichern

Die Skalierung wird vom Designteam in Figma-Variablen verwaltet und ist als einzelne Typografie-Sammlung mit semantischen Aliasen strukturiert.

Erstellen Sie eine Variablensammlung namens „Typografie“. Fügen Sie darin für jede Rohgröße (size/100 bis size/900) eine Zahlenvariable mit den entsprechenden Pixelwerten in rem (10, 13, 16, 20, 25, 31, 39, 49, 61) hinzu. Fügen Sie anschließend eine zweite Ebene von Aliasen hinzu: text/caption, text/small, text/body, text/lead, text/h4, text/h3, text/h2, text/h1, text/display. Jeder Alias ​​verweist auf eine Variable für die Rohgröße.

Erstellen Sie dann Textstile, einen pro Rolle. Heading/H1 verwendet text/h1 für die Größe, Ihre Überschriftenschriftart für die Schriftfamilie, Ihre Überschriftenstärke für die Strichstärke und Ihr Überschriften-Zeilenhöhenverhältnis für den Zeilenabstand. Body/Default verwendet text/body, Ihre Fließtextschriftart und normale Strichstärke. Wiederholen Sie dies für jede Rolle.

Die Regel besteht darin, dass Designer Benutzeroberflächen mithilfe von Textstilen gestalten, anstatt Schriftgrößen im Inspektor einzugeben. Sobald ein Team diese Regel verinnerlicht hat, wird die Skalierung automatisch durchgesetzt. Jeder, der eine benutzerdefinierte Größe festlegt, muss das Muster sichtbar brechen, und diese Sichtbarkeit ist die maßgebliche Regel.

Kombinieren Sie dies mit einer Modus-Konfiguration, wenn Sie mehrere Dichtemodi unterstützen. Ein „kompakter“ Modus kann die Rohgrößenvariablen überschreiben und ein Verhältnis von 1,125 für eine dichtere Darstellung verwenden. Ein „komfortabler“ Modus kann 1,25 verwenden. Die Aliase bleiben gleich. Komponenten ändern sich nicht. Die Skalierung wird lediglich darunter angepasst. Das ist der Vorteil des Systems.

Skalierung in Tailwind CSS integrieren

Die Tailwind-Konfiguration dient dem Entwicklerteam zur Festlegung der Skalierung und sollte die Variablenstruktur von Figma exakt widerspiegeln.

Ersetzen Sie Tailwinds Standardwert fontSize durch Ihre Skalierung in tailwind.config.js:

module.exports = {
  theme: {
    fontSize: {
      'caption':  ['0.625rem',  { lineHeight: '1rem' }],
      'small':    ['0.8125rem', { lineHeight: '1.25rem' }],
      'body':     ['1rem',      { lineHeight: '1.5rem' }],
      'lead':     ['1.25rem',   { lineHeight: '1.75rem' }],
      'h4':       ['1.5625rem', { lineHeight: '2rem' }],
      'h3':       ['1.9375rem', { lineHeight: '2.375rem' }],
      'h2':       ['2.4375rem', { lineHeight: '2.875rem' }],
      'h1':       ['3.0625rem', { lineHeight: '3.5rem' }],
      'display':  ['3.8125rem', { lineHeight: '4.25rem' }],
    },
  },
}

text-h1 im Markup hat nun dieselbe Bedeutung wie Heading/H1 in Figma. Der Klassenname ist die Vereinbarung. Entwickler wählen keine Größen, sondern Rollen. Die Rolle wird zur Build-Zeit automatisch dem richtigen Pixelwert zugeordnet.

Die Zeilenhöhen sind hier nicht willkürlich. Das Muster ist: geringer Zeilenabstand für kleine Schriftgrößen, größerer Zeilenabstand für Fließtext und Überschriften, wieder geringer Zeilenabstand für Überschriften. Eine gängige Regel ist: Zeilenhöhe 1,5 für Fließtext, 1,1 bis 1,2 für Überschriften, mit einem Übergang über 1,3 bis 1,4 für Überschriften und H4-Schriftgrößen. Sie können dies als weitere Skala (eine Zeilenabstandsskala) oder als Werte pro Schritt ausdrücken. Das Verhältnis zwischen Größe und Zeilenabstand sollte jedoch bewusst und nicht nach Augenmaß festgelegt werden.

Wenn Sie die Standardklassen von Tailwind neben Ihrer Skala beibehalten möchten (für älteren Code oder Komponenten von Drittanbietern), verwenden Sie extend, anstatt fontSize vollständig zu ersetzen. Langfristig ist jedoch nur eine Skala vorgesehen, nicht zwei. Zwei Typografieskalen im selben Produkt führen letztendlich zu einer uneinheitlichen Typografie und einer Reihe von Fehlern.

Kombinieren Sie die Skala mit einem echten Leitfaden zur Schriftartenkombination für die Schriftauswahl und einem Designsystem-Framework, das die Skala in den Kontext setzt. Die Skala ist ein Teil des Typografiesystems, die Schriftauswahl und die Rollenzuordnung sind die anderen. Benötigen Sie eine funktionierende Skala, echte Tokens und Figma + Tailwind, die von Anfang an korrekt eingerichtet sind? Miete Brainy. Wir liefern vollständige Typografiesysteme über BrandBrainy und UXBrainy aus, inklusive Tokens, den Figma-Variablen und der Tailwind-Konfiguration – alles in einem Paket.

Die Governance-Regeln für eine funktionierende Skala

Jede veraltete Typografieskala ist auf die gleiche Weise gescheitert: durch Ausnahmen.

Drei Regeln sorgen dafür, dass eine Skala länger funktioniert als jedes Tool:

Regel 1: Jede neue Komponente wählt Rollen, nicht Größen. Ein Designer, der eine Karte erstellt, wählt „Body“ für den Textkörper, „H3“ für den Titel und „Caption“ für den Zeitstempel. Er gibt nicht font-size: 18px im Inspektor ein. Existiert die Rolle nicht, schlägt er eine neue Rolle über das System vor, anstatt sie einmalig zu überschreiben.

Regel 2: Ausnahmen erhalten einen Namen und ein Datum. Benötigt das Marketingteam beispielsweise eine 72px große Überschrift für einen Hero-Bereich auf einer Kampagnenseite, die Anzeigegröße beträgt aber 61px, erhält die Ausnahme einen Namen (hero-marketing-q3-launch) und ein Datum. Nach dem Versand der Kampagne wird die Ausnahme entweder in die Skala aufgenommen (falls sie wiederverwendbar ist) oder gelöscht (falls sie einmalig war). Anonyme Überschreibungen sind nicht zulässig.

Regel drei: Die Skala wird vierteljährlich, nicht jährlich überprüft. Vierteljährlich ist der Zeitraum kurz genug, um Abweichungen frühzeitig zu erkennen. Jährlich ist der Zeitraum lang genug, dass jedes Team bereits Anpassungen vorgenommen hat und deren Rücknahme ein Projekt darstellt. Die vierteljährliche Überprüfung dauert nur 15 Minuten. Die jährliche Überprüfung bedeutet eine komplette Neugestaltung.

Teams, die ihre Typografieskala verlieren, erzählen im Nachhinein immer die gleiche Geschichte: Jemand benötigte 17px für einen Button, jemand anderes 21px für ein Banner. Sechs Monate später befinden sich 47 Schriftgrößen im Quellcode, und niemand weiß mehr, welche davon korrekt sind. Die Skala ist verschwunden. Zurück bleibt ein Friedhof der Schriftgrößen.

Das lässt sich verhindern, indem man die Skala als Vertrag und nicht als Tabelle behandelt. Die Einhaltung des Vertrags wird durch Tools (Figma-Styles, Tailwind-Klassen, Lint-Regeln) und regelmäßige Überprüfungen sichergestellt. Der Vertrag wird im Rahmen der Quartalsüberprüfung neu verhandelt. Alles, was nicht im Vertrag enthalten ist, gilt als Fehler.

FAQ

Was ist eine modulare Schriftskala?

Eine modulare Schriftskala ist ein System, bei dem jede Schriftgröße eines Produkts durch Anwendung eines einheitlichen Verhältnisses auf eine einheitliche Basisgröße generiert wird. Wählen Sie eine Basisgröße (üblicherweise 16 Pixel für das Web), ein Verhältnis (üblicherweise zwischen 1,125 und 1,618) und multiplizieren oder dividieren Sie die Basisgröße wiederholt mit diesem Verhältnis, um die einzelnen Schritte zu generieren. Das Ergebnis ist eine Skala, in der jede Größe mathematisch mit jeder anderen Größe in Beziehung steht. Dies verleiht der Typografie eine innere Konsistenz, die durch willkürliche Pixelwahl nicht erreicht werden kann.

Welches Verhältnis sollte ich für meine Schriftskala verwenden?

Wählen Sie das Verhältnis entsprechend der benötigten Datendichte Ihres Produkts. Verwenden Sie 1,125 oder 1,2 für datenintensive Produkte wie Dashboards und Administrationstools, bei denen Überschriften nicht von den Daten ablenken sollen. Verwenden Sie 1,25 oder 1,333 für Standard-SaaS-Marketingseiten, Content-Websites und Produktseiten, auf denen die meisten B2B-Produkte zu finden sind. Für redaktionelle Inhalte, Magazine oder Display-Produkte, bei denen Überschriften auch wirklich wie Überschriften wirken sollen, verwenden Sie 1,414 oder 1,618. Der häufigste Fehler ist die Wahl eines Verhältnisses, weil es imposant klingt, anstatt weil es zum Produkt passt.

Wie viele Größen sollte eine Schriftskala haben?

Die meisten produktionsreifen Skalen umfassen sieben bis neun Größen. Caption, Small, Body, Lead, H4, H3, H2, H1 und Display decken nahezu alle gängigen Produktoberflächen ab. Weniger als sieben Größen lassen Lücken, die Designer mit individuellen Anpassungen füllen müssen. Mehr als zehn Größen führen zu einer zu geringen Anzahl an Größen, die nie verwendet werden und die Wartung des Systems erschweren. Sieben bis neun Größen sind optimal. Die Rollennamen sollten den Zweck jeder Größe beschreiben, nicht ihren Pixelwert.

Soll ich rem oder px für die Werte der Schriftskala verwenden?

Verwenden Sie rem für das Web. Die Standard-Schriftgröße im Browser beträgt 16 Pixel. Nutzer können diese jedoch über die Barrierefreiheitseinstellungen und Browserpräferenzen ändern. Eine rem-basierte Skalierung berücksichtigt diese Einstellungen automatisch. Pixelbasierte Skalierungen ignorieren sie. Tailwind, Material Design und die meisten modernen Designsysteme verwenden aus diesem Grund rem. Für mobile Plattformen gilt: iOS verwendet Punkte und unterstützt dynamische Typografie, Android verwendet skalierungsunabhängige Pixel (sp). Das Prinzip ist dasselbe: Verwenden Sie die relative Einheit der Plattform, nicht absolute.

Was ist der Unterschied zwischen einer modularen Typografieskala und Design-Tokens?

Eine modulare Typografieskala ist die mathematische Grundlage, Design-Tokens die Art und Weise, wie diese Grundlage geschaffen wird. Die Skala definiert die Werte (10, 13, 16, 20, 25, 31, 39, 49, 61). Tokens sind die benannte Ebene, die es dem restlichen Designsystem ermöglicht, auf diese Werte zuzugreifen, ohne sie fest zu kodieren. Man kann zwar eine Skala ohne Tokens haben, aber diese Skala hält in einer realen Codebasis nicht stand. Man kann zwar Tokens ohne Skala haben, aber die Werte wären willkürlich. Das vollständige System ist die Skala, ausgedrückt als Tokens, mit Rohdaten-, semantischen und Komponentenebenen, und wird über dieselbe Quelle an Figma und den Code ausgeliefert.

Das Muster, das die meisten Typografieskalen übersehen

Eine Typografieskala ist keine Liste von Schriftgrößen, sondern ein Vertrag darüber, wie Text in Ihrem Produkt hierarchisch strukturiert wird.

Teams, die dies richtig umsetzen, wählen nicht einfach ein Verhältnis und belassen es dabei. Sie wählen ein Verhältnis, entwickeln die Skala, liefern sie als Tokens aus, integrieren sie in Figma und Tailwind und setzen sie anschließend durch vierteljährliche Überprüfungen und eine ausnahmslose Regel durch. Die Skala ist nicht das Ergebnis, sondern die Disziplin. Das Ergebnis ist die Voraussetzung für die Disziplin.

Teams, die dies falsch angehen, behandeln die Skala wie ein Moodboard. Sie wählen ansprechende Proportionen in einem Pinterest-Mockup, liefern ein statisches Spezifikationsdokument und stellen sechs Monate später fest, dass das Entwicklerteam es nie übernommen hat, weil das Dokument keinen ausführbaren Code enthielt. Oder sie integrieren die Skalierung in Figma, aber nie in Tailwind, und die Designdateien und die Produktions-App driften auseinander, bis sie zu zwei verschiedenen Produkten mit unterschiedlichen Schriftarten werden. Oder sie integrieren sie in beide Plattformen, ohne jegliche Kontrolle, und innerhalb eines Jahres überwiegen die Ausnahmen die Regeln.

Die Abkürzung besteht darin, die Skalierung von Anfang an als Vertrag zu behandeln. Die Berechnungen legen die einzelnen Schritte fest. Die Tokens ermöglichen die Implementierung der Schritte. Figma-Variablen und die Tailwind-Konfiguration sorgen dafür, dass die Schritte auf beiden Seiten der Design-Entwicklungs-Grenze nutzbar sind. Die Kontrolle hält die Schritte nach dem Launch am Leben. Jeder Teil des Systems erfüllt eine bestimmte Aufgabe, und das System versagt, wenn einer fehlt.

Wenn Sie eine funktionierende modulare Typografie-Skala, echte Token, echte Figma-Variablen, eine echte Tailwind-Konfiguration und einen Governance-Plan benötigen, der die Skala auch nach dem Launch zusammenhält, Brainy einstellen. Wir liefern vollständige Designsysteme über BrandBrainy und UXBrainy aus, mit Typografie-Skalen, die von Anfang an als Token konzipiert sind, Typografiesystem mit Markenfarbpalette verknüpft sind und die Regeln enthalten, die das System nach dem Launch am Laufen halten.