Content Pattern Library ist eine strukturierte Sammlung wiederverwendbarer Text-Komponenten – von Fehlermeldungen über Button-Texte bis zu Onboarding-Formulierungen – die konsistente Produktsprache in Design-Systemen sichert.
Rubrik: Mediendesign & Digitale Medien · Unterrubrik: UX Writing & Content Design · Niveau: Profi Synonyme / Auch bekannt als: Text-Komponenten, Content Library, Writing Pattern Library, UX Content System
Was ist eine Content Pattern Library?
Design Systems (wie Googles Material Design, Salesforces Lightning Design System oder Atlassians Design System) bestehen typischerweise aus visuellen Komponenten: Buttons, Cards, Modals, Formularelemente. Eine Content Pattern Library erweitert dieses Konzept um die textliche Dimension: Sie dokumentiert nicht nur, wie Komponenten aussehen, sondern was in ihnen steht und nach welchen Regeln Texte für diese Komponenten geschrieben werden.
Die Idee wurde maßgeblich durch das Buch „Design Systems" von Alla Kholmatova (2017) geprägt, die funktionale und perceptuelle Muster unterscheidet. Für UX Writer sind Content Patterns eine Antwort auf eine häufige Herausforderung: In großen Produkten schreiben viele Menschen Texte – Entwickler, Produktmanager, Designer – und ohne ein gemeinsames Referenzwerk entstehen Inkonsistenzen.
Erklärung
Was sind Content Patterns?
Ein Content Pattern ist eine wiederverwendbare, standardisierte Textlösung für einen bestimmten Schnittstellenkontext. Statt jede Fehlermeldung neu zu erfinden, gibt ein Pattern vor:
- Welche Struktur hat diese Art von Text?
- Welchen Ton hat sie?
- Welche Informationen sind obligatorisch?
- Wie lang darf sie sein?
- Wie sieht ein konkretes Beispiel aus?
Typen von Content Patterns
Systemzustands-Patterns: Texte für wiederkehrende Systemzustände: Laden, Fehler, leer, Erfolg, Timeout.
Beispiel: Pattern „Ladezustand"
- Struktur: Kurztext + optionale Aktivitätsanzeige
- Ton: Neutral, kein Humor
- Länge: Max. 5 Wörter
- Beispiel: „Lädt…" / „Daten werden geladen."
Fehlermeldungs-Patterns: Typisierte Fehlermeldungen nach Fehlertyp (Validierungsfehler, Systemfehler, Netzwerkfehler). Vgl. Fehlertext-Design.
Onboarding-Patterns: Standardtexte für Empty States (Leerer Zustand (Empty State)), Welcome-Screens, Feature-Einführungen.
Navigations-Patterns: Benennung von wiederkehrenden Navigationselementen: Tabs, Breadcrumbs, Back-Links.
Transaktions-Patterns: Texte für Bestätigungen, Warnungen vor irreversiblen Aktionen, Erfolgs-Feedback.
Datenschutz & Legal-Patterns: Standardformulierungen für DSGVO-Einwilligungen, Datenschutzhinweise in Formularen.
Aufbau einer Content Pattern Library
Eine gut strukturierte Content Pattern Library enthält für jedes Pattern:
- Pattern-Name – Eindeutiger, sprechender Name (z. B. „Lösch-Bestätigung")
- Kontext – Wann wird dieses Pattern verwendet?
- Struktur – Welche Textteile hat es (Titel, Body, CTA)?
- Constraints – Zeichenlimits, obligatorische/optionale Teile
- Ton-Hinweis – Emotionaler Kontext und gewünschter Ton
- Beispiele – 2–3 konkrete Beispieltexte
- Anti-Patterns – Häufige falsche Verwendungen
- Verknüpfung – Verlinkung zur zugehörigen Design-Komponente
Integration in Design Systems
Eine Content Pattern Library ist am wirkungsvollsten, wenn sie direkt mit dem Design System verknüpft ist. In Figma bedeutet das: Jede UI-Komponente enthält eine Annotation mit dem zugehörigen Content Pattern. In Storybook kann der Content-Pattern-Name als Story-Prop dokumentiert werden.
Ziel ist, dass Entwickler, die eine Komponente bauen, direkt auf die Textvorgaben zugreifen können, ohne die UX Writerin fragen zu müssen.
Beispiele
Pattern: Lösch-Bestätigung
- Kontext: Nutzer will ein Objekt permanent löschen
- Struktur: [Objekt-Name] + Konsequenz + primärer Löschen-Button + Abbrechen-Button
- Ton: Sachlich, kein Humor, klar über Irreversibilität
- Constraints: Titel max. 50 Zeichen, keine Entschuldigungen
- Beispiel:
- Titel: „[Projektname] löschen?" - Body: „Diese Aktion kann nicht rückgängig gemacht werden." - Primär-Button: „Endgültig löschen" - Sekundär-Button: „Abbrechen"
- Anti-Pattern: „Achtung! Wenn Sie das Projekt löschen, sind alle Daten unwiederbringlich verloren. Sind Sie absolut sicher?"
Pattern: Leerer Zustand (erstmalig)
- Kontext: Nutzer hat noch keine Inhalte erstellt
- Struktur: Kurze Erklärung + CTA
- Ton: Motivierend, einladend
- Constraints: Erklärung max. 2 Sätze, CTA max. 4 Wörter
- Beispiel: „Hier erscheinen deine Projekte. Erstelle jetzt dein erstes." [Projekt erstellen]
- Anti-Pattern: „Keine Daten vorhanden."
In der Praxis
Wer pflegt die Content Pattern Library?
Die Pflege liegt idealerweise beim UX-Writing-Team in enger Abstimmung mit dem Design-System-Team. In kleinen Teams ohne dedizierte UX Writer kann ein Product Designer oder Product Manager diese Rolle übernehmen.
Governance-Modell:
- Neue Patterns: Proposal-Prozess mit Review durch UX Writing + Design
- Aktualisierungen: Mindestens quartalsweise Review
- Deprecation: Alte Patterns mit Hinweis auf Nachfolge-Pattern, nie einfach löschen
Content Patterns vs. UX-Style-Guide
Beide Dokumente sind Teil eines Content-Design-Systems, erfüllen aber unterschiedliche Funktionen:
- Style Guide: Regeln und Prinzipien (Wie schreiben wir? Welche Wörter benutzen wir?)
- Content Pattern Library: Konkrete Textlösungen für spezifische UI-Situationen (Was schreiben wir hier genau?)
Der Style Guide beantwortet „Wie?", die Pattern Library beantwortet „Was?".
Skalierbarkeit
Content Pattern Libraries skalieren besonders gut in Unternehmen mit:
- Mehreren Produktteams, die dasselbe Design System nutzen
- Mehrsprachigen Produkten (Patterns können pro Sprache lokalisiert werden)
- Hoher Mitarbeiterfluktuation (neues Team-Mitglied findet sofort fertige Texte)
Vergleich & Abgrenzung
Content Pattern Library vs. Komponentenbibliothek: Eine Komponentenbibliothek (z. B. Figma-Bibliothek) enthält visuelle UI-Bausteine. Eine Content Pattern Library enthält die textlichen Regeln und Beispiele für diese Bausteine. Beide zusammen bilden ein vollständiges Design System.
Content Pattern Library vs. Boilerplate-Texte: Boilerplate-Texte sind fix und werden direkt kopiert. Content Patterns sind Regeln und Strukturen mit Beispielen – Texte werden angepasst, nicht blind kopiert.
Content Pattern Library vs. Glossar: Ein Glossar definiert Begriffe und Terminologie. Eine Pattern Library definiert Text-Strukturen für bestimmte UI-Situationen.
Häufige Fragen (FAQ)
Wann lohnt sich der Aufwand einer Content Pattern Library? Ab etwa 3–5 UX Writern oder wenn mehrere Teams am selben Design System arbeiten. Kleinere Teams profitieren von einem schlanken Style Guide; vollständige Pattern Libraries sind ab mittlerer Produktgröße sinnvoll.
Wie verhindere ich, dass die Library veraltet? Quartalsweise Review; Ownership klar zuweisen; Prozess für Team-Feedback einrichten. Eine veraltete Pattern Library ist schlimmer als keine – sie führt zu Fehlern.
Kann ich eine Content Pattern Library in Figma dokumentieren? Ja – über Anmerkungen (Annotations), beschreibende Component Properties oder separate Dokumentationsseiten. Einige Teams nutzen auch Notion oder Confluence als ergänzende Dokumentation.
Muss jedes Design-System eine Content Pattern Library haben? Nein, aber jedes reife Design System profitiert davon. Der Einstieg kann klein sein: Zunächst nur die häufigsten Fehlertypen und Empty States dokumentieren.
Verwandte Einträge
- UX-Style-Guide
- Content-First Design
- Content Design Prozess
- Fehlertext-Design
- Leerer Zustand (Empty State)
Weiterführend
- Kholmatova, Alla: Design Systems, Smashing Magazine, 2017
- Frost, Brad: Atomic Design, Bradfrost.com, 2016 (frei verfügbar)
- Tran, Dan / Fessenden, Therese: „Design Systems 101", Nielsen Norman Group, 2021
- GOV.UK Design System – Writing for User Interfaces, design-system.service.gov.uk, 2022
