Service Design im Unternehmen verankern: Reifegrad-Modell, Teamstruktur & ROI

Die meisten Unternehmen behandeln Service Design als Projekt: Ein Team durchläuft einen Double Diamond, liefert ein Ergebnis, und danach kehrt die Organisation zum Tagesgeschäft zurück. Das Ergebnis mag gut sein — aber die Fähigkeit, es entstehen zu lassen, verschwindet mit dem Projektende.

Die Zahlen zeigen, warum das teuer ist. McKinsey untersuchte über fünf Jahre 300 börsennotierte Unternehmen und entwickelte den McKinsey Design Index (MDI): Unternehmen im obersten Quartil erzielten 32 Prozentpunkte mehr Umsatzwachstum und 56 Prozentpunkte höhere Aktionärsrendite als der Branchendurchschnitt [1]. Aber — und das ist der entscheidende Punkt — diese Unternehmen hatten Design nicht als Projekt behandelt, sondern als organisatorische Fähigkeit verankert. Diese Unternehmen hatten Top-Level-Metriken für Design, cross-funktionale Teams und kontinuierliche Nutzerforschung.

Das Service Design Network (SDN) kommt von der anderen Seite zum gleichen Schluss: In ihrer Untersuchung zu organisatorischen Herausforderungen im Service Design berichten Praktikerinnen und Praktiker, dass 70 % der Probleme in SD-Projekten organisatorischer Natur sind — nicht kundenbezogen [2]. Es fehlt nicht an Methoden oder Erkenntnissen, sondern an Mandat, Budget, Zugang zu Stakeholdern und Einbettung in Entscheidungsprozesse. Eine Praktikerin berichtet, dass sie 80 % ihrer Arbeitszeit für internes Stakeholder-Management aufwendet statt für die eigentliche Designarbeit [2].

Die Frage ist also nicht, ob Service Design wirkt. Die Frage ist: Wie verankerst du es so in deiner Organisation, dass es über einzelne Projekte hinaus wirkt? Dieser Artikel liefert dafür einen vollständigen Rahmen: ein 5-Stufen-Reifegrad-Modell, drei Teamstrukturen im Vergleich, ein ROI-Framework, das mit dem Reifegrad wächst, und die sechs häufigsten Fehler, die Unternehmen bei der Verankerung machen.

Das Service Design Reifegrad-Modell

Reifegrad-Modelle sind im Englischen unter “Service Design Maturity Models” verbreitet — im deutschsprachigen Raum gibt es dazu praktisch keine Quelle. Das folgende Modell basiert auf der Arbeit des SDN und der Koos Service Design Agency [3], erweitert um die fünf Dimensionen des InVision Design Maturity Reports [5] und die praktischen Erfahrungen aus Stickdorn et al. (2018) [4].

Jede Stufe beschreibt, wie tief Service Design in die Organisation eingedrungen ist — nicht, wie viele Projekte durchgeführt wurden. Ein Unternehmen auf Stufe 3 mit zehn Projekten ist weiter als eines auf Stufe 1 mit dreißig.

Stufe 1: Erkunden (Explore)

Service Design existiert als einzelne Initiative. Ein Team oder eine Einzelperson hat das Thema entdeckt, erste Workshops durchgeführt oder einen externen Dienstleister beauftragt. Es gibt kein dediziertes Budget, keinen formalen Prozess und keine Messgrößen. Das Ergebnis hängt von der Energie einzelner Personen ab.

Typisches Bild: Eine Produktmanagerin bei einem Versicherer hat auf einer Konferenz von Customer Journey Mapping gehört und probiert es im eigenen Projekt aus. Die Ergebnisse sind gut, aber niemand außerhalb ihres Teams weiß davon. Es gibt keine Dokumentation, keinen Erfahrungstransfer und kein Budget für ein zweites Projekt.

Selbsttest: Wenn die Person, die SD vorantreibt, das Unternehmen verlässt — verschwindet dann auch Service Design?

Stufe 2: Beweisen (Prove)

Erste Pilotprojekte liefern messbare Ergebnisse. Das Management wird aufmerksam. Es gibt 1-3 interne Champions, die Service Design aktiv propagieren. Erste Budgets werden freigegeben — aber projektgebunden, nicht dauerhaft. Der Nachweis läuft über Einzelerfolge: “Wir haben mit Journey Mapping die Onboarding-Dauer um 40 % reduziert.”

