Service Design Methoden: Überblick, Auswahlhilfe & Tool-Kombinationen

Es gibt über 54 dokumentierte Service Design Methoden [1] — und die meisten Übersichten listen sie einfach auf. Was fehlt, ist eine Antwort auf die Frage, die sich jeder Praktiker stellt: Wann verwende ich welche Methode?

Stickdorn, Hormess, Lawrence und Schneider dokumentieren in This is Service Design Doing die bislang umfangreichste Methodensammlung für Service Design [1]. Sie ordnen die Methoden nach Projektphasen — aber sie liefern keine Entscheidungskriterien. Keine Matrix, die sagt: Bei diesem Problemtyp, dieser Teamgröße und diesem Zeitbudget brauchst du diese drei Methoden und nicht jene. Die Folge: Teams greifen zu den Methoden, die sie kennen, statt zu den Methoden, die passen.

Dieses Problem wird dadurch verschärft, dass die deutschsprachige Service-Design-Literatur eine ganze Methodentradition systematisch ignoriert. Werkzeuge wie das Ishikawa-Diagramm, der PDCA-Zyklus, das Kano-Modell und der Gemba Walk stammen aus dem Qualitätsmanagement — und sind für Service Design mindestens so relevant wie Journey Maps und Personas. Aber kein deutschsprachiges SERP-Ergebnis integriert beide Traditionen in eine gemeinsame Toolbox.

Dieser Artikel gibt dir beides: einen vollständigen Überblick über 40+ Methoden in 10 Kategorien und eine Auswahlmatrix, die dir sagt, wann du welche Methode einsetzt — mit konkreten Tool-Kombinationen für drei typische Projektszenarien.

Was sind Service Design Methoden?

Service Design Methoden sind strukturierte Vorgehensweisen, mit denen Teams Dienstleistungen analysieren, gestalten, testen und verbessern. Sie machen die unsichtbare Architektur eines Services sichtbar — die Touchpoints, Prozesse, Emotionen und Backstage-Systeme, die das Kundenerlebnis bestimmen.

Was Service Design Methoden von allgemeinen Kreativitäts- oder Managementmethoden unterscheidet, ist ihr Fokus auf drei Eigenschaften von Dienstleistungen: Dienstleistungen sind immateriell (du kannst sie nicht anfassen), ko-produziert (Kunde und Anbieter erbringen sie gemeinsam) und prozesshaft (sie entfalten sich über die Zeit). Eine Methode, die diese drei Eigenschaften nicht adressiert, ist eine Managementmethode — aber keine Service Design Methode im engeren Sinn.

Zwei Traditionen, eine Toolbox

Die Methoden, die heute im Service Design eingesetzt werden, stammen aus zwei unterschiedlichen Traditionen:

Die Design-Tradition — entstanden aus Ethnografie, Industriedesign und Human-Centered Design. Kern: Verstehen durch Beobachtung und Einfühlung, Gestalten durch Visualisierung und Prototyping. Typische Methoden: Personas, Journey Maps, Service Blueprints, Storyboards, Co-Creation-Workshops. G. Lynn Shostack, die 1982 das Service Blueprint erfand, kam aus dem Bankwesen — aber ihre Methode wurde von der Design-Community adoptiert und weiterentwickelt [2]. Bitner, Ostrom und Morgan zeigten 2008, dass Blueprinting in der Praxis Kundenbeschwerden um bis zu 50 % reduzieren kann [7].

Die Qualitätsmanagement-Tradition — entstanden aus dem japanischen Total Quality Management der 1950er-Jahre, geprägt von W. Edwards Deming, Kaoru Ishikawa und Noriaki Kano. Kern: Messen, Analysieren, Verbessern. Typische Methoden: Ishikawa-Diagramm, PDCA-Zyklus, Kano-Modell, Gemba Walk, Wertstromanalyse. Diese Werkzeuge wurden für die Fertigungsqualität entwickelt — aber ihre Logik (Ursachenanalyse, Kundenbedarfsklassifikation, iterative Verbesserung, Beobachtung vor Ort) ist direkt auf Servicequalität übertragbar [3] [5].

