Warum jedes gute WordPress-Theme ein Designsystem braucht


Wenn du schon ein paar Jahre mit WordPress arbeitest, kennst du das vielleicht:
Du fängst mit einem Theme an, bist anfangs zufrieden – und ein Jahr später stellst du fest, dass du für jede Kleinigkeit neue CSS-Schnipsel brauchst. Also wechselst du das Theme.
Beim zweiten Wechsel merkst du: Jetzt stimmen deine Farben nicht mehr, das Logo sitzt zu hoch, und irgendetwas ist mit den Buttons anders.

Ich hab das durchgespielt. Mehrmals.

Am Anfang habe ich mit klassischen, statischen Themes gearbeitet. Dann kam Divi – großartig in Sachen Flexibilität, aber nach ein paar Jahren wusste ich selbst nicht mehr, wo welche Einstellung eigentlich herkam.
Danach GeneratePress: schlanker, schneller, besser strukturiert. Aber auch da: vieles lag noch in CSS-Dateien, vieles war visuell anpassbar, aber nicht systematisch gedacht.

Später kamen Block-Themes und Frameworks wie Kadence. Sie fühlten sich moderner an, aber irgendwie war es immer noch Flickwerk: Design, Farben, Layouts – alles verteilt, nie wirklich zentral steuerbar.

Und dann kam der Moment, an dem ich mir dachte:

Es kann doch nicht sein, dass jede Website, die ich baue, ihr eigenes Mini-Universum hat.

Ich wollte ein Designsystem, kein Sammelsurium.


Vom Theme zum System: ein Perspektivwechsel

Was ist der Unterschied zwischen einem „Theme“ und einem „Designsystem“?

Ein Theme liefert ein Aussehen.
Ein Designsystem liefert Struktur.

Es legt fest, wie Dinge gestaltet werden – nicht was gerade hübsch aussieht.
Und genau hier liegt die Stärke der modernen WordPress-Architektur mit Full Site Editing (FSE) und der Datei theme.json:
Sie zwingt dich fast dazu, in Systemen zu denken.


Der Schlüssel: theme.json

Die theme.json ist heute das Herz jedes modernen Themes.
Hier definierst du nicht nur Farben, sondern ganze semantische Ebenen deines Designs.

Ein Auszug aus meiner Grundstruktur:

 
"color": { "palette": [ { "name": "Primary", "slug": "primary", "color": "#ff6600" }, { "name": "Foreground", "slug": "foreground", "color": "#111111" }, { "name": "Background", "slug": "background", "color": "#ffffff" } ] }

Früher hätte ich dieselben Farben in einer CSS-Datei, in Divi-Optionen und vielleicht noch in einem Plugin gepflegt.
Heute definiere ich sie einmal – und sie gelten überall.

Wenn ich die Primärfarbe ändere, ändert sich automatisch die Farbe aller Buttons, Links und Icons, die currentColor verwenden.
Ich ändere also den Stilgedanken, nicht mehr nur die Optik.


Warum Komplexität nichts Schlechtes ist

Ich weiß noch, wie ich am Anfang mit FSE gekämpft habe.
Alles fühlte sich neu an – Blöcke, Templates, Parts, Styles.
Aber irgendwann kippte der Punkt:
Ich merkte, dass diese „Komplexität“ eigentlich Ordnung ist.

Früher musste ich Designentscheidungen in fünf Dateien verstreut pflegen.
Heute liegt fast alles an einem Ort:
theme.json beschreibt meine Logik, nicht mein Chaos.

Wenn du das Prinzip einmal verstanden hast, arbeitest du nicht mehr am Theme, sondern am System dahinter.


Farben denken wie Beziehungen

Der wichtigste Schritt war für mich, Farben nicht mehr als „Farben“, sondern als Beziehungen zu verstehen.

Es gibt:

  • eine Primärfarbe,

  • helle und dunkle Varianten davon,

  • und eine neutrale Palette aus Grautönen (100–900), die immer funktioniert.

Das sieht in der theme.json so aus:

 
{ "name": "Primary Dark", "slug": "primary-dark", "color": "#cc5200" }, { "name": "Neutral 700", "slug": "neutral-700", "color": "#444444" }

Wechsle ich die Primärfarbe – z. B. von Orange zu Purple – bleibt der Rest konsistent.
Weil sich das System nicht ändert, nur die Variable.

Diese Denke hat mein Verhältnis zu Design völlig verändert.
Ich suche nicht mehr nach Farben, die „passen“,
sondern nach Farben, die sich in ein Verhältnis einfügen.


Theme-unabhängige Assets

Das zweite große Aha-Erlebnis war das Thema Assets.
Ich hatte früher Logos in jedem Theme-Ordner doppelt, Fonts in jedem Child-Theme und Icons irgendwo in Uploads.