Typisches Bild: Der Vorstand eines Automobilzulieferers genehmigt nach einem erfolgreichen Pilotprojekt im After-Sales-Bereich ein zweites SD-Projekt — diesmal für das Händler-Onboarding. Aber: Jedes Projekt muss einzeln genehmigt werden.

Selbsttest: Gibt es messbare Ergebnisse aus mindestens einem SD-Projekt, die du dem Management zeigen kannst?

Stufe 3: Skalieren (Scale)

Service Design wird über mehrere Projekte und Geschäftsbereiche hinweg angewendet. Es gibt ein dediziertes Budget (nicht mehr projektgebunden), formale Prozesse und erste Standards. Ein Team oder eine Rolle ist explizit für SD verantwortlich. Die Organisation beginnt, in SD-Ausbildung zu investieren.

Typisches Bild: Eine Bank richtet ein Service-Design-Team von drei Personen ein, das interne Projekte begleitet. Es gibt Templates für Journey Maps und Service Blueprints, einen standardisierten Workshop-Ablauf und einen Katalog abgeschlossener Projekte mit dokumentierten Ergebnissen.

Selbsttest: Gibt es einen formalen Prozess, über den Geschäftsbereiche Service-Design-Unterstützung anfordern können?

Stufe 4: Integrieren (Integrate)

Service Design ist in die Geschäftsprozesse eingebettet: Neue Services durchlaufen einen SD-Prozess als Standard (nicht als Ausnahme). Cross-funktionale Teams arbeiten mit SD-Methoden. Entscheidungen werden auf Basis von Nutzerforschung getroffen, nicht nur auf Basis von Business Cases. Metriken existieren auf Portfolio-Ebene, nicht nur auf Projektebene.

Typisches Bild: Ein Telekommunikationsunternehmen hat Service Design als festen Bestandteil in die Produktentwicklung integriert. Jede neue Tarifstruktur durchläuft eine Journey-Mapping-Phase, jeder Kundenkanal hat ein aktuelles Service Blueprint. Der Chief Customer Officer berichtet quartalsweise über SD-getriebene Metriken.

Selbsttest: Würde ein neuer Service ohne SD-Prozess als Ausnahme gelten — oder als Normalfall?

Stufe 5: Durchdringen (Thrive)

Service Design ist keine Abteilung mehr, sondern organisatorische Kultur. Birgit Mager, weltweit erste Professorin für Service Design, beschreibt dieses Zielbild als den Moment, in dem SD aufhört, eine separate Aktivität zu sein, und zur Selbstverständlichkeit wird [6]. Die Sprache des Unternehmens ist kundenzentrisch. Pieter Zwart, CEO von Coolblue, formulierte es so: “Wir sind eine Customer-Journey-Agentur, die zufällig Elektronikartikel verkauft” [3]. Auf dieser Stufe braucht es kein separates SD-Team mehr, weil die Denkweise in jeder Funktion verankert ist.

Typisches Bild: Wenn eine Führungskraft in der Vorstandsrunde fragt: “Was sagt die Journey Map dazu?” — und das eine normale Frage ist, kein exotischer Einwurf.

Selbsttest: Wird “Wie erlebt der Kunde das?” in Entscheidungsrunden genauso selbstverständlich gefragt wie “Was kostet das?”

Capital One unter Jamin Hegeman ist eines der am besten dokumentierten Beispiele für Stufe 5: Über neun Jahre wurden mehr als 1.000 Mitarbeitende in SD-Methoden ausgebildet, Journey Maps wurden zur gemeinsamen Sprache aller Funktionen, und das Unternehmen transformierte ganze Geschäftseinheiten mit SD-Denkweise [7].

Wichtig: Diese Stufen sind nicht linear. Einzelne Geschäftsbereiche können auf unterschiedlichen Stufen stehen. Und Rückschritte passieren — zum Beispiel, wenn ein Executive Sponsor wechselt und das Thema seinen Rückhalt verliert.

3 Teammodelle im Vergleich

Sobald Service Design über einzelne Projekte hinauswächst (ab Stufe 2-3), stellt sich die strukturelle Frage: Wo sitzt das SD-Team in der Organisation? Stickdorn et al. (2018) widmen diesem Thema ein eigenes Kapitel und identifizieren drei Grundmodelle [4].

Zentrales Team (Center of Excellence)

Ein dediziertes Service-Design-Team, das alle SD-Aktivitäten bündelt. Geschäftsbereiche “buchen” das Team für Projekte.