Die meisten deutschsprachigen Übersichten zu Service Design Methoden decken ausschließlich die Design-Tradition ab. Dieser Artikel integriert beide — weil ein Produktmanager bei einem Automobilhersteller, der seinen After-Sales-Service verbessern will, das Ishikawa-Diagramm aus der Produktion bereits kennt und es direkt auf Servicefehler anwenden kann.

10 Kategorien von Service Design Methoden

Die folgende Taxonomie organisiert 40+ Methoden in zehn funktionale Kategorien — nicht nach Projektphase (wie der Double Diamond des British Design Council [6]), sondern nach dem Zweck, den sie erfüllen. Denn dieselbe Methode kann in verschiedenen Phasen eingesetzt werden: Ein Service Blueprint dient in der Discover-Phase der Ist-Analyse und in der Develop-Phase dem Soll-Entwurf.

1. Research & Discovery

Methode	Zweck	Wann einsetzen
Empathy Map	Nutzer-Empathie aufbauen	Projektstart, vor Persona-Erstellung
Persona	Nutzertypen verdichten	Nach Recherche, als Grundlage für Mapping
Shadowing	Reale Nutzung beobachten	Wenn Selbstberichte nicht ausreichen
Fokusgruppe	Gruppenperspektiven erfassen	Für explorative Hypothesen
Diary Study	Verhalten über Zeit erfassen	Für longitudinale Nutzungsmuster
Contextual Inquiry	Im Nutzungskontext befragen	Für komplexe Arbeitsumgebungen

2. Mapping & Visualisierung

Methode	Zweck	Wann einsetzen
Service Blueprint	Front- & Backstage-Prozesse abbilden	Analyse bestehender Services, Soll-Entwurf
Customer Journey Map	Kundenerlebnis über Touchpoints visualisieren [8]	Schmerzpunkte identifizieren, Emotionen kartieren
Stakeholder Map	Akteure und Beziehungen darstellen	Projektvorbereitung, Komplexe Ökosysteme
Storyboard	Szenarien visuell erzählen	Neue Konzepte kommunizieren
Ecosystem Map	Service-Ökosystem abbilden	Für systemische Perspektive

3. Ideation & Kreation

Methode	Zweck	Wann einsetzen
Morphologischer Kasten	Lösungsraum systematisch explorieren	Wenn mehr als 3 unabhängige Dimensionen kombiniert werden
Brainstorming	Viele Ideen schnell generieren	Breite Ideenfindung, lockerer Einstieg
Brainwriting (6-3-5)	Stille Ideengenerierung	Wenn Introvertierte zu Wort kommen sollen
SCAMPER	Bestehende Lösungen variieren	Für inkrementelle Innovation
Crazy Eights	8 Ideen in 8 Minuten skizzieren	Schnelle Konzeptvariation
How Might We	Probleme in Chancen umformulieren	Übergang von Analyse zu Ideation

4. Analyse & Synthese

Methode	Zweck	Wann einsetzen
Ishikawa-Diagramm	Ursachen systematisch analysieren	Wenn ein Problem mehrere Ursachenbereiche hat
Five Whys	Grundursache einer Kette finden	Für einzelne lineare Ursachenketten
Affinitätsdiagramm	Daten gruppieren und Muster erkennen	Nach Research, vor Synthese
Root Cause Analysis	Grundursachen identifizieren	Nach Servicefehlern
Jobs-to-be-Done	Kundenbedarf funktional beschreiben	Für bedarfsorientierte Analyse

5. Workshop & Facilitation

Methode	Zweck	Wann einsetzen
Retrospektive	Vergangenes reflektieren	Nach Projektphasen, Sprints
World Cafe	Wissen im großen Kreis teilen	Für 15+ Teilnehmer
LEGO Serious Play	Komplexität greifbar machen	Für abstrakte Themen, Strategiearbeit
Fishbowl	Fokussierte Gruppendiskussion	Wenn wenige Experten viele informieren
Design Studio	Paralleles Konzeptieren im Team	Für Alignment bei divergierenden Ideen

6. Prototyping & Testing

