July 29, 2025
Wie Sie den Business Case für ein Design System richtig aufziehen
Ein Design System steht auf Ihrer Wunschliste ganz oben?
Im Gespräch mit Oliver Stöcker
Inhaltsverzeichnis
Und eigentlich ist auch klar, warum: Es spart Zeit, sorgt für Konsistenz und bringt Ordnung in Design und Code. Ihr Produkt- oder Dev-Team würde davon direkt profitieren.
Aber: Die Entscheidung dafür treffen andere.
Und genau hier wird es schwierig.
Ein Satz wie „Wir brauchen ein Design System“ reicht oft nicht aus.
Denn die Frage, die Entscheider stellen, ist eine andere:
Was bringt es dem Unternehmen, ganz konkret?
Hier setzt dieser Artikel an.
Er zeigt Ihnen, wie Sie den Business Case für ein Design System so aufbauen, dass er verstanden und akzeptiert wird.
Sie erfahren:
- Welche Argumente auf Entscheider-Ebene funktionieren
- Wie Sie typische Einwände entkräften
- Welche Zahlen Sie vorbereiten sollten
Falls Sie gerade erst ins Thema einsteigen und mehr über Aufbau, Bestandteile oder Einsatzgebiete eines Design Systems erfahren möchten: Hier geht’s zum Grundlagen-Guide. Dort sprechen wir auch darüber, wann Sie welche Elemente eines Design Systems in Betracht ziehen sollten.
Weil Design System nicht gleich Design System ist: Worum geht es hier?
Design Systeme kommen in allerlei Formen und Ausmaßen: Vom kleinen UI-Kit in Figma bis zum vollständigen Satz von Regeln, der oft auch Code-Snippets in verschiedenen Programmiersprachen umfasst und öffentlich auf einer Website veröffentlicht wird – wie etwa bei Porsche.
Diese „vollständige” Variante stellt sicher, dass visuelle Regeln auch für Subunternehmer oder verschiedene Agenturen, die mit Porsche zusammenarbeiten, klar sind. Denn Marken-Konsistenz ist bei einem etablierten Image wie dem von Porsche enorm wichtig.
Für die meisten KMUs umfasst das Design System zumeist ein UI-Kit oder eine Component-Library in Figma. Genaugenommen ist das kein (vollständiges) Design System, wird aber trotzdem oft so genannt.
Für die KMUs geht es dabei weniger um das Alignment Externer, sondern darum, dass interne Design- und Entwicklungsprozesse durch die Definition wiederverwendbarer Designkomponenten effizienter und konsistenter werden.
Wie groß Ihr angedachtes Design System auch werden soll: Sie finden in diesem Artikel die nötigen Argumente für Ihren Business Case.
Warum Design Systeme ein Business-Thema sind
Viele Entscheidungsträger halten Design Systeme für ein reines UI-Thema.
Etwas, das zwischen Farben, Buttons und Komponenten in Figma stattfindet.
Was dabei oft übersehen wird: Mit der Struktur kommt auch Effizienz, Skalierbarkeit und eine bessere Zusammenarbeit im gesamten Produktteam.
Ein Design System ist höchstens auf den ersten Blick ein Designprojekt, denn es wirkt auf auch technischer, organisatorischer und wirtschaftlicher Ebene.
Vom Design-Problem zur Unternehmensinvestition
Zwei Buttons mit unterschiedlichem Padding. Drei leicht abweichende Components. Ein Formular, das in einem Produkt horizontal, im anderen vertikal strukturiert ist.
Auf den ersten Blick sind es kleine Dinge. Doch genau diese Details führen zu echten Kosten.
Entwickler*innen verlieren Zeit, weil sie Komponenten mehrfach aufsetzen oder anpassen müssen. Designer*innen bauen in Figma Dinge neu, die es eigentlich schon gibt. Und beim Übergang zwischen Design und Dev geht regelmäßig Kontext verloren – was zu Rückfragen, Nacharbeiten oder ungewollten Inkonsistenzen führt.
Auch neue Features ziehen sich unnötig in die Länge.
Warum?
Weil grundlegende UI-Entscheidungen wie Spacing und States jedes Mal aufs Neue verhandelt werden müssen.
Die Folge: Jedes Produktteam löst dieselben Probleme, aber auf unterschiedliche Weise.
Das bedeutet:
- Höherer Entwicklungsaufwand
- Unvorhersehbare Projektzeiten
- Eine UI, die von Plattform zu Plattform leicht anders funktioniert
Ein Design System unterbindet genau das.
Es gibt zentrale Regeln und wiederverwendbare Bausteine vor, wodurch der Initialaufwand sinkt, die Qualität steigt, und Teams mit- statt gegeneinander arbeiten.
Das spart nicht nur Aufwand, sondern schützt aktiv vor Skalierungsproblemen.
Ein Vorteil, den Entscheider*innen verstehen.
Ein Design System spart nicht nur Design-Zeit, sondern auch Produktzeit, Entwicklungszeit und Denkzeit.
Und genau deshalb gehört es auf den Tisch, wenn es um Investitionen geht.
Typische Einwände – und wie Sie sie entkräften
Wer ein Design System vorschlägt, bekommt selten sofort ein „Ja“.
Stattdessen: Rückfragen, Skepsis, manchmal ein Nicken mit anschließender Funkstille.
Das liegt nicht daran, dass die Idee schlecht ist.
Sondern daran, dass sie falsch verstanden wird.
Hier sind vier typische Einwände, die Sie kennen sollten – und wie Sie darauf reagieren können.
„Wir haben keine (Design-)Ressourcen dafür“
Das wohl häufigste Argument.
Und auch absolut verständlich, denn fast jedes Team ist überlastet.
Aber gerade dieser Einwand bietet eine gute Brücke.
Denn ein Design System sollte nicht als zusätzliches Projekt, sondern als Maßnahme zur Zeitersparnis gesehen werden.
Was Sie sagen können:
„Genau deshalb brauchen wir es. Weil wir jetzt schon zu viel Zeit mit Wiederholung und Abstimmung verlieren. Das System würde uns helfen, Features dauerhaft schneller umzusetzen.“
Noch besser: Zeigen Sie konkrete Beispiele, wie viel Zeit heute für manuelle UI-Fragestellungen draufgeht und wie das in Zukunft schneller ginge.
„Das hat keine Priorität“
Hier hilft Klartext: Ein Design System betrifft Design, aber es entlastet auch Entwicklung, Produktmanagement und QA.
Was Sie sagen können:
„Design liefert die Vorlage, aber gebaut, gepflegt und genutzt wird es von mehreren Disziplinen. Es geht nicht um Look & Feel, sondern um Wiederverwendung, technische Qualität und Produktgeschwindigkeit.“
Ein kleiner Perspektivwechsel reicht oft aus, um aus einem „Design-Ding“ ein Teamprojekt zu machen.
„Wir haben doch schon Komponenten“
Fast jedes Produktteam hat irgendeine Art von Komponenten-Repo.
Was Entscheidungsträger oft nicht wissen: Ein Design System ist mehr als das.
Was Sie sagen können:
„Ein Design System sorgt dafür, dass Design und Code synchronisiert sind – inklusive Dokumentation, Guidelines und Tokens. Erst dann wird es auch teamübergreifend von Devs, Designer*innen und PMs genutzt. Eine lose Komponenten-Sammlung ist ein Startpunkt, aber noch kein System.“
Tipp: Machen Sie sichtbar, wo aktuelle Komponenten abweichen, wie oft ähnliche Varianten gebaut wurden oder wo Dokumentation fehlt. Das macht das Problem greifbar.
„Das lohnt sich nur für große Unternehmen“
Ein verbreiteter Irrtum.
Denn gerade in kleineren oder mittleren Teams kann ein Design System mehr bewegen, weil Ressourcen knapper sind.
Was Sie sagen können:
„Wir bauen bereits wiederkehrende Elemente – aber ohne System. Mit einem kompakten, gut dokumentierten Setup hätten wir schnell einen Effekt. Es muss kein Mammutprojekt sein.“
Betonen Sie, dass man klein starten kann: mit einem MVP, den wichtigsten Komponenten, klaren Regeln. Und dann Schritt für Schritt wachsen.
Wenn Sie diese Einwände früh erkennen und aktiv adressieren, verwandeln Sie Widerstand in Gesprächsbereitschaft. Und aus einem „Vielleicht später“ wird ein „Zeigen Sie mal, wie das aussehen könnte“.
Die Elemente eines überzeugenden Business Case
Wenn Sie ein Design System vorschlagen, brauchen Sie Zahlen, Vergleiche und eine klare Story.
Der Business Case dient dabei als eine Art Entscheidungsvorlage für Ihre*n Vorgesetzte*n.
Und diese funktioniert am besten, wenn sie drei wichtige Fragen überzeugend beantwortet:
- Was kostet es?
- Was bringt es?
- Was passiert, wenn wir es nicht machen?
Hier sind die wichtigsten Elemente, die Ihr Case abdecken sollte – pragmatisch, konkret und anpassbar auf Ihre Organisation.
Ziele definieren
Starten Sie nicht mit dem System, sondern mit dem Problem.
Was genau soll das Design System für Ihr Unternehmen leisten?
Typische Ziele:
- Konsistentere UI über mehrere Produkte hinweg
- Schnellere Umsetzungszeit für neue Features
- Weniger Redundanz im Code
- Weniger Rückfragen zwischen Design und Entwicklung
Wichtig: Vermeiden Sie vage Begriffe wie „bessere Qualität“.
Formulieren Sie stattdessen so konkret wie möglich – z. B. „Reduktion von UI-Doppelentwicklungen um 30 %“.
Ist-Analyse
Ein Business Case überzeugt dann, wenn klar wird, wie teuer der Status quo ist.
Machen Sie sichtbar:
- Wie oft werden Komponenten doppelt gebaut?
- Wie lange dauert aktuell der Weg von Design zu Dev?
- Wie viele Designentscheidungen müssen regelmäßig neu getroffen werden?
- Wie viel Zeit geht durch fehlende Doku oder Nachfragen verloren?
Sie brauchen keine perfekten Zahlen – Schätzungen und kleine Audits reichen oft aus, um die Richtung zu zeigen.
Beispiel:
„Ein Button braucht im Schnitt 4 Stunden bis zur Übergabe und Implementierung. Bei 15 Buttons pro Release sind das 60 Stunden. Mit Systemkomponenten wären es 10.“
Kennzahlen & ROI-Logik
Jetzt wird’s greifbar: Was kostet das System – und was spart es ein?
Die meisten Kosten entstehen durch die Arbeitsstunden und den Fokus, den das System beim Setup einfordert.
Typische Posten, die in der Planung eines Design Systems auftauchen:
- Design-Zeit für Aufbau von Komponenten, Tokens und Guidelines
- Dev-Kapazitäten für die Erstellung und Dokumentation von Code-Komponenten
- Abstimmung mit Teams für Rollen, Naming, Nutzung und Governance
- Enablement: Schulungen, Onboardings, Dokumentation
Was das in Zahlen bedeutet? Das hängt vor allem vom Umfang des geplanten Systems, der Teamgröße und der bestehenden Design-Basis ab. Als Richtwert: Ein MVP-Setup mit 6–8 Kernkomponenten könnte 5 Personentage dauern. Für ein größeres System mit 25 Komponenten, sowohl bestehend aus einzelnen Atomen als auch ganzen Sektionen, könnten rund 2-3 Wochen Arbeit anfallen.
Aber wichtig ist: Es ist ein einmaliger Initialaufwand, der sich planbar staffeln lässt – z. B. über ein Quartal.
Ein Design System ist kein abstrakter Kostenblock, sondern eine Investition, die sich bei realistischem Einsatzszenario schnell amortisiert.
.jpg)
Stakeholder-Perspektiven: Wer braucht was – und wie überzeugen Sie?
Nicht alle Entscheider achten auf dieselben Dinge.
Ein CEO denkt in Zahlen und Wirkung.
Ein CTO fragt nach Skalierbarkeit und Codequalität.
Ein Produktteam will schneller liefern – ohne Frust im Sprint.
Deshalb:
Passen Sie Ihre Argumente an die Perspektive Ihrer Ansprechpartner*innen an.
Hier die wichtigsten Rollen – mit passenden Argumentationsansätzen:
Produktteams
Was sie brauchen: Planbarkeit, weniger Abstimmung, klare UX
Was Sie sagen können:
„Ein Design System reduziert Standard-Diskussionen im Sprint. Es liefert Muster, auf die sich alle verlassen können – ohne jedes Mal neue Entscheidungen treffen zu müssen. Das macht eure Arbeit schneller und die Features konsistenter.“
Entwickler*innen / Engineering Leads
Was sie brauchen: Wiederverwendbaren Code, weniger Dopplung, technische Qualität
Was Sie sagen können:
„Statt dieselbe Komponente fünfmal unterschiedlich zu bauen, nutzen wir definierte Bausteine mit klarer Zustandslogik. Das spart Zeit, reduziert Fehler und senkt langfristig den Wartungsaufwand.“
Designer*innen
Was sie brauchen: Schnelle Iteration, weniger Redundanz, klarere Designentscheidungen
Was Sie sagen können:
„Statt jedes Mal Buttons, Modals oder Forms anders zu bauen, greifen wir auf getestete Systemkomponenten zurück. Das beschleunigt Prototyping und gibt mehr Zeit für echte UX-Optimierung.“
CPO / Produktleitung
Was sie brauchen: Time-to-Market, Effizienz im Team, Fokus auf User Value
Was Sie sagen können:
„Wenn Standard-UI nicht mehr jedes Mal neu entschieden oder gebaut werden muss, haben Teams mehr Zeit fürs eigentliche Produkt. Das bringt Tempo in die Entwicklung – gerade bei wiederkehrenden Anforderungen.“
CEO / CFO
Was sie brauchen: Wirtschaftlichkeit, Markenstärke, strategischer Impact
Was Sie sagen können:
„Ein Design System amortisiert sich in wenigen Monaten – weil es Redundanzen reduziert, Teams entlastet und technische Schulden vermeidet. Gleichzeitig stärkt es das Markenerlebnis und verringert langfristige Wartungskosten.“
Je klarer Sie diesen Mehrwert pro Rolle zeigen, desto wahrscheinlicher ist es, dass Sie Zustimmung bekommen.
Denn jede Rolle muss sich im System wiederfinden – und den Nutzen erkennen.
Pilot-Projekte & Quick Wins
Sie müssen nicht gleich mit einem vollständigen System starten.
Bieten Sie an, mit einem Pilot-Team oder einem MVP-Set zu beginnen.
Das senkt die Einstiegshürde und gibt Ihnen früh Erfolge, mit denen Sie für den Ausbau des System argumentieren können.
Beispiel:
„Wir starten mit 6 Kernkomponenten in Figma und Storybook. Ziel: bis Release X durchgängig nutzen, Feedback einsammeln und Aufwand dokumentieren.“
Das zeigt, dass Sie Bedenken berücksichtigen und bereit sind, einen Beweis des Mehrwerts bei möglichst geringem anfänglichen Invest zu erbringen.
Fazit und Handlungsaufruf
Ein Design System ist mehr als ein Styleguide.
Und ein Business Case dafür ist mehr als ein paar nette Argumente.
Es geht darum, strukturiert zu zeigen, warum sich die Investition lohnt – für Ihr Team, für das Produkt und fürs Unternehmen.
Die wichtigsten Punkte auf einen Blick:
- Ein Design System ist die Infrastruktur für bessere, schnellere Produkte.
- Ein guter Business Case spricht die Sprache der Entscheider*innen: konkret, wirtschaftlich, zielorientiert.
- Argumentieren Sie mit Zahlen, Zeit und Risiken – nicht mit Ästhetik.
- Zeigen Sie, was der Status quo kostet und was Sie durch Systematik gewinnen.
- Starten Sie klein, aber durchdacht: Pilotprojekte und MVPs schaffen Vertrauen und messbare Ergebnisse.
Jetzt Ihren nächsten Schritte planen
Wenn Sie das Gefühl haben, „wir sollten das mal machen“, dann ist jetzt der richtige Moment.
Was Sie tun können:
- Machen Sie eine kleine UI-Inventur: Was wird oft wiederholt? Wo entstehen Reibungen?
- Notieren Sie konkrete Pain Points: Wie viel Zeit, Rückfragen oder Unklarheiten kosten sie?
- Skizzieren Sie ein MVP-System: 5–6 zentrale Komponenten reichen oft für den Anfang.
- Stimmen Sie sich mit Tech- und Design-Kolleg*innen ab: Wer hätte Kapazität? Wer bräuchte was?
- Bereiten Sie ein kurzes Decision-Memo vor: Ziele, Aufwand, Nutzen – ohne PowerPoint.
Und wenn Sie intern noch Überzeugungsarbeit leisten müssen:
Diesen Artikel können Sie gerne weiterleiten.
Er wurde genau dafür geschrieben.
Falls Sie noch Fragen haben oder auf der Suche nach Support sind: Gerne helfen wir Ihnen beim Design System Setup.