Dimension	Bewertung
Vorteile	Konsistente Methoden und Standards; Wissenstransfer zwischen Projekten; kritische Masse an Expertise
Nachteile	Wird zum Engpass bei hoher Nachfrage; Distanz zu Geschäftsbereichen; kann als “Elfenbeinturm” wahrgenommen werden
Passt zu	Stufe 2-3; Organisationen, die SD gerade erst aufbauen und Konsistenz brauchen

Eingebettete Designer (Embedded/Federated)

SD-Praktikerinnen und -Praktiker sitzen direkt in den Produkt- oder Geschäftsbereichsteams. Es gibt kein zentrales SD-Team.

Dimension	Bewertung
Vorteile	Maximale Nähe zum Geschäft; schnelle Iteration; tiefes Domänenwissen
Nachteile	Inkonsistente Praktiken; Isolation der Designer; kein systematischer Wissensaustausch
Passt zu	Stufe 3-4; Organisationen mit starken Geschäftsbereichen und hoher Autonomie

Hybrid-Modell

Ein zentrales CoE setzt Standards, entwickelt Methoden weiter und bildet aus. Gleichzeitig sitzen eingebettete Designer in den Geschäftsbereichen, die das Tagesgeschäft begleiten.

Dimension	Bewertung
Vorteile	Konsistenz UND Geschäftsnähe; Wissensaustausch über die Community of Practice; Skalierbarkeit
Nachteile	Matrix-Komplexität; doppelte Berichtslinien; erfordert reife Governance
Passt zu	Stufe 4-5; große Organisationen mit mehreren Geschäftsbereichen

Praxisbeispiel: Stell dir eine Versicherung mit 12 Geschäftsbereichen vor (Kranken, Leben, Sach, Kfz usw.). Ein zentrales CoE von 4 Personen entwickelt den SD-Toolkit, trainiert neue Kolleginnen und Kollegen und pflegt die übergreifende Journey-Map-Bibliothek. In 6 der 12 Geschäftsbereiche sitzt jeweils ein eingebetteter Service Designer, der Projekte vor Ort begleitet. Die eingebetteten Designer treffen sich monatlich in einer Community of Practice, die das CoE moderiert. So entsteht Konsistenz ohne Zentralisierung — und Geschäftsnähe ohne Isolation.

Der InVision Design Maturity Report bestätigt dieses Muster: Unternehmen mit der höchsten Design-Reife nutzen überwiegend Hybrid-Modelle, während Einsteiger mit zentralen Teams beginnen [5].

Service Design intern verkaufen

Die SDN-Forschung zeigt ein ernüchterndes Bild: Service Designer berichten, dass sie dreimal mehr Zeit für Stakeholder-Engagement aufwenden als geplant [2]. Internes Verkaufen ist kein Nebenaspekt — es ist die Hälfte der Arbeit. Fünf Strategien, die sich in der Praxis bewährt haben:

1. Starte mit Quick Wins

Such dir ein konkretes Problem, das sichtbar ist, überschaubar und in 4-6 Wochen lösbar. Ein Onboarding-Prozess, der Kunden verliert. Ein internes Formular, das jeder hasst. Ein Kanal-Wechsel, bei dem Informationen verloren gehen. Löse es mit SD-Methoden, miss das Ergebnis, kommuniziere es breit. Der erste Beweis zählt mehr als jede Strategie-Präsentation.

2. Sprich die Sprache des Managements

“Empathie”, “Nutzerzentriertheit” und “Co-Kreation” sind SD-Fachbegriffe, die im Vorstand nicht verfangen. Übersetze: “Wir können die Onboarding-Dauer um 40 % senken” (messbar), “Wir reduzieren Supportanfragen um ein Drittel” (kostenwirksam), “Unsere Churn-Rate sinkt von 18 % auf 12 %” (umsatzrelevant). McKinsey fand, dass Unternehmen mit Top-Level-Design-Metriken — also Designkennzahlen, die im Vorstand besprochen werden — signifikant bessere Finanzergebnisse erzielen [1].

3. Nutze Journey Mapping als Trojanisches Pferd

Eine Customer Journey Map ist das zugänglichste SD-Werkzeug: visuell, sofort verständlich, und sie macht Silos sichtbar, ohne sie beim Namen zu nennen. Lade Stakeholder ein, ihre Perspektive auf die Journey beizutragen. Wer einmal gesehen hat, wie sein Bereich aus Kundensicht aussieht, fragt von selbst nach mehr.