Methode	Zweck	Wann einsetzen
Service Prototyping	Serviceerlebnis simulieren	Vor der Implementierung
Desktop Walkthrough	Miniatur-Simulation mit Figuren	Schnelles Prozessverständnis im Team
Wizard of Oz	Service manuell simulieren	Wenn Technologie noch nicht gebaut ist
Usability-Test	Nutzbarkeit prüfen	Für digitale Touchpoints
A/B-Test	Varianten vergleichen	Für datengetriebene Entscheidungen

7. Prozess & Verbesserung

Methode	Zweck	Wann einsetzen
PDCA-Zyklus	Iterativ planen, testen, lernen	Kontinuierliche Verbesserung
Gemba Walk	Vor Ort beobachten	Wenn du den Service selbst erleben willst
Wertstromanalyse	Wertschöpfung vs. Verschwendung trennen	Für Prozessoptimierung
Kaizen	Schrittweise verbessern	Für inkrementelle Verbesserungskultur

8. Entscheidung & Priorisierung

Methode	Zweck	Wann einsetzen
Kano-Modell	Kundenanforderungen klassifizieren	Wenn du Basis-, Leistungs- und Begeisterungsmerkmale trennen musst
Entscheidungsmatrix	Alternativen gewichtet bewerten	Für transparente Auswahlentscheidungen
MoSCoW	Must/Should/Could/Won’t priorisieren	Für schnelle Priorisierung im Team
Impact/Effort-Matrix	Aufwand vs. Wirkung visualisieren	Für Priorisierung von Quick Wins

9. Canvases & Frameworks

Methode	Zweck	Wann einsetzen
Business Model Canvas	Geschäftsmodell auf einer Seite	Strategische Einordnung des Service
Value Proposition Canvas	Wertversprechen an Kundenbedarf koppeln	Für Product-Market-Fit-Analyse
Service Logic Canvas	Servicelogik beschreiben	Für service-dominante Perspektive
Team Canvas	Team-Alignment herstellen	Projektstart, neue Teamkonstellationen

10. Templates & Vorlagen

Templates sind keine eigenständigen Methoden, sondern standardisierte Formate für die oben genannten Methoden. Vorlagen für Service Blueprint, Customer Journey Map, Ishikawa-Diagramm und Kano-Fragebogen findest du in den jeweiligen Detailartikeln.

Wann welche Methode? Die Auswahlmatrix

Die meisten Methodenübersichten ordnen Werkzeuge nach dem Double Diamond [6] — Discover, Define, Develop, Deliver. Das ist ein sinnvoller Startpunkt, aber es reicht nicht. Denn innerhalb jeder Phase stehen dir fünf bis zehn Methoden zur Verfügung. Die entscheidende Frage ist nicht „In welcher Phase bin ich?”, sondern: Welches Problem löse ich gerade, mit wem und wie viel Zeit habe ich?

Dimension 1: Problemtyp

Du willst…	Dann nutze…	Nicht…
Nutzer verstehen	Empathy Map, Shadowing, Contextual Inquiry	Brainstorming (du brauchst zuerst Daten)
Ideen generieren	Morphologischer Kasten, Brainstorming, How Might We	Ishikawa (das ist Analyse, nicht Ideation)
Ursachen analysieren	Ishikawa-Diagramm, Five Whys, Root Cause Analysis	Journey Map (die zeigt Symptome, nicht Ursachen)
Lösungen validieren	Usability-Test, Service Prototyping, A/B-Test	Persona (die beschreibt Nutzer, nicht Lösungen)
Entscheidungen treffen	Kano-Modell, MoSCoW, Entscheidungsmatrix	Affinitätsdiagramm (das gruppiert, entscheidet aber nicht)

Dimension 2: Teamgröße

Teamgröße	Geeignete Methoden	Ungeeignete Methoden
Solo (1 Person)	Desk Research, Empathy Map, Storyboard, Five Whys	World Cafe, LEGO Serious Play, Fishbowl
Kleines Team (2-5)	Service Blueprint, Ishikawa-Diagramm, Morphologischer Kasten, Brainwriting	World Cafe (zu wenige Teilnehmer)
Workshop-Gruppe (6-20)	Customer Journey Map, World Cafe, Design Studio, Gemba Walk	Five Whys (zu viele Stimmen für lineare Analyse)