Bis ich verstanden habe:
Das gehört alles nicht ins Theme.

Heute liegen meine Dateien unter

 
/wp-content/assets/ /logos/ /fonts/ /icons/

So bleiben sie unabhängig vom Theme und sind für alle Projekte nutzbar.
Ein Update oder Theme-Wechsel zerstört nichts mehr.

Und genau das ist für mich der Kern eines guten Systems:

Wenn du etwas änderst, darf nichts anderes ungewollt mit umfallen.


Der Stylecheck – mein persönliches Prüfwerkzeug

Mit der Zeit habe ich mir eine eigene Seite angelegt: /stylecheck/.
Darauf liegen alle Grundelemente: Überschriften, Absätze, Listen, Zitate, Buttons, Tabellen, Icons, Bilder.

Jedes Mal, wenn ich etwas am Theme ändere, rufe ich diese Seite auf.
Ich sehe sofort, ob Abstände, Farben und Typografie noch harmonieren.

Es ist eine kleine, aber unglaublich effektive Routine – fast wie ein juristischer Querverweis:
Ich überprüfe nicht den Einzelfall, sondern das System dahinter.


Warum ich heute kaum noch CSS schreibe

Das klingt fast ketzerisch, aber:
Ich schreibe nur noch CSS, wenn ich wirklich muss.

Früher war CSS mein Werkzeugkasten – heute ist es mein Notizbuch.
Der Großteil der Gestaltung passiert direkt über das Designsystem und theme.json.

Das ist nicht weniger kreativ – es ist präziser.
Ich definiere Designprinzipien, nicht Pixelpositionen.


FSE als Werkzeug für langfristige Ordnung

Viele scheuen FSE, weil es „zu technisch“ wirkt.
Ich sehe es genau andersherum:
FSE ist die konsequenteste Vereinfachung, die WordPress je eingeführt hat.

Einmal sauber gedacht, ist alles miteinander verknüpft:
Farben, Typografie, Abstände, Layouts, Blöcke – alles folgt einer inneren Logik.

Und genau das liebe ich an dieser Arbeitsweise.
Ich kann mit einem Design in Orange beginnen und Wochen später dasselbe Theme auf Lila oder Blau umstellen – ohne einen Stilbruch.


Mein persönliches Fazit

Ich habe mich mit Themes herumgequält.
Ich habe mich durch Divi geklickt, CSS-Dateien durchwühlt und zahllose Einstellungen doppelt gepflegt.
Aber ich bin froh, dass ich das alles hinter mir habe.

Heute ist mein Ansatz klar:
Ich denke vom System her, nicht vom Theme.
Ich will keine „schöne Seite“ bauen, sondern ein robustes Gestaltungsprinzip, das auch in fünf Jahren noch funktioniert.

Ein Theme ist vergänglich.
Ein Designsystem ist nachhaltig.

Und genau das ist der Grund, warum ich meine Arbeit an ibp.Teams und anderen Projekten so liebe:
Weil ich hier das, was ich gelernt habe, endlich in saubere Strukturen übersetzen kann.


Weiterführend

➡️ In Teil 2 geht es um den Aufbau eines modularen Farb- und Typografiesystems in der theme.json.
➡️ Auf ibp.Teams zeige ich, wie dieses Prinzip in der Praxis aussieht – mit echten Beispielen aus unseren Themes.

https://teams.ibp.one/info/ibp-designsystem/


Ebenfalls lesenswert

  • Claude Code mit n8n verbinden: Der schnellste Guide für KI-gesteuerte Automatisierungen und MCP-Workflows

    Claude Code mit n8n verbinden: Der schnellste Guide für KI-gesteuerte Automatisierungen und MCP-Workflows

    Praxisleitfaden zur Verbindung von Claude Code und n8n via MCP. Erfahren Sie, wie agentische KI die Workflow-Erstellung beschleunigt und Risiken kontrolliert werden.

    Weiterlesen

  • Portainer: Docker- und Kubernetes-Container einfach verwalten und steuern

    Portainer: Docker- und Kubernetes-Container einfach verwalten und steuern

    Erfahre, wie Portainer das Management von Docker- und Kubernetes-Containern vereinfacht, die Sicherheit durch RBAC erhöht und die IT-Governance im Betrieb stärkt.

    Weiterlesen

  • Docker einfach erklärt: Was es ist, wofür man es braucht und wie man es nutzt

    Docker einfach erklärt: Was es ist, wofür man es braucht und wie man es nutzt

    Was ist Docker? Erfahre alles über Container-Technologie, Vorteile für die IT-Infrastruktur.

    Weiterlesen