4. Baue interne Champions auf

Ein einzelner SD-Evangelist reicht nicht. Du brauchst Verbündete in jedem Geschäftsbereich — Personen, die SD nicht als Methode, sondern als Denkweise verstanden haben und in ihrem Bereich propagieren. Identifiziere Kolleginnen und Kollegen, die ohnehin kundennah denken, und gib ihnen Werkzeuge und Erfolgsgeschichten an die Hand.

5. Kombiniere Top-down und Bottom-up

Bottom-up allein erzeugt Graswurzel-Begeisterung, aber keine Ressourcen. Top-down allein erzeugt ein Mandat, das niemand lebt. Du brauchst beides: einen Executive Sponsor, der Budget, Zugang und Sichtbarkeit gibt — und ein Netzwerk aus Praktikern, die die tägliche Arbeit verändern. Stickdorn et al. (2018) betonen: “Service Design needs organizational backing that goes beyond a single project” [4].

ROI messen: Was auf welcher Stufe?

Einer der häufigsten Fehler bei der SD-Verankerung: zu früh den “ROI von Service Design” berechnen wollen. Auf Stufe 1 gibt es keine Baseline, auf Stufe 2 sind die Stichproben zu klein. ROI-Messung muss mit dem Reifegrad wachsen.

Stufe 1-2: Projekt-Level

Auf den frühen Stufen zählst du, was sich direkt messen lässt:

• Kundenzufriedenheit vorher/nachher (NPS, CSAT für den spezifischen Service)
• Prozesseffizienz (Bearbeitungszeit, Anzahl der Übergaben, Fehlerquote)
• Time-to-Market (Dauer von der Idee bis zum Live-Service)
• Supportanfragen (Reduktion nach Service-Redesign)

Versuche nicht, einen finanziellen ROI zu berechnen — du hast weder die Baseline noch die Zuordnung. Dokumentiere stattdessen Vorher-Nachher-Vergleiche pro Projekt. Ein Beispiel: Ein Versicherungsunternehmen misst vor dem SD-Pilotprojekt, dass die durchschnittliche Schadensbearbeitungszeit 14 Tage beträgt und der NPS für den Schadenprozess bei -5 liegt. Nach dem Redesign des Prozesses mit Service Blueprint und Journey Mapping sinkt die Bearbeitungszeit auf 8 Tage, der NPS steigt auf +22. Das ist kein ROI — aber ein Beweis, der das nächste Projekt finanziert.

Stufe 3: Portfolio-Level

Ab Stufe 3 hast du genug Datenpunkte, um über einzelne Projekte hinaus zu aggregieren:

• Anteil der Services, die SD-Prozess durchlaufen haben (Adoption-Rate)
• Aggregierter NPS-Anstieg über alle SD-Projekte
• Kostenvermeidung durch frühe Fehlererkennung (Probleme, die im Prototyping-Stadium statt nach dem Launch entdeckt wurden)
• Mitarbeiterzufriedenheit in SD-begleiteten Teams vs. Vergleichsgruppe

Hier wird der RODI-Ansatz (Return on Design Investment) erstmals anwendbar: (Nutzen - Kosten) / Kosten. Der Nutzen umfasst sowohl direkte Einsparungen (Prozessverkürzung, Fehlerreduktion) als auch Opportunitätsgewinne (schnellere Markteinführung, höhere Kundenbindung).

Stufe 4-5: Business-Level

Auf den reifen Stufen wird SD-Impact auf Geschäftsebene sichtbar:

• Umsatzwachstum durch SD-designte Services (Attribution über A/B-Tests oder Kohortenvergleich)
• Customer Lifetime Value (CLV-Veränderung in SD-bearbeiteten Segmenten)
• Employee Experience (Fluktuation in SD-eingebetteten Teams vs. Vergleichsgruppe)
• Innovationsgeschwindigkeit (Time-to-Market als organisatorische Metrik, nicht als Projektmetrik)

McKinseys MDI-Methodik zeigt: Auf dieser Stufe korreliert Design-Reife mit Finanzergebnissen auf Unternehmensebene — nicht mehr auf Projektebene [1]. Der InVision Report bestätigt: Unternehmen auf der höchsten Design-Reife-Stufe erzielen messbar höhere Umsatzwachstumsraten als ihre Wettbewerber [5].