Dimension 3: Verfügbare Zeit

Zeitbudget	Methoden	Ergebnis
30-60 Minuten	How Might We, Crazy Eights, Impact/Effort-Matrix, Five Whys	Schnelle Hypothesen, erste Priorisierung
Halber Tag (3-4 Std.)	Ishikawa-Diagramm, Empathy Map + Persona, MoSCoW-Priorisierung	Strukturierte Analyse, erste Synthese
Ganzer Tag	Customer Journey Map, Service Blueprint, Kano-Modell (Auswertung)	Vollständige Artefakte
Mehrtägig	Service Prototyping, Diary Study, PDCA-Zyklus (kompletter Durchlauf)	Validierte Ergebnisse

Konkrete Empfehlungen

Nutze das Ishikawa-Diagramm, wenn du eine klare Ursachenanalyse brauchst, bevor du Lösungen entwickelst — besonders wenn das Team mehr als eine Hypothese für das Problem hat und alle systematisch geprüft werden müssen.

Nutze den PDCA-Zyklus, wenn du eine Verbesserung in kurzen Iterationsschleifen testen willst — nicht als einmaliges Projekt, sondern als wiederkehrendes Verbesserungsformat.

Nutze das Kano-Modell, wenn du priorisieren musst und wissen willst, welche Servicemerkmale Basiserwartung sind (nicht verhandelbar) und welche Begeisterung auslösen (Differenzierungspotenzial).

Nutze den Gemba Walk, wenn du den Service nicht aus Berichten kennenlernen willst, sondern aus eigener Anschauung — besonders wenn die Diskrepanz zwischen dokumentiertem Soll-Prozess und gelebtem Ist-Prozess groß sein könnte.

Die vergessene Tradition: Qualitätsmanagement-Werkzeuge im Service Design

Wenn du in einem Unternehmen mit Qualitätsmanagement-Tradition arbeitest — und das trifft auf fast alle produzierenden Unternehmen und viele Dienstleister zu —, dann kennst du einen Teil der Service Design Toolbox bereits, ohne es zu wissen.

Vier Werkzeuge aus dem Qualitätsmanagement gehören in jede Service Design Toolbox, werden aber von der Design-Community systematisch übersehen:

Das Ishikawa-Diagramm (1943, Kaoru Ishikawa bei Kawasaki Steel Works [3]) ist die strukturierteste verfügbare Methode für Ursachenanalyse. Im Service Design kommt es zum Einsatz, wenn ein Serviceproblem mehrere potenzielle Ursachenbereiche hat — Mensch, Methode, Technologie, Prozess — und das Team über die offensichtlichste Erklärung hinausgehen muss. Wenn ein Versicherer feststellt, dass die Schadensbearbeitungszeit im After-Sales-Prozess von 5 auf 14 Tage gestiegen ist, hilft kein Brainstorming. Es braucht ein Ishikawa-Diagramm, das alle Ursachenkategorien systematisch durcharbeitet.

Der PDCA-Zyklus (1950er, W. Edwards Deming [5]) liefert die iterative Verbesserungslogik, die im Service Design oft als selbstverständlich vorausgesetzt, aber selten explizit praktiziert wird. Plan-Do-Check-Act ist das einfachste und robusteste Framework für kontinuierliche Serviceverbesserung. Ein Automobilhersteller, der seinen digitalen Kundenservice iterativ verbessern will, kann jeden Verbesserungszyklus als PDCA-Schleife strukturieren — mit expliziter Check-Phase, in der gemessen wird, ob die Maßnahme gewirkt hat.

Das Kano-Modell (1984, Noriaki Kano [4]) klassifiziert Servicemerkmale nach ihrer Wirkung auf die Kundenzufriedenheit. Es beantwortet eine Frage, die weder Personas noch Journey Maps beantworten können: Welche Features sind Basiserwartung, welche sind Leistungstreiber und welche erzeugen Begeisterung? Ein Finanzdienstleister, der sein Online-Banking-Portal weiterentwickelt, braucht das Kano-Modell, um zu verstehen, dass eine schnelle Ladezeit Basismerkmal ist (Abwesenheit erzeugt Frust, Anwesenheit wird nicht bemerkt), während eine proaktive Ausgabenanalyse Begeisterungsmerkmal ist.

