WP Design System – WordPress Theme
WordPress setzt konsequent auf Full Site Editing (FSE) als zukunftsweisenden Standard. Um Projekte schneller und in höchster Qualität realisieren zu können, haben wir ein umfassendes Design-System entwickelt und öffentlich dokumentiert.
Projektzeitraum
Unsere Aufgabe
WordPress hat ab Version 5 einen grundlegenden Umbau hin zum Block Editor und später zum Site Editor vollzogen. Anfang 2024 erreichte das System eine Stabilität, die uns dazu veranlasste, unser bisher genutztes WordPress-Starter-Theme von Grund auf neu zu konzipieren und technisch vollständig neu aufzubauen.
Ziel war es, ein modernes Starter-Theme zu entwickeln, das alle WordPress-Funktionen der neuesten Generation nutzt und im Team auf Akzeptanz stößt. Technisch lag der Fokus insbesondere auf vollständiger Barrierefreiheit sowie auf der Konzeption aller Inhaltsmodule (Patterns) nach dem Purpose-First-Prinzip.
Unser erster grober Plan
Den ersten Entwurf stellte Jonas zu einem Zeitpunkt vor, als bei kulturbanause WordPress-Projekte noch überwiegend mit dem klassischen Theme-Ansatz und ACF-Modulen umgesetzt wurden. Ziel war es, ein System zu schaffen, das sowohl Design als auch Entwicklung enger miteinander verzahnt.
Konkret sollte eine Design-Datei bzw. Designbibliothek entstehen, die alle typischen Website-Komponenten abbildet. Ergänzend dazu war eine passende Frontend-Komponentenbibliothek geplant, in die sich ACF-Felder – oder alternativ Felder anderer CMS – möglichst einfach integrieren ließen.
Alle Komponenten („Pattern“) sollten nach dem Purpose-First-Prinzip konzipiert werden: Jedes Modul sollte einen klaren inhaltlichen Zweck erfüllen und nicht primär aus gestalterischen Gründen existieren. Zusätzlich war eine kalkulatorische Komponente vorgesehen, mit der sich der Projektaufwand anhand der Anzahl und Komplexität der eingesetzten Pattern vergleichsweise zuverlässig abschätzen lassen sollte.
Version 1 unserer Website-Module
Die erste Version des Systems bestand aus einer Adobe-XD-Datei mit bewusst niedrig aufgelösten (Lo-Fi) Modulen. Diese dienten vor allem dazu, in Kundenterminen schnell den grundlegenden Seitenaufbau und die Struktur zu skizzieren.
Parallel dazu lagen alle Komponenten als Plain HTML, CSS und JavaScript in PatternLab vor. Für die Zusammenarbeit mit externen Design-Agenturen wurde das System ausführlich erklärt und dokumentiert. Ziel war es, eine bessere Zuarbeit von nicht-technischen Design-Teams zu ermöglichen und die Lücke zwischen Gestaltung und Umsetzung zu verkleinern.
Kurswechsel: Fokus auf WordPress und Figma
Nach den ersten Projekten wurde deutlich, dass ein CMS-agnostischer Ansatz für unsere Arbeit wenig Mehrwert bot. Zum einen hatte der WordPress-Block-Editor inzwischen eine hohe Reife erreicht, zum anderen lag der Fokus unserer Inhouse-Entwicklung ohnehin klar auf WordPress.
Für andere CMS erstellte Frontend-Bibliotheken brachten meist projektspezifische Anforderungen mit sich, die durch unser bewusst schlank gehaltenes System nicht sinnvoll abgedeckt werden konnten. Die angestrebte Allgemeingültigkeit erwies sich damit als unnötige Einschränkung.
Wir entschieden uns daher für einen klaren Schnitt: Das gesamte System sollte direkt als WordPress-Pattern-Bibliothek aufgebaut werden – ergänzt um eine parallel gepflegte Figma-Library.
Aufbau eines barrierefreien WordPress-Starter-Themes
In den folgenden Monaten entstand ein WordPress-Parent-Theme mit einer umfangreichen Sammlung an Pattern. Um unseren Anforderungen an responsives Design und Barrierefreiheit gerecht zu werden, nutzten viele Komponenten zunächst noch Custom-CSS-Layouts, Container Queries und klassische Breakpoints.
Ergänzend dazu stellten wir in einem Child-Theme zentrale Funktionen für Sicherheit, Performance und Anpassbarkeit bereit. Diese erste Version war vollständig produktionsfähig und wurde erfolgreich in mehreren Kundenprojekten eingesetzt.
Code first, Design second
Ein zentrales Prinzip lautete: Alle WordPress-Pattern müssen deckungsgleich als Komponenten in Figma existieren. Nur so konnten wir konzeptionell in Figma starten und gleichzeitig sicherstellen, dass alles, was dort vorbereitet wurde, im Code bereits vorhanden war.
Da der manuelle Aufbau der Figma-Library zu aufwendig gewesen wäre, importierten wir den fertigen Code direkt aus dem Browser nach Figma und passten ihn dort an die bestehende Variablen-Struktur an. Mit der Zeit verlor die Figma-Datei jedoch an Bedeutung, da Layouts zunehmend direkt im WordPress-Editor im Browser erstellt werden konnten.
Praxiserfahrungen und Iterationen im Projektalltag
Obwohl die ersten Projekte qualitativ überzeugend umgesetzt wurden, zeigte sich im Projekt-Workflow, dass noch Reibungspunkte bestanden. Besonders störend waren individuelle CSS-Styles, die aufwendig überschrieben oder angepasst werden mussten.
Gleichzeitig entwickelte sich WordPress stark weiter: Features wie Grid-Layouts, Section Styles und teilweise synchronisierte Patterns reduzierten den Bedarf an Custom Code erheblich und verbesserten die Anpassbarkeit deutlich. In diesem Zuge überarbeiteten wir auch mehrfach unsere Typografie-, Spacing- und Farb-Systematik, um maximale Flexibilität bei gleichzeitig hoher Konsistenz zu erreichen.
Skalierung durch agentisches Coding
Dank agentischem Coding konnten wir das inzwischen sehr umfangreiche WordPress-Theme effizient weiterentwickeln. Wir integrierten strukturierte README-Dateien für AI-Agenten und nutzten KI-gestützte Prozesse zur Anpassung von Content-Outlines, Übersetzungs-Strings und der Kategorisierung der Pattern.
Sobald neue Pattern oder Funktionen hinzukommen, stellt eine Kombination aus Build-Prozess und AI-Agent sicher, dass die Qualität stimmt und alle Komponenten konsistent sowie regelkonform aufgebaut sind. Ohne diese agentische Unterstützung wären viele strukturelle Umbauten aus Kapazitätsgründen nicht realisierbar gewesen.
Vom Starter-Theme zum WordPress Design System
Mittlerweile haben wir das Theme in WP Design System umbenannt – denn es ist weit mehr als ein klassisches Starter-Theme. Alle Komponenten sind im Design, im Code sowie in Text- und Video-Dokumentationen vollständig beschrieben. Zahlreiche Design Tokens ermöglichen eine konsistente Erweiterung im Projektalltag.
Parent- und Child-Theme sind dabei strikt getrennt:
Im Parent befindet sich alles, was mit WordPress-Bordmitteln umsetzbar ist. Das Child-Theme bildet unseren Customization-Layer. Komplexere oder stark spezialisierte Komponenten ergänzen wir gezielt über Plugins.
Damit eignet sich das WP Design System sowohl für einfache, datenbankbasierte No-Code-Projekte als auch für komplexe, barrierefreie Anwendungen mit hohem Custom-Code-Anteil und vollständiger Versionierung.