Praxis-Tipp: Bau das Mess-System auf, bevor du es brauchst. Wenn du auf Stufe 2 noch keine Baseline-Daten sammelst, hast du auf Stufe 3 nichts zum Vergleichen. Jedes SD-Projekt sollte mindestens eine Vorher-Messung dokumentieren.

6 typische Fehler bei der Verankerung

1. Die Abteilungsfalle

Service Design wird zur eigenen Abteilung mit eigenem P&L — und damit zum Silo. Die Ironie: SD soll Silos überwinden, wird aber selbst zu einem. Die Folge: Geschäftsbereiche delegieren “das Kundending” an die SD-Abteilung, statt es selbst zu verinnerlichen. Gegenmaßnahme: SD als Querschnittskompetenz positionieren, nicht als Organisationseinheit. Das CoE unterstützt, es ersetzt nicht.

2. Adoption statt Impact messen

“14 Teams haben dieses Jahr Journey Mapping gemacht” klingt nach Fortschritt — sagt aber nichts über Wirkung. Wenn alle Teams die Methode nutzen, aber kein einziger Service messbar besser geworden ist, hat Adoption ohne Impact stattgefunden. Gegenmaßnahme: Immer Outcome-Metriken neben Adoption-Metriken führen. Nicht “Wie viele Teams nutzen SD?”, sondern “Was hat SD bewirkt?“

3. Ohne Executive Sponsorship starten

Graswurzel-Begeisterung ist wichtig, aber allein nicht ausreichend. Ohne einen Sponsor auf C-Level oder Bereichsleiterebene fehlt es an Budget, Zugang zu strategischen Projekten und der Legitimation, Abteilungsgrenzen zu überschreiten. Die SDN-Forschung bestätigt: Organisatorische Barrieren — fehlende Ressourcen, fehlende Entscheidungskompetenz — sind die häufigsten Gründe, warum SD-Initiativen stagnieren [2]. Gegenmaßnahme: Einen Executive Sponsor gewinnen, bevor du skalierst. Auf Stufe 1-2 reicht ein Abteilungsleiter; ab Stufe 3 brauchst du C-Level-Rückhalt.

4. Kopieren statt adaptieren

Das SD-Modell eines Tech-Konzerns 1:1 auf einen Mittelständler übertragen funktioniert nicht. Die Organisationskultur, die Entscheidungswege und die verfügbaren Ressourcen sind fundamental verschieden. Ein Versicherer mit 5.000 Mitarbeitern und regulatorischen Anforderungen braucht ein anderes Verankerungsmodell als ein 200-Personen-SaaS-Unternehmen. Gegenmaßnahme: Die Prinzipien übernehmen, die Struktur adaptieren. Stufe für Stufe vorgehen, nicht alles auf einmal implementieren.

5. Methoden-Training ohne Projektanbindung

Teams werden in Journey Mapping, Blueprinting und Prototyping geschult — aber es gibt kein konkretes Projekt, in dem sie das Gelernte anwenden können. Nach sechs Monaten ist das Wissen verblasst. Stickdorn et al. (2018) dokumentieren dieses Muster explizit: Methodentraining ohne direkte Anwendung führt zu “SD-Tourismus” — Teams können über Methoden sprechen, aber nicht mit ihnen arbeiten [4]. Gegenmaßnahme: Jedes Training mit einem realen Projekt verknüpfen. Teilnehmende arbeiten während des Trainings an einem echten Service-Problem ihres Geschäftsbereichs.

6. Externe Abhängigkeit aufbauen

Externe Berater führen die SD-Projekte durch, liefern Ergebnisse und gehen. Das Unternehmen hat ein Ergebnis, aber keine Fähigkeit. Beim nächsten Projekt wird wieder extern beauftragt. Gegenmaßnahme: Externe Unterstützung als Befähigung einsetzen, nicht als Ersatz. Der Integrierte Service Entstehungs Prozess (iSEP) verfolgt genau diesen Ansatz: Externe begleiten die ersten Durchläufe und bauen parallel internes Know-how auf, sodass die Organisation den Prozess zunehmend selbst tragen kann.

Verwandte Konzepte

Die organisatorische Verankerung von Service Design steht nicht isoliert, sondern verbindet sich mit mehreren Kernkonzepten:

• Service Design: Der Grundlagenartikel — Definition, Prozess, Prinzipien und die Frage, wann SD sinnvoll ist. Dieser Artikel baut darauf auf.
• Service Blueprint: Das zentrale Werkzeug für die Backstage-Analyse. Auf Stufe 3-4 des Reifegradmodells wird Blueprinting zum Standard-Prozessschritt.
• Customer Journey Mapping: Das zugänglichste SD-Werkzeug — und das beste “Trojanische Pferd” für die interne Verbreitung (siehe Abschnitt “Intern verkaufen”).

In unserem Integrierten Service Entstehungs Prozess (iSEP) sind diese Methoden in einen kohärenten Rahmen eingebettet, der die organisatorische Verankerung von Anfang an mitdenkt: Nicht nur das Service-Ergebnis wird designt, sondern auch der Weg, wie die Organisation die Fähigkeit dauerhaft aufbaut.

Häufige Fragen

Braucht man ein eigenes Service Design Team?

Nicht zwingend — aber eine klare Zuständigkeit. Auf Stufe 1-2 genügen engagierte Einzelpersonen, die SD neben ihrer Hauptrolle vorantreiben. Ab Stufe 3 braucht es dedizierte Ressourcen, sei es als zentrales Team, als eingebettete Rolle oder als Hybrid. Entscheidend ist nicht die Organisationsform, sondern dass jemand für Standards, Wissenstransfer und Qualitätssicherung verantwortlich ist.

Wie lange dauert es, Service Design im Unternehmen zu verankern?

Von Stufe 1 zu Stufe 3 dauert es typischerweise 18-36 Monate — vorausgesetzt, es gibt Managementunterstützung und reale Projekte. Von Stufe 3 zu Stufe 5 kann es 3-5 Jahre dauern, weil es hier um Kulturveränderung geht, nicht um Methodeneinführung. Schneller ist nicht immer besser: Ein Unternehmen, das die Stufen überspringt, hat die Grundlagen nicht gelegt und fällt zurück.

Was kostet die Einführung von Service Design?

Die größten Kosten sind nicht externe Beratung oder Software, sondern interne Arbeitszeit: Interviews, Workshops, Prototyping, Stakeholder-Alignment. Für ein erstes Pilotprojekt (Stufe 1-2) rechne mit 3-5 Personen über 6-8 Wochen bei ca. 30-50 % Auslastung. Ab Stufe 3 kommen Kosten für dedizierte Rollen, Training-Programme und Tools hinzu. Stickdorn et al. (2018) empfehlen: “Start with a pilot project, not a company-wide transformation” [4].

Wer ist für Service Design verantwortlich?

Auf Stufe 1-2 oft eine engagierte Einzelperson in Produkt, Innovation oder Marketing. Ab Stufe 3 typischerweise ein dediziertes Team oder eine Rolle, die an einen Chief Customer Officer, Chief Experience Officer oder COO berichtet. Auf Stufe 5 ist die Frage obsolet — weil SD in jeder Funktion verankert ist. Entscheidend auf jeder Stufe: Der Verantwortliche braucht Zugang zu cross-funktionalen Projekten, nicht nur zum eigenen Bereich.

Quellenverzeichnis

[1] Sheppard, Benedict, Hugo Sarrazin, Garen Kouyoumjian und Tracy Doshi. “The Business Value of Design.” McKinsey Quarterly, Oktober 2018. URL: https://www.mckinsey.com/business-functions/mckinsey-design/our-insights/the-business-value-of-design

[2] Service Design Network. “Taming Organisational Challenges in Service Design.” SDN Community Knowledge. URL: https://www.service-design-network.org

[3] Koos Service Design. “Service Design Maturity Model: An Introduction.” Koos Blog. URL: https://www.koos.io/service-design-maturity-model

[4] Stickdorn, Marc, Markus Edgar Hormess, Adam Lawrence und Jakob Schneider. This Is Service Design Doing: Applying Service Design Thinking in the Real World. O’Reilly Media, 2018. ISBN: 9781491927186.

[5] InVision. The New Design Frontier: The widest survey of designers to date. InVision Design Maturity Report, 2019. URL: https://s3.amazonaws.com/www-assets.invisionapp.com/The-New-Design-Frontier-from-InVision.pdf

[6] Mager, Birgit. The Future of Service Design. TH-Köln, 2020. ISBN: 978-3-9818990-6-1.

[7] Hegeman, Jamin. “Service Design Leadership at Capital One.” Dokumentiert in: SDN Executive Leadership, Carnegie Mellon University, SMU. URL: https://jamin.org/experience/