Der Gemba Walk (japanisch: „der reale Ort”) bringt Entscheidungsträger dorthin, wo der Service tatsächlich stattfindet — nicht in den Besprechungsraum, sondern an die Servicefront. Ein Klinikmanager, der den Patientenaufnahmeprozess verbessern will, lernt mehr aus zwei Stunden Beobachtung am Empfang als aus zehn PowerPoint-Berichten.

Diese vier Werkzeuge sind keine Konkurrenz zu Journey Maps, Blueprints und Personas — sie ergänzen sie. Die Design-Tradition ist stark im Verstehen und Gestalten. Die QM-Tradition ist stark im Analysieren und Verbessern. Ein vollständiges Service Design Projekt braucht beides.

Tool-Kombinationen: Welche Methoden passen zusammen?

Einzelne Methoden entfalten ihre volle Wirkung erst in der richtigen Kombination. Die folgende Übersicht zeigt drei bewährte Sequenzen für typische Projektszenarien — mit Erklärung, warum die Methoden in dieser Reihenfolge zusammengehören.

Sequenz A: Service Redesign — „Ein bestehender Service funktioniert nicht gut genug”

Customer Journey Mapping → Ishikawa-Diagramm → Morphologischer Kasten → Service Blueprint → Service Prototyping

Die Journey Map identifiziert, wo der Service scheitert — die Pain Points und kritischen Touchpoints. Das Ishikawa-Diagramm analysiert, warum er dort scheitert — welche Ursachen in welchen Kategorien liegen. Der Morphologische Kasten generiert systematisch wie er besser werden könnte — indem er die Lösungsdimensionen kombiniert. Das Service Blueprint übersetzt die beste Lösung in einen vollständigen Prozessentwurf mit Front- und Backstage. Der Prototyp testet, ob der Entwurf in der Praxis funktioniert.

Anwendungsfall: Ein Automobilhersteller stellt fest, dass Kunden den digitalen After-Sales-Prozess bei Schritt 4 von 7 abbrechen. Die Journey Map zeigt den Abbruchpunkt, Ishikawa identifiziert Ursachen (unklare Statusmeldungen, fehlende Rückruf-Option, langsame Systemantwort), der Morphologische Kasten kombiniert Lösungsoptionen, das Blueprint definiert den neuen Prozess.

Sequenz B: New Service Development — „Wir entwickeln einen neuen Service von Grund auf”

Empathy Map → Persona → Service Blueprint → Kano-Modell → PDCA-Zyklus

Die Empathy Map baut Verständnis für den Nutzer auf — was sieht, hört, denkt und fühlt er? Die Persona verdichtet dieses Verständnis in einen handlungsfähigen Archetyp. Das Service Blueprint entwirft den neuen Service als vollständigen Prozess. Das Kano-Modell priorisiert die Features — welche sind Basiserwartung, welche differenzieren? Der PDCA-Zyklus steuert die iterative Markteinführung: klein starten, messen, lernen, anpassen.

Anwendungsfall: Eine Bank entwickelt einen neuen digitalen Beratungsservice für Firmenkunden. Empathy Maps und Personas basieren auf Interviews mit Firmenkunden-Beratern und ihren Kunden. Das Blueprint definiert den gesamten Beratungsprozess. Das Kano-Modell zeigt, dass Video-Beratung Basiserwartung ist, aber eine integrierte Dokumentenfreigabe Begeisterung auslöst. PDCA steuert die schrittweise Einführung.

Sequenz C: Service Improvement — „Wir wollen einen bestehenden Service schrittweise besser machen”

Gemba Walk → Ishikawa-Diagramm → PDCA-Zyklus → Service Blueprint

Der Gemba Walk liefert Beobachtungsdaten aus erster Hand — was passiert wirklich an der Servicefront? Das Ishikawa-Diagramm strukturiert die beobachteten Probleme und analysiert ihre Ursachen. Der PDCA-Zyklus testet Verbesserungsmaßnahmen in schnellen Iterationen. Das Service Blueprint dokumentiert den verbesserten Prozess als neuen Standard.

Anwendungsfall: Ein Versicherer beobachtet steigende Beschwerden im Schadensprozess. Der Gemba Walk am Kundenservice-Standort zeigt, dass Sachbearbeiter zwischen drei nicht integrierten Systemen wechseln müssen. Ishikawa analysiert die Ursachen (Systemlandschaft, Schulungsdefizite, Prozesslücken). PDCA testet zunächst eine vereinfachte Eingabemaske. Das Blueprint dokumentiert den optimierten Prozess.

Physische vs. digitale Tools

Service Design Methoden leben von der Interaktion im Team — und das Medium beeinflusst die Qualität dieser Interaktion.

Physische Tools (Post-its, Whiteboards, ausgedruckte Templates, Moderationskarten) erzeugen in Workshops ein höheres Engagement. Die haptische Interaktion senkt die Hemmschwelle zur Beteiligung: Es ist einfacher, einen Post-it zu verschieben als einen digitalen Kommentar zu hinterlassen. Physische Tools eignen sich besonders für Ideation-Sessions, Journey-Mapping-Workshops und alle Formate, bei denen spontane Beteiligung wichtiger ist als Dokumentierbarkeit.

Digitale Tools (Miro, Figma, Smaply, Mural) sind überlegen, wenn Teams verteilt arbeiten, Ergebnisse langfristig dokumentiert werden müssen oder Vorlagen wiederverwendet werden sollen. Sie sind außerdem unverzichtbar für die asynchrone Zusammenarbeit: Ein Blueprint in Miro kann über Wochen weiterentwickelt werden, ein Whiteboard-Foto nicht.

Die pragmatische Regel: Starte physisch, dokumentiere digital. Der Workshop findet mit Post-its und Whiteboard statt. Danach wird das Ergebnis digitalisiert — als lebendiges Dokument, nicht als Foto-Archiv.

Häufige Fehler bei der Methodenwahl

1. Methoden-Overkill

Ein kleines Verbesserungsprojekt braucht keine 8 Methoden aus 5 Kategorien. Wenn du einen einzelnen Touchpoint optimieren willst, reichen ein Gemba Walk, ein Ishikawa-Diagramm und ein PDCA-Zyklus. Nicht jedes Projekt braucht Personas, Journey Maps und Service Blueprints.

2. Methoden-Fetischismus

Die Methode wird zum Selbstzweck. Das Team diskutiert 30 Minuten über die korrekte Ishikawa-Kategorisierung (4M oder 6M?), statt die Ursachen zu analysieren. Methoden sind Werkzeuge, nicht Rituale. Wenn eine Methode nicht zum Problem passt, wechsle die Methode — nicht das Problem.

3. Copy-Paste ohne Anpassung

Methoden 1:1 aus dem Lehrbuch zu übernehmen funktioniert selten. Ein Kano-Fragebogen für eine Versicherungs-App sieht anders aus als einer für eine E-Commerce-Plattform. Die Kategorien eines Ishikawa-Diagramms für einen digitalen Service unterscheiden sich von denen für einen Fertigungsprozess. Passe die Methode an deinen Kontext an.

4. Nur die Design-Tradition

Teams, die nur mit Journey Maps, Personas und Blueprints arbeiten, verpassen die analytische Schärfe, die QM-Werkzeuge liefern. Wenn ein Serviceproblem komplexe Ursachen hat, hilft kein noch so detailliertes Journey Mapping — du brauchst ein Ishikawa-Diagramm oder eine andere Form der strukturierten Ursachenanalyse.

5. Fehlende Iteration

Eine Customer Journey Map einmal erstellen und dann in die Schublade legen ist kein Service Design. Service Design ist iterativ. Der PDCA-Zyklus macht diese Iteration explizit: Plane eine Verbesserung, setze sie um, prüfe das Ergebnis, passe an. Dann von vorn. Stickdorn et al. [1] betonen: Service Design ist ein Prozess, kein Projekt. Die Methoden sind nur so gut wie die Iteration, in die sie eingebettet sind.

Häufig gestellte Fragen

Was sind die wichtigsten Service Design Methoden?

Die fünf am häufigsten eingesetzten Service Design Methoden in der Praxis sind: Customer Journey Mapping (für die Visualisierung des Kundenerlebnisses), Service Blueprint (für die Prozessarchitektur), Persona (für die Nutzerverdichtung), das Kano-Modell (für die Anforderungspriorisierung) und der PDCA-Zyklus (für die iterative Verbesserung). Welche Methoden „wichtig” sind, hängt aber vom Projekt ab — die Auswahlmatrix weiter oben hilft bei der Entscheidung.

Welche Service Design Methoden gibt es?

In der Literatur sind über 54 Methoden dokumentiert [1]. Dieser Artikel ordnet 40+ davon in 10 funktionale Kategorien: Research, Mapping, Ideation, Analyse, Workshop, Prototyping, Prozessverbesserung, Priorisierung, Canvases und Templates. Die Kategorien orientieren sich am Zweck der Methode, nicht an der Projektphase — weil dieselbe Methode in verschiedenen Phasen eingesetzt werden kann.

Was ist der Unterschied zwischen Service Design und Design Thinking Methoden?

Design Thinking und Service Design teilen viele Methoden — Empathy Map, Prototyping, How Might We. Der Unterschied liegt im Gegenstand: Design Thinking ist ein generischer Innovationsansatz für Produkte, Services und Systeme. Service Design wendet diesen Ansatz spezifisch auf Dienstleistungen an und ergänzt ihn um servicespezifische Werkzeuge wie Service Blueprint, Customer Journey Map und Backstage-Prozessanalyse. Außerdem integriert Service Design Werkzeuge aus dem Qualitätsmanagement (Ishikawa, PDCA, Kano), die in der Design-Thinking-Literatur kaum vorkommen.

Brauche ich alle Methoden für jedes Projekt?

Nein. Ein typisches Service Design Projekt nutzt 3-6 Methoden, nicht 40. Die Auswahl hängt ab von deinem Problemtyp (verstehen, analysieren, generieren, entscheiden), deiner Teamgröße und deinem Zeitbudget. Die drei Tool-Kombinationen in diesem Artikel (Service Redesign, New Service Development, Service Improvement) zeigen bewährte Sequenzen von jeweils 4-5 Methoden. Starte mit der Kombination, die zu deinem Projektziel passt, und ergänze Methoden nur bei Bedarf.

Quellenverzeichnis

[1] Stickdorn, Marc, Markus Hormess, Adam Lawrence und Jakob Schneider. This is Service Design Doing: Applying Service Design Thinking in the Real World. Sebastopol, CA: O’Reilly, 2018.

[2] Shostack, G. Lynn. “How to Design a Service.” European Journal of Marketing 16, Nr. 1 (1982): 49-63. doi:10.1108/EUM0000000004799.

[3] Ishikawa, Kaoru. What Is Total Quality Control? The Japanese Way. Englewood Cliffs, NJ: Prentice Hall, 1985.

[4] Kano, Noriaki, Nobuhiko Seraku, Fumio Takahashi und Shin-ichi Tsuji. “Attractive Quality and Must-Be Quality.” Journal of the Japanese Society for Quality Control 14, Nr. 2 (1984): 39-48.

[5] Deming, W. Edwards. Out of the Crisis. Cambridge, MA: MIT Press, 1986.

[6] British Design Council. “The Double Diamond: A Universally Accepted Depiction of the Design Process.” London, 2005.

[7] Bitner, Mary Jo, Amy L. Ostrom und Felicia N. Morgan. “Service Blueprinting: A Practical Technique for Service Innovation.” California Management Review 50, Nr. 3 (2008): 66-94.

[8] Følstad, Asbjørn und Knut Kvale. “Customer Journeys: A Systematic Literature Review.” Journal of Service Theory and Practice 28, Nr. 2 (2018): 196-227.