User Research im Service Design: Methoden, JTBD & B2B-Praxis

Dein Unternehmen hat ein neues Kundenportal gelauncht. Die UX-Tests liefen sauber, das Interface ist modern, die Ladezeiten stimmen. Trotzdem stagniert der NPS. Die Support-Tickets steigen. Und im Quartalsmeeting sagt der Geschäftsführer: “Wir haben doch Nutzerforschung gemacht.”

Habt ihr. Aber die falschen Fragen gestellt — an den falschen Leuten, zur falschen Zeit. Was getestet wurde, war das Frontstage: Buttons, Formulare, Navigation. Was nie untersucht wurde: Warum Kunden den Service überhaupt nutzen, welche internen Übergaben zwischen Vertrieb und Operations den Prozess brechen, und warum die Sachbearbeiter seit Jahren mit einem Workaround arbeiten, den kein Interview je erfasst hat.

Das ist der Unterschied zwischen UX Research und User Research im Service Design. UX Research optimiert Touchpoints. Service Design Research untersucht das gesamte Service-Ökosystem — Frontstage und Backstage, Kunden und Mitarbeiter, sichtbare Interaktionen und unsichtbare Strukturen [1]. Die Qualität dieser Forschung entscheidet sich nicht bei der Datenerhebung, sondern an drei Stellen, die kein deutsches Handbuch adressiert: dem Zugang zu den richtigen Stakeholdern im Enterprise-Kontext, der Synthese von Research-Daten zu Handlungsimpulsen, und der Unterscheidung zwischen Research, die bestätigt, und Research, die verändert.

Was ist User Research im Service Design?

Sarah Gibbons (Nielsen Norman Group) formuliert die Abgrenzung: UX und Service Design sind “zwei Seiten derselben Medaille” — UX definiert, was der Nutzer erlebt, Service Design orchestriert, welche internen Strukturen das Erlebnis tragen [1]. Für die Forschung bedeutet das: Wenn du nur den Endnutzer befragst, verstehst du bestenfalls die Hälfte des Problems.

Generative vs. evaluative Forschung

Stickdorn et al. (2018) unterscheiden zwei Forschungsmodi, die im Service Design verschiedene Funktionen erfüllen [2]:

Modus	Frage	Typische Methoden	Phase im Double Diamond
Generativ (entdeckend)	Was sind die tatsächlichen Bedürfnisse? Welche Probleme existieren, die wir noch nicht kennen?	Contextual Inquiry, Service Safari, JTBD-Interviews, Stakeholder-Interviews	Discover
Evaluativ (prüfend)	Funktioniert unsere Lösung? Wo hakt es?	Usability-Tests, A/B-Tests, Service-Prototyping	Deliver

Die deutsche SERP-Landschaft behandelt fast ausschließlich evaluative Methoden — Usability-Tests, Surveys, A/B-Tests [3]. Für Service Innovation ist das zu spät. Generative Forschung muss vor der ersten Designentscheidung stattfinden, weil sie bestimmt, was überhaupt gebaut wird. Christian Rohrer (NN/g) bringt es auf den Punkt: “What people say” und “what people do” sind sehr oft grundverschieden — wer nur fragt, statt zu beobachten, verpasst genau die Erkenntnisse, die den Service verändern würden [4].

Warum Service-Design-Research anders ist als Produktforschung

Drei strukturelle Unterschiede:

1. Mehrere Nutzertypen gleichzeitig. Im B2B-Kontext gibt es nicht “den Nutzer”, sondern Nutzer, Entscheider, Einflussnehmer, Einkäufer und Gatekeeper — jede Rolle mit anderen Bedürfnissen [5]. Wenn du nur den Einkaufskontakt befragst, verpasst du die Sachbearbeiterin, die den Service täglich nutzt.

2. Backstage ist Teil des Forschungsfelds. Ein Service wird durch eine Organisation erbracht. Interne Übergaben, informelle Workarounds, Systembrüche zwischen Abteilungen — all das beeinflusst die Servicequalität, ist aber für den Endkunden unsichtbar. Birgit Mager (TH Köln, weltweit erste Professorin für Service Design) formuliert das Prinzip: “You cannot change the frontstage if you don’t impact the backstage” [6].

3. Der Forschungsgegenstand existiert in der Zeit. Ein Produkt kann man anfassen und testen. Ein Service entfaltet sich über Tage, Wochen oder Monate — vom ersten Kontakt über die Nutzung bis zur Kündigung. Forschungsmethoden müssen diese zeitliche Dimension abbilden.

Die wichtigsten Research-Methoden für Service Design

Die folgenden vier Methoden decken die generative Forschungsphase im Service Design ab. Sie ergänzen sich: Contextual Inquiry und Service Safari liefern Beobachtungsdaten, Stakeholder-Interviews erschließen Organisationswissen, Organisationsethnografie macht unsichtbare Strukturen sichtbar.

Contextual Inquiry — Nutzer im Kontext verstehen

Wann einsetzen: Wenn du verstehen willst, wie Menschen einen Service in ihrem tatsächlichen Arbeitsumfeld nutzen — nicht, wie sie glauben, ihn zu nutzen.

Was es ist: Contextual Inquiry (Kontextinterview) ist eine Feldforschungsmethode, die Holtzblatt und Beyer 1997 systematisierten [7]. Der Forscher beobachtet und befragt Nutzer an ihrem Arbeitsplatz, im “Meister-Lehrling-Modell”: Der Nutzer ist der Meister, der seine Arbeit zeigt; der Forscher ist der Lehrling, der zusieht, zuhört und gezielt nachfragt. Die Methode basiert auf vier Prinzipien: Kontext (am Ort der Nutzung), Partnerschaft (gemeinsames Erkunden), Interpretation (Deutungen sofort validieren) und Fokus (auf die Forschungsfrage konzentriert) [8].

Protokoll:

1. Vorbereitung: Forschungsfrage definieren, Einwilligung einholen (DSGVO-konform, dazu mehr in Abschnitt 6), Beobachtungsleitfaden vorbereiten
2. Primer (10 Min.): Rapport aufbauen, Erwartungen klären, Vertraulichkeit zusichern
3. Transition: Explizit vom Gespräch in den Beobachtungsmodus wechseln — “Zeig mir bitte, wie du normalerweise vorgehst”
4. Beobachtung mit Rückfragen (60-90 Min.): Zwischen Zusehen und gezielten Fragen alternieren. Eigene Interpretationen sofort am Nutzer validieren: “Du hast gerade zwischen zwei Programmen gewechselt — ist das immer so?”
5. Wrap-up (10 Min.): Zusammenfassung der wichtigsten Beobachtungen, letzte Korrekturen durch den Nutzer

Praxis-Tipp: Der häufigste Fehler ist, die Transition in Schritt 3 zu überspringen. Ohne expliziten Wechsel bleibt das Gespräch im Interview-Modus — der Nutzer fasst zusammen, statt zu zeigen. NN/g dokumentiert einen Versicherungs-Fall, der das Problem illustriert: Datenerfasserinnen eines Auto-Versicherers beschrieben ihren Arbeitsablauf in Interviews als einfach und geradlinig. Die Beobachtung vor Ort zeigte ein völlig anderes Bild: Sie wechselten routinemäßig zwischen zwei Software-Tools und speicherten nach jedem Eintrag manuell, obwohl Autosave aktiv war. Beide Gewohnheiten waren so tief eingeschliffen, dass sie in keinem Interview erwähnt wurden [8]. Michael Polanyi nannte dieses Phänomen “tacit knowledge” — Wissen, das so tief in der Praxis verankert ist, dass es nicht verbalisiert werden kann [9].

Service Safari — den Service selbst erleben

Wann einsetzen: Zu Beginn jedes Service-Design-Projekts, bevor die erste Kundeninteraktion stattfindet — als Grundlage für das eigene Verständnis des Service-Erlebnisses.

Was es ist: Bei einer Service Safari durchläuft das Designteam den Service aus der Kundenperspektive — als Erstnutzer, nicht als Analyst [2]. Du gehst in die Bankfiliale, meldest einen Schadenfall, rufst die Hotline an, durchläufst das Onboarding. Das Ziel ist nicht Bewertung, sondern Erfahrung: Wie fühlt sich der Service an, wenn du ihn tatsächlich nutzt?

Protokoll:

1. Szenario definieren: Welchen Service-Pfad durchlaufen wir? (z. B. “Schadenfall melden als Neukunde”)
2. Dokumentationsrahmen festlegen: AEIOU-Framework (Activities, Environments, Interactions, Objects, Users) oder TACIT (Thoughts, Actions, Context, Interactions, Touchpoints)
3. Service durchlaufen: Einzeln oder in Zweierteams, mit Fotos, Screenshots und Notizen. Keine Sonderbehandlung — du bist Kunde, kein Auditor
4. Sofort-Debrief (30 Min.): Emotionale Höhepunkte und Tiefpunkte teilen, Überraschungen dokumentieren
5. Ergebnisse konsolidieren: In eine vorläufige Customer Journey Map überführen

Praxis-Tipp: Die Service Safari ist die am niedrigschwelligsten zugängliche Research-Methode — kein Budget, keine Rekrutierung, kein externer Dienstleister nötig. Und sie überrascht zuverlässig: Wenn dein Team eine Schadenmeldung bei der eigenen Versicherung durchläuft, tauchen Warteschleifen, redundante Formulare und tote Touchpoints auf, die in keinem Prozesshandbuch stehen. Sie komplementiert ein systematisches Benchmarking um die Erfahrungsperspektive: Benchmarking vergleicht Kennzahlen, die Service Safari vergleicht Erlebnisse.

Stakeholder-Interviews — das Organisationswissen erschließen

Wann einsetzen: Wenn du verstehen willst, wie verschiedene Abteilungen den Service wahrnehmen, wo interne Konflikte die Servicequalität beeinflussen und welche organisatorischen Constraints die Gestaltung begrenzen.

Was es ist: Strukturierte Einzelgespräche mit internen und externen Stakeholdern — nicht als Projektstart-Ritual, sondern als eigenständige Forschungsmethode [10]. NN/g identifiziert fünf Zwecke: Politik neutralisieren, Anforderungen besser verstehen, organisatorische Prioritäten erfassen, den Designprozess anpassen und Buy-in aufbauen [10]. Für Multi-Stakeholder Design sind sie unverzichtbar, weil sie die unterschiedlichen Erfolgsdefinitionen verschiedener Rollen sichtbar machen.

Protokoll:

1. Leitfaden erstellen: Maximal 8 offene Fragen, davon 2-3 rollenübergreifend (“Was bedeutet guter Service für deine Abteilung?”) und 2-3 rollenspezifisch
2. Breite Abdeckung planen: Nicht nur Management — Frontline-Mitarbeiter, Support, Operations und externe Partner einbeziehen
3. Einzelgespräche führen (45-60 Min.): Keine Gruppeninterviews. Die Hierarchie-Dynamik deutscher Unternehmen verfälscht Gruppenaussagen
4. Sofort-Notizen: Innerhalb von 30 Minuten nach dem Interview die drei wichtigsten Aussagen festhalten
5. Quermuster identifizieren: Nach 5-6 Interviews die wiederkehrenden Themen und Widersprüche zwischen Abteilungen konsolidieren

Praxis-Tipp: Die wertvollste Frage in einem Stakeholder-Interview ist nicht “Was funktioniert?”, sondern “Was passiert zwischen deiner Abteilung und der nächsten, wenn ein Kundenfall weitergegeben wird?” Übergaben sind die Bruchstellen im Service — und sie sind in keinem Prozesshandbuch dokumentiert, weil sie sich organisch entwickelt haben.

Steve Portigal (2024) dokumentiert ein Phänomen, das jeder erfahrene Interviewer kennt: Die wichtigsten Informationen kommen oft erst, wenn das formelle Interview vorbei ist — im Türrahmen, beim Hinausgehen, wenn der Aufnahmeknopf theoretisch schon gedrückt wurde [34]. Portigal nennt es das “Türgriff-Phänomen”. Der Grund: In dem Moment, in dem die formale Gesprächssituation endet, fällt die soziale Erwünschtheit weg. Der Tipp: Lass das Aufnahmegerät laufen, bis du das Gebäude verlässt.

Organisationsethnografie — die unsichtbaren Strukturen sichtbar machen

Wann einsetzen: Wenn Interviews und Prozessdokumentation ein konsistentes Bild ergeben, die Servicequalität aber trotzdem leidet — ein Hinweis auf unsichtbare Strukturen, die nur durch Beobachtung im Arbeitsalltag zugänglich sind.

Was es ist: Organisationsethnografie überträgt ethnografische Methoden — teilnehmende Beobachtung, informelle Gespräche, Dokumentenanalyse — auf den Unternehmenskontext. Ybema et al. (2009) definieren sie als die Erforschung der “Kluft zwischen dem, wie Organisationen sagen, dass sie arbeiten, und dem, wie sie tatsächlich arbeiten” [11]. Segelstrom, Raijmakers und Holmlid (2009) zeigten in zwei Fallstudien, dass Service Designer ethnografische Methoden erfolgreich einsetzen können, allerdings mit einem anderen Kommunikationsfokus als klassische Ethnografen: Designer priorisieren visuelle Kommunikation der Erkenntnisse, Ethnografen priorisieren “thick description” [12].

Protokoll:

1. Zugang verhandeln: Formale Genehmigung einholen (bei Unternehmen mit Betriebsrat kann das Wochen dauern — einplanen, nicht unterschätzen)
2. Beobachtungsfokus definieren: z. B. Übergaben zwischen Abteilungen, informelle Workarounds, Kommunikationswege bei Eskalationen
3. Teilnehmende Beobachtung (2-5 Tage): Im Arbeitsumfeld mitlaufen, nicht in der Teeküche sitzen. Gespräche entstehen natürlich, wenn du die Arbeit miterlebst
4. Dokumentieren: Workarounds, Post-it-Zettel am Monitor, Excel-Listen, die kein System kennt — die Artefakte informeller Prozesse
5. Muster synthetisieren: Wo weicht die gelebte Praxis von der dokumentierten ab? Welche informellen Regeln stabilisieren den Service?

Praxis-Tipp: Die größte Erkenntnis der Organisationsethnografie ist fast immer, was nicht in der Prozessdokumentation steht. Die Excel-Tabelle, die eine Sachbearbeiterin seit drei Jahren pflegt, weil das offizielle CRM die Information nicht erfasst, sagt mehr über die Servicequalität als jede Prozesslandkarte. Wenn diese Tabelle bei einem System-Relaunch eliminiert wird, bricht ein Stück unsichtbare Infrastruktur weg.

Die bisherigen Methoden erzeugen Beobachtungs- und Kontextdaten. Aber Daten allein erzählen keine Geschichte. Um aus Beobachtungen Handlungsimpulse abzuleiten, brauchst du ein Interpretationsframework — und genau das liefert Jobs to be Done.

Jobs to be Done (JTBD) als Research-Framework

Zwei Schulen — und welche für Service Research passt

JTBD ist kein einheitliches Framework, sondern zwei fundamental verschiedene Interpretationen unter demselben Namen [13]:

Dimension	Ulwick / ODI	Christensen / Moesta
Kernkonzept	”Jobs” sind Aktivitäten mit messbaren Outcomes	”Jobs” sind der Fortschritt, den jemand im Leben machen will
Methode	Quantitativ: Outcome-Statements, Importance-Satisfaction-Surveys	Qualitativ: Switch-Interviews, Timeline-Rekonstruktion
Stärke	Systematisch, wiederholbar, quantifizierbar	Tiefes Verständnis von Motivation und Kontext
Schwäche	Erfasst emotionale und soziale Dimensionen schlecht	Schwer skalierbar, subjektive Interpretation

Für Service Design Research empfiehlt sich der Moesta/Christensen-Ansatz als Einstieg: Die qualitative Switch-Interview-Methode deckt auf, warum jemand einen Dienstleister wechselt oder bei ihm bleibt — eine Frage, die für Service Innovation zentral ist [14]. Ulwicks ODI-Methode ergänzt in der Priorisierungsphase, wenn quantifiziert werden muss, welche Outcomes am stärksten unterversorgt sind [15].

JTBD im B2B-Kontext: organisationale vs. persönliche Jobs

Im B2B-Service-Kontext hat jeder Stakeholder mindestens zwei “Jobs” gleichzeitig: einen organisationalen und einen persönlichen [16].

Job-Dimension	Beispiel (Versicherung)	Beispiel (Fertigung)
Funktional	”Schadenregulierung beschleunigen"	"Maschinenausfallzeit reduzieren”
Emotional	”Mich sicher fühlen, dass ich die richtige Entscheidung treffe"	"Nicht der sein, der die falsche Anlage bestellt hat”
Sozial	”Vor dem Vorstand als innovativ gelten"	"Im Team als zuverlässig wahrgenommen werden”

Die meisten Enterprise-Research-Projekte erfassen nur funktionale Jobs. Das ist zu wenig. Forrester (2024, n=16.000+) fand: 99 % der B2B-Käufe werden durch organisatorische Veränderungen ausgelöst, und 86 % geraten ins Stocken — oft, weil emotionale und soziale Bedenken einzelner Stakeholder nie adressiert wurden [17]. Die Frage “Was passiert für dich persönlich, wenn dieses Projekt scheitert?” deckt eine Dimension auf, die kein Fragebogen erfasst.

JTBD-Interviews für Services: Die Forces of Progress

Bob Moesta, Co-Entwickler des JTBD-Frameworks, operationalisierte die Switch-Interview-Technik mit dem Forces-of-Progress-Modell [14]:

• F1 — Push (Druck der Situation): Was stört am aktuellen Service so sehr, dass Veränderung nötig wird?
• F2 — Pull (Anziehung des Neuen): Was verspricht der neue Service, das der alte nicht bietet?
• F3 — Habit (Gewohnheit des Bestehenden): Was hält den Kunden beim aktuellen Anbieter — trotz Unzufriedenheit?
• F4 — Anxiety (Angst vor dem Neuen): Was befürchtet der Kunde beim Wechsel?

Wenn F1+F2 > F3+F4, findet der Wechsel statt. Im Enterprise-Kontext sind F3 und F4 oft die dominierenden Kräfte: Organisatorische Trägheit, Schulungsaufwand, Karriererisiko für den Entscheider und die schiere Komplexität eines Anbieterwechsels blockieren den Fortschritt, selbst wenn der aktuelle Service schlecht ist. Die Forrester-Daten stützen diese Beobachtung: 86 % der B2B-Kaufprozesse stocken [17] — oft nicht an Budgetfragen, sondern an der akkumulierten Angst (F4) der Beteiligten.

Von JTBD-Daten zum nächsten Schritt: Wenn Switch-Interviews die “Jobs” und “Forces” identifiziert haben, fließen diese direkt in ein Service Blueprint ein. Jeder identifizierte “Job” wird einem Touchpoint zugeordnet; jede “Force” informiert, welche Backstage-Prozesse den Service unterstützen oder untergraben müssen.

B2B-Personas: Rollenbasiert, nicht demografisch

Das Dual-Persona-Problem: Nutzer und Entscheider

Alan Cooper führte 1999 Personas als Designwerkzeug ein [18]. Im B2B-Kontext reicht eine einzelne Persona nicht, weil die Person, die einen Service nutzt, fast nie die Person ist, die ihn kauft. NN/g formuliert die zentrale Unterscheidung: “Users” (tägliche Operatoren) und “Choosers” (Budget-Entscheider) haben fundamental verschiedene Bedürfnisse [19].

Adele Revella (2015/2024) operationalisiert die B2B-Persona-Forschung mit den “5 Rings of Buying Insight”: Priority Initiative, Success Factors, Perceived Barriers, Buyer’s Journey und Decision Criteria [20]. Ihre Empfehlung: 8-10 Interviews pro homogenem Marktsegment, jeweils 30 Minuten, genügen, um die Kernmuster zu erkennen.

Für die verschiedenen Nutzertypen im Service Design und das vertiefte Framework zur Personas- und Prototypenentwicklung haben wir separate Artikel geschrieben. Hier der Kerngedanke für die Research-Phase: Bevor du Personas baust, kläre, für welche Rolle du forschst. Ein Research-Plan, der nur den Einkäufer befragt, produziert Personas, die den Einkäufer beschreiben — nicht den Nutzer.

Vom Buying Center zur Service-Persona

Das Buying-Center-Modell (Webster & Wind, 1972) identifiziert fünf Rollen: Nutzer, Einkäufer, Einflussnehmer, Entscheider und Gatekeeper [5]. Für Service-Persona-Research bedeutet das: Du brauchst nicht fünf Personas, aber du brauchst Research-Daten aus mindestens drei dieser Rollen — Nutzer, Entscheider und Gatekeeper als Minimum.

Ein häufiger Fehler: Die Persona-Erstellung beginnt mit demografischen Merkmalen (Alter, Branche, Unternehmensgröße). Das Persona Institut warnt explizit: “B2B-Unternehmen, die nur eine Persona erstellen, laufen Gefahr, wichtige Stakeholder im Buying Center zu ignorieren” [21]. Starte stattdessen mit den Rollen und ihren “Jobs” — die demografischen Merkmale ergeben sich aus den Research-Daten, nicht umgekehrt.

Synthese & Insight-Generierung — über Affinity Mapping hinaus

Hier trennt sich die Spreu vom Weizen. Jeder deutschsprachige Guide erklärt Methoden. Keiner erklärt, was du mit den Daten danach machst. Jon Kolko (2010) identifizierte das Problem in Design Issues: Design-Synthese “appears magical” — sie findet im Kopf des Forschers statt, und nur das Ergebnis wird sichtbar [22]. Genau diesen unsichtbaren Prozess machen wir hier transparent.

Schritt 1: Thematische Analyse und Kodierung

Thematische Analyse geht über Affinity Mapping hinaus. Statt Sticky Notes zu clustern, arbeitest du systematisch durch deine Daten [23]:

1. Alle Daten lesen — komplett, nicht nur die Highlights. Transkripte, Beobachtungsnotizen, Fotos, Artefakte
2. Codes vergeben: Jede relevante Aussage oder Beobachtung bekommt ein Label. Nicht nach Thema, sondern nach Bedeutung: “Workaround-als-Symptom”, “Übergabe-Bruch”, “Emotionale-Belastung”
3. Kandidaten-Themen bilden: Codes, die zusammengehören, werden zu Themen. Ein Thema ist kein Oberbegriff — es ist eine Aussage: “Sachbearbeiter kompensieren Systembrüche durch informelle Tabellen” statt “IT-Probleme”
4. Themen prüfen: Passen alle zugeordneten Codes zum Thema? Gibt es Gegenbeispiele in den Daten? NN/g empfiehlt: Nach dem dritten Schritt eine Pause einlegen, bevor du die Themen evaluierst — Distanz verbessert die Urteilsfähigkeit [23]

Schritt 2: Insight Statements formulieren

Ein Insight ist keine Beobachtung. Eine Beobachtung beschreibt, was passiert. Ein Insight erklärt, warum es passiert und was das bedeutet:

Beobachtung	Insight
”5 von 8 Sachbearbeitern pflegen eine eigene Excel-Tabelle neben dem CRM"	"Das CRM bildet den tatsächlichen Informationsbedarf der Schadenregulierung nicht ab — die Sachbearbeiter haben ein Parallelsystem gebaut, das bei jedem Software-Update gefährdet ist"
"Handwerksbetriebe bestellen freitags für die nächste Woche"	"Der eigentliche ‘Job’ ist nicht Bestellung, sondern Planungssicherheit — die Handwerker wollen sicherstellen, dass ihre Baustelle montags nicht stillsteht”

Die Formel für ein Insight Statement: [Nutzergruppe] + [überraschendes Verhalten oder Bedürfnis] + [zugrundeliegende Ursache] + [Implikation für das Design].

Der häufigste Fehler bei der Insight-Formulierung: Teams verwechseln Beobachtungen mit Insights. “Nutzer wechseln zwischen zwei Programmen” ist eine Beobachtung. Erst wenn du die Ursache und die Implikation hinzufügst, wird es ein Insight. Kolko (2010) beschreibt, warum das so schwer ist: Synthese ist ein abduktiver Prozess — ein Sprung von Daten zu Bedeutung, der sich nicht algorithmisch ableiten lässt [22]. Wenn dein Team nach der Synthese 40 “Insight Statements” produziert hat, die alle mit “Nutzer tun X” beginnen statt mit “Nutzer tun X, weil Y — deshalb Z”, dann sind es noch Beobachtungen.

Schritt 3: Von Insights zu “How Might We”-Fragen

“How Might We” (HMW) ist das Scharnier zwischen Forschung und Gestaltung [2]. Eine gut formulierte HMW-Frage beschreibt die Herausforderung, ohne die Lösung vorwegzunehmen:

• Zu breit: “Wie können wir den Service verbessern?”
• Zu eng: “Wie können wir ein besseres CRM-Feld für die Schadenregulierung bauen?”
• Richtig: “Wie könnten wir sicherstellen, dass alle relevanten Fallinformationen den Sachbearbeitern zur Verfügung stehen, ohne dass sie ein Parallelsystem pflegen müssen?”

Aus den Insight Statements lassen sich HMW-Fragen ableiten, die direkt in die Ideationsphase führen. Die Research-Synthese ist damit abgeschlossen — und die Brücke zur Gestaltung gebaut. Wer nach der Synthese systematisch Lösungsvarianten generieren will, findet im Morphologischen Kasten ein passendes Werkzeug.

Empathy Maps als Synthese-Artefakte

Dave Gray entwickelte die Empathy Map als Synthesewerkzeug — nicht als Workshop-Warm-up [24]. Im B2B-Kontext ergänze jede Eintragung mit dem Vermerk “P” (persönliches Motiv) oder “O” (organisatorisches Motiv). “Angst, eine teure Fehlentscheidung zu treffen” (O) ist etwas anderes als “Angst, vor dem Team das Gesicht zu verlieren” (P) — obwohl beides denselben Stakeholder betrifft [21]. Die Empathy Map macht sichtbar, wo Research-Lücken bestehen: Ein leerer Quadrant zeigt, welche Dimension in der nächsten Forschungsrunde abgedeckt werden muss.

Research-Zugang im Enterprise-Kontext

Bestehende Touchpoints als Research-Kanäle nutzen

Der häufigste Einwand gegen User Research im B2B lautet: “Wir kommen nicht an die Nutzer ran.” Die meisten Unternehmen haben bereits regelmäßige Kundenkontakte — sie nutzen sie nur nicht für Forschung.

Vier Kanäle, die fast jedes B2B-Unternehmen bereits hat:

1. Vertriebsgespräche: Jedes Akquisegespräch enthält Research-Daten — wenn jemand mitschreibt und die richtigen Fragen stellt
2. Support-Tickets: Die Beschwerdedatenbank ist ein Archiv unerfüllter Bedürfnisse, das niemand als Forschungsquelle nutzt
3. Onboarding-Sessions: Der Moment, in dem neue Kunden den Service zum ersten Mal nutzen, ist eine natürliche Beobachtungsgelegenheit
4. Quarterly Business Reviews (QBRs): Strukturierte Kundengespräche, die sich mit minimaler Anpassung um Research-Fragen erweitern lassen

Teresa Torres (2021) definiert Continuous Discovery als “mindestens wöchentliche Touchpoints mit Kunden, durch das Team, das den Service baut” [25]. Für Unternehmen, die neu in Research einsteigen, ist das realistischer als ein großes Forschungsprojekt — weil es vorhandene Kontakte nutzt, statt neue zu schaffen.

DSGVO, NDAs und Compliance navigieren

Deutschland operiert unter einem dreistufigen Datenschutz-Regime, das User Research nicht verhindert, aber die Planung prägt [26]:

1. DSGVO (GDPR): Einwilligung muss frei, spezifisch, informiert und unmissverständlich sein (Art. 7 DSGVO). Vor jeder Datenerhebung einholen — ohne Ausnahme.
2. BDSG (Bundesdatenschutzgesetz): Ergänzt die DSGVO um deutsche Besonderheiten, u. a. für Beschäftigtendaten.
3. TDDDG (ehem. TTDSG): Regelt die Datenverarbeitung bei digitalen Diensten. Seit Mai 2024 in Kraft, inhaltlich weitgehend identisch mit dem TTDSG.

Was das für Research-Praxis bedeutet:

• Aufnahmen: Video- und Audioaufnahmen am Arbeitsplatz erfordern explizite Einwilligung jedes Teilnehmers. In Unternehmen mit Betriebsrat kann zusätzlich eine formale Genehmigung erforderlich sein — Wochen vor dem geplanten Termin einplanen.
• Datenminimierung: Nur erheben, was für die Forschungsfrage nötig ist. Herausforderung: Qualitative Forschung lebt von Kontext, und “notwendig” ist Interpretationssache.
• Drittanbieter: Transkriptionsdienste, Cloud-Speicher und Remote-Research-Plattformen müssen DSGVO-konform sein. Viele US-basierte Tools sind es nicht.
• Aufbewahrung: Rohdaten mit Personenbezug (Aufnahmen, Fotos) nach definierter Frist löschen oder anonymisieren. Die German UPA empfiehlt als Orientierung zwei Jahre [27].

Die German UPA hat mit “Keine Angst vorm Datenschutz” einen Leitfaden veröffentlicht, der den zentralen Punkt klarstellt: “User Research ist weiterhin wie bisher möglich, es müssen allerdings einige Dinge bei Planung, Durchführung und Nachbereitung berücksichtigt werden” [27]. DSGVO-Compliance ist kein Hindernis — sie ist ein Qualitätsmerkmal, das Vertrauen bei Forschungsteilnehmern schafft.

Rekrutierung im B2B: Jenseits von Consumer-Panels

Standardmäßige Testpersonen-Panels funktionieren im B2B nicht. Die Teilnehmer sind hochspezialisierte Fachkräfte, die sich nicht über Online-Anzeigen rekrutieren lassen. Vier Wege, die funktionieren:

1. Account Management als Rekrutierungskanal: Bitte bestehende Account Manager, forschungsbereite Kunden zu identifizieren. Wichtig: Erkläre den AMs, warum die Forschung dem Kunden nützt, nicht nur dem eigenen Unternehmen.
2. Kundenbeiräte und Advisory Boards: Wenn dein Unternehmen einen Kundenbeirat hat, sind dessen Mitglieder ideale Research-Teilnehmer — sie haben bereits ein Interesse an der Weiterentwicklung des Service.
3. Branchenverbände und Fachveranstaltungen: Die German UPA, VDI, VDMA und branchenspezifische Verbände bieten Zugang zu Fachleuten, die sich für Methodenentwicklung interessieren.
4. Incentivierung: B2B-Teilnehmer können oft keine Geldprämien annehmen (Compliance-Regeln). Funktioniert besser: Exklusiver Einblick in die Ergebnisse, frühzeitiger Zugang zu neuen Features, oder ein gemeinsames Mittagessen — der Beziehungsaspekt wiegt im B2B schwerer als der monetäre.

Die 7 häufigsten Research-Fehler

1. Bestätigung statt Entdeckung (Confirmation Bias)

Was schiefgeht: Das Forschungsziel ist nicht Erkenntnis, sondern Bestätigung einer bereits getroffenen Entscheidung. Erika Hall nennt es “Research Theater”: “People waste a lot of time and money going through the motions — because they do the work and write the reports, and decisions are still based on whim or authority, flavored with a little confirmation bias” [29].

Warum: Die Forschungsfrage war nie offen. Halls Lakmusprobe: “Asking questions is a waste of time unless you know your reason for doing so in advance. And you have to publicly swear that your reason is not ‘to be proven right’” [29].

Was stattdessen: Vor dem ersten Interview die Forschungsfrage schriftlich formulieren und mit dem Team teilen. Vereinbare vorab: Wenn die Ergebnisse unserer Hypothese widersprechen, wie werden wir damit umgehen? Wer trifft dann welche Entscheidung? Wenn niemand diese Frage beantworten kann, ist Research zum jetzigen Zeitpunkt Geldverschwendung.

2. Die falschen Teilnehmer befragen

Was schiefgeht: Im B2B wird der Einkaufskontakt befragt, nicht der Sachbearbeiter, der den Service täglich nutzt. Oder nur zufriedene Kunden — weil der Vertrieb den Zugang steuert und kritische Stimmen fernhält.

Warum: M3 Design dokumentiert das Strukturproblem: “R&D employees are not free to contact users directly but are represented by sales organizations responsible for managing the customer interface, however sales organizations do not consider arranging meetings with the end user a high-priority task” [30].

Was stattdessen: Research-Teilnehmer nach Rollen rekrutieren, nicht nach Verfügbarkeit. Mindestens drei der fünf Buying-Center-Rollen abdecken: Nutzer, Entscheider, Gatekeeper. Und mindestens 2-3 ehemalige Kunden oder “Lost Deals” einbeziehen — sie liefern die ehrlichsten Insights.

3. Research ohne Synthese (“Research Theater”)

Was schiefgeht: 12 Interviews geführt, 200 Seiten Transkripte erzeugt, eine 40-seitige Präsentation erstellt. Die Präsentation wird in einer Stunde vorgestellt und dann in einem Ordner abgelegt, den niemand je wieder öffnet. In Enterprise-Projekten kostet dieses Muster 60.000-80.000 EUR und 3-6 Monate — nicht wegen der Forschung selbst, sondern wegen des Services, der danach trotzdem am Nutzer vorbei gebaut wird.

Warum: Es fehlt der Schritt zwischen Datensammlung und Handlung. Kolko (2010) zeigt: Die meisten Teams können Daten sammeln, aber die Synthese — der Weg von Daten zu Insight zu Entscheidung — wird nicht gelehrt und nicht praktiziert [22].

Was stattdessen: Synthese beginnt nach dem ersten Interview, nicht nach dem letzten. Torres (2021) empfiehlt: Führe nach jedem Interview ein 30-Minuten-Debrief mit dem gesamten Projektteam. Wer beim Interview dabei war, teilt die drei wichtigsten Beobachtungen. Wer nicht dabei war, stellt Fragen. So entsteht gemeinsames Verständnis statt einsamer Report [25].

4. Nur eine Methode einsetzen (fehlende Triangulation)

Was schiefgeht: Das Team führt 10 Interviews und behandelt die Aussagen als Fakten. Interviews erfassen, was Menschen sagen — nicht, was sie tun. Die Lücke zwischen beidem ist oft der Ort, an dem die wertvollsten Insights liegen.

Warum: Budgetrestriktionen, Zeitmangel oder Unkenntnis anderer Methoden.

Was stattdessen: Kombiniere mindestens eine Befragungsmethode (Interviews, JTBD-Gespräche) mit einer Beobachtungsmethode (Contextual Inquiry, Service Safari). Triangulation bedeutet nicht “mehr Aufwand”, sondern “verschiedene Blickwinkel auf dasselbe Phänomen”. 5 Interviews + 2 Contextual Inquiries liefern bessere Ergebnisse als 15 Interviews.

5. Den Organisationskontext ignorieren

Was schiefgeht: Der Endnutzer wird perfekt erforscht, aber die internen Strukturen, die den Service erbringen, bleiben unberücksichtigt. Das Ergebnis: Ein Service-Konzept, das für den Kunden ideal ist, aber an internen Silos, IT-Restriktionen oder Compliance-Anforderungen scheitert.

Warum: UX-Denken priorisiert den Endnutzer. Service Design muss zusätzlich die Organisation verstehen, die den Service erbringt.

Was stattdessen: Plane mindestens 30 % der Research-Zeit für interne Forschung ein: Stakeholder-Interviews, Prozessbeobachtung, Dokumentenanalyse. Frag nicht nur “Was braucht der Kunde?”, sondern auch “Was hindert die Organisation daran, es zu liefern?“

6. Erkenntnisse nicht zurückführen

Was schiefgeht: Research-Teilnehmer investieren ihre Zeit, erhalten aber nie Feedback zu den Ergebnissen. Beim nächsten Mal sagen sie ab.

Warum: Die Rückführung von Ergebnissen wird nicht eingeplant. Das Team sieht die Forschung als abgeschlossene Phase, nicht als Beziehung.

Was stattdessen: Plane bei der Rekrutierung bereits die Rückführung ein: “In 6 Wochen teilen wir die zusammengefassten Ergebnisse mit dir.” Torres (2021) macht den Punkt explizit: Continuous Discovery funktioniert nur, wenn Teilnehmer wiederkommen — und sie kommen nur wieder, wenn sie sehen, dass ihre Beiträge Wirkung haben [25]. Im B2B ist diese Rückführung kein Nice-to-have, sondern der Grundstein für die nächste Research-Runde.

7. Zu früh in Lösungen denken

Was schiefgeht: Im dritten Interview sagt ein Kunde “Ich hätte gerne eine App dafür” — und das Team skizziert die App noch am selben Nachmittag. Die Forschung wird abgebrochen, weil man “die Lösung” gefunden hat.

Warum: Erika Hall: “Ask first, prototype later. If we only test bottle openers, we may never realize customers prefer screw-top bottles” [28]. Kunden beschreiben Lösungen in der Sprache der Lösungen, die sie kennen. Der eigentliche “Job” liegt darunter.

Was stattdessen: Notiere jede Lösungsidee aus Interviews — aber verfolge sie nicht sofort. Sammle erst alle Research-Daten, führe die Synthese durch, und prüfe dann, ob die vorgeschlagenen Lösungen tatsächlich den identifizierten “Jobs” entsprechen. Meistens tun sie es nicht.

Häufige Fragen zu User Research im Service Design

Was ist der Unterschied zwischen User Research und UX Research?

UX Research untersucht, wie Nutzer mit einem Interface interagieren — Buttons, Formulare, Navigation. User Research im Service Design erweitert den Fokus auf das gesamte Service-Ökosystem: alle Touchpoints, alle beteiligten Akteure, alle Backstage-Prozesse. In der Praxis sind die Methoden teilweise identisch (Interviews, Beobachtung), aber der Forschungsgegenstand ist breiter [1].

Wie viele Interviews brauche ich?

Es gibt keine universelle Zahl. NN/g empfiehlt: Starte mit 5-6 Teilnehmern pro Nutzersegment und analysiere nach jedem Interview. Wenn nach 3-4 Interviews keine neuen Muster mehr auftauchen, hast du Sättigung erreicht [31]. Griffin und Hauser (1993) fanden, dass 20-30 Interviews 90-95 % aller Kundenbedürfnisse aufdecken. Für ein typisches B2B-Service-Design-Projekt: Plane 12-15 Interviews über alle Stakeholder-Rollen hinweg, mit der Option, bei früher Sättigung zu stoppen. Laura Faulkner (2003) warnt: 5 Testpersonen finden zwischen 55 % und 99 % der Probleme — die Varianz ist enorm [32].

Was ist der Unterschied zwischen JTBD und Personas?

JTBD fragt: “Was versucht der Mensch zu erreichen?” Personas fragen: “Wer ist dieser Mensch?” Beide ergänzen sich: JTBD identifiziert die Bedürfnisse, Personas machen die Menschen greifbar, die diese Bedürfnisse haben. Im B2B-Service-Design brauchst du beides, weil derselbe “Job” von verschiedenen Rollen mit unterschiedlichen Prioritäten verfolgt wird.

Wie überzeuge ich mein Management, in User Research zu investieren?

Reframe Research als Risikominimierung, nicht als Kosten. Die Adobe Mittelstand-Studie 2021 dokumentiert: Mittelstandsunternehmen kennen ihre Kunden “durch langjährige Zusammenarbeit”, aber dieses Wissen skaliert nicht [33]. Konkret: “Wir investieren 15.000 EUR in Forschung, bevor wir 300.000 EUR in einen Service investieren, den möglicherweise keiner braucht.” Im deutschen Engineering-Kontext ist “Risikominimierung” überzeugender als “Nutzerzentrierung”.

Welche Research-Methode ist die richtige für mein Projekt?

Starte mit zwei Fragen: (1) Weißt du, was das Problem ist, oder musst du es erst entdecken? Wenn entdecken: generative Methoden (Contextual Inquiry, JTBD-Interviews). Wenn prüfen: evaluative Methoden (Usability-Tests, Prototypen-Test). (2) Kannst du die Nutzer besuchen? Wenn ja: Beobachtungsmethoden (Contextual Inquiry, Service Safari). Wenn nein: Befragungsmethoden (Remote-Interviews, Tagebuchstudien).

Wie passt User Research in den Integrierten Service Entstehungs Prozess (iSEP)?

Im iSEP bildet User Research das Fundament der Discovery-Phase — aber Research endet dort nicht. In jeder weiteren Phase kehrt das Team zu den Research-Teilnehmern zurück: In Phase 2 werden die Insight Statements aus Phase 1 mit denselben Stakeholdern validiert (“Haben wir das richtig verstanden?”), in Phase 3 werden Service-Prototypen mit denselben Nutzern getestet. Diese Rückspiegelungsschleifen verhindern das häufigste Syntheseproblem: dass Erkenntnisse im Lauf des Projekts unbemerkt verzerrt werden, weil niemand sie gegen die Realität prüft. Ein typischer Zyklus dauert 2-3 Wochen pro Phase.

Methodik & Quellenangabe

Dieser Artikel basiert auf einer systematischen Auswertung von 34 direkt zitierten Quellen: akademische Studien (Holtzblatt & Beyer 1997, Kolko 2010, Segelstrom et al. 2009, Ybema et al. 2009, Faulkner 2003), Fachbücher (Stickdorn et al. 2018, Moesta 2020, Revella 2015, Hall 2019, Portigal 2024, Torres 2021, Cooper 1999), Industrieberichte (Forrester 2024, Adobe 2021), Practitioner-Quellen (NN/g, IDEO, German UPA) und regulatorische Quellen (DSGVO, BDSG, TDDDG). Quellen wurden nach vier Kriterien ausgewählt: Methodenstrenge (empirische Studien bevorzugt), Praxisrelevanz (Service-Design-Kontext priorisiert), Zitationsimpact (höher zitierte Arbeiten stärker gewichtet) und Aktualität (Quellen ab 2015 bevorzugt, klassische Grundlagenwerke ausgenommen). Alle DOIs und URLs wurden vor Aufnahme geprüft. Die SERP-Analyse umfasste 11 deutschsprachige Wettbewerberartikel.

Redaktionelle Einschätzungen (“In der Praxis zeigt sich…”) basieren auf den zitierten Quellen und der Synthese der Forschungsdossiers, nicht auf unveröffentlichten Daten.

Limitationen

• Keine eigenen Wirksamkeitsdaten: Dieser Artikel beschreibt Methoden auf Basis publizierter Quellen. Wir haben keine eigene Studie durchgeführt, die die Wirksamkeit der beschriebenen Kombinationen in deutschen Enterprise-Kontexten misst.
• B2B-Evidenz ist dünn. Die meisten zitierten Studien zu Research-Methoden stammen aus B2C- oder akademischen Kontexten. Die Übertragung auf B2B-Enterprise erfordert Anpassungen, die noch nicht systematisch evaluiert sind.
• JTBD-Debatte unabgeschlossen. Die theoretische Spannung zwischen Ulwick/ODI und Christensen/Moesta ist nicht gelöst. Unsere Empfehlung für den Moesta-Ansatz in der Discovery-Phase basiert auf dem qualitativen Charakter der Service-Design-Forschung, nicht auf einem empirischen Vergleich der beiden Schulen.
• Organisationsethnografie erfordert Expertise. Die Methode ist in der Beschreibung zugänglicher, als sie in der Durchführung ist. Ohne Erfahrung in teilnehmender Beobachtung besteht das Risiko, oberflächliche Eindrücke für tiefe Insights zu halten.
• Nicht abgedeckt: Remote-Research-Methoden für verteilte Teams, quantitative Research-Methoden (Surveys, Analytics), Research-Governance und -Repositories für große Organisationen, und die Integration von Research in agile Entwicklungsprozesse. Jedes dieser Themen verdient eine eigene Behandlung.

Offenlegung

SI Labs berät Unternehmen bei der Gestaltung von Dienstleistungen. Der Integrierte Service Entstehungs Prozess (iSEP) wird im Artikel erwähnt; Leser sollten sich des kommerziellen Interesses bewusst sein. Alle Empfehlungen stützen sich auf publizierte Quellen. Die Grenzen der Methoden sind im Abschnitt Limitationen benannt.

Quellenverzeichnis

[1] Gibbons, Sarah. “UX vs. Service Design.” Nielsen Norman Group, 2021. URL: https://www.nngroup.com/articles/ux-vs-service-design/ [Practitioner Article | Industry Standard | Citations: N/A | Quality: 80/100]

[2] 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: 978-1491927182. [Practitioner Book | 54 Methods | Citations: 1500+ | Quality: 85/100]

[3] SI Labs SERP-Analyse, Februar 2026. 11 deutschsprachige Wettbewerberartikel zu “user research methoden”, “JTBD methode”, “persona erstellen”. [Internal Analysis | N/A | Quality: 60/100]

[4] Rohrer, Christian. “When to Use Which User-Experience Research Methods.” Nielsen Norman Group. URL: https://www.nngroup.com/articles/which-ux-research-methods/ [Practitioner Article | 3-Dimensional Framework | Citations: N/A | Quality: 80/100]

[5] Webster, Frederick E. und Yoram Wind. “A General Model for Understanding Organizational Buying Behavior.” Journal of Marketing 36, Nr. 2 (1972): 12—19. DOI: 10.1177/002224297203600204 [Academic Article | Foundational — Buying Center model | Citations: 5000+ | Quality: 90/100]

[6] Mager, Birgit. The Future of Service Design. TH-Koeln, 2020, S. 34. ISBN 978-3-9818990-6-1. [Academic Monograph | First SD Professor worldwide (1995) | Citations: 50+ | Quality: 75/100]

[7] Holtzblatt, Karen und Hugh Beyer. Contextual Design: Defining Customer-Centered Systems. Morgan Kaufmann, 1997. 2. Aufl. 2017. DOI: 10.1016/B978-0-12-800894-2.00001-6 [Academic Book | Foundational — Contextual Inquiry | Citations: 3000+ | Quality: 88/100]

[8] Nielsen Norman Group. “Contextual Inquiry: Inspire Design by Observing and Interviewing Users in Their Context.” URL: https://www.nngroup.com/articles/contextual-inquiry/ [Practitioner Article | Case study included | Citations: N/A | Quality: 80/100]

[9] Polanyi, Michael. The Tacit Dimension. University of Chicago Press, 1966. [Academic Book | Foundational — Tacit Knowledge | Citations: 30000+ | Quality: 95/100]

[10] Nielsen Norman Group. “Stakeholder Interviews.” URL: https://www.nngroup.com/articles/stakeholder-interviews/ [Practitioner Article | 5 purposes identified | Citations: N/A | Quality: 78/100]

[11] Ybema, Sierk, Dvora Yanow, Harry Wels und Frans H. Kamsteeg (Hrsg.). Organizational Ethnography: Studying the Complexity of Everyday Life. SAGE Publications, 2009. ISBN: 9781847870469. DOI: 10.4135/9781446278925 [Academic Book | Foundational — Organizational Ethnography | Citations: 800+ | Quality: 82/100]

[12] Segelstrom, Fabian, Bas Raijmakers und Stefan Holmlid. “Thinking and Doing Ethnography in Service Design.” Proceedings of IASDR 2009, Seoul. URL: https://www.ida.liu.se/~steho87/iasdr/SegelstromRaijmakersHolmlid.pdf [Academic Article | N=2 case studies | Citations: 100+ | Quality: 72/100]

[13] Klement, Alan. “Know the Two — Very — Different Interpretations of Jobs to be Done.” JTBD.info. URL: https://jtbd.info/know-the-two-very-different-interpretations-of-jobs-to-be-done-5a18b748bd89 [Practitioner Analysis | Theoretical | Citations: N/A | Quality: 65/100]

[14] Moesta, Bob (mit Greg Engle). Demand-Side Sales 101: Stop Selling and Help Your Customers Make Progress. Lioncrest Publishing, 2020. [Practitioner Book | Co-creator of JTBD | Citations: 100+ | Quality: 78/100]

[15] Ulwick, Anthony W. Jobs to be Done: Theory to Practice. IDEA BITE PRESS, 2016. URL: https://jobs-to-be-done-book.com/ [Practitioner Book | ODI Methodology | Citations: 300+ | Quality: 80/100]

[16] Christensen, Clayton M., Taddy Hall, Karen Dillon und David S. Duncan. “Know Your Customers’ ‘Jobs to Be Done’.” Harvard Business Review 94, Nr. 9 (September 2016): 54—62. URL: https://hbr.org/2016/09/know-your-customers-jobs-to-be-done [Practitioner Article | Foundational — JTBD | Citations: 2000+ | Quality: 85/100]

[17] Forrester. The State of Business Buying, 2024. Forrester Research, 2024. n=16.000+ globale B2B-Einkäufer. URL: https://www.forrester.com/press-newsroom/forrester-the-state-of-business-buying-2024/ [Industry Report | n=16.000+ | Citations: N/A | Quality: 82/100]

[18] Cooper, Alan. The Inmates Are Running the Asylum. SAMS/Pearson, 1999. [Practitioner Book | Foundational — Personas | Citations: 5000+ | Quality: 85/100]

[19] Nielsen Norman Group. “B2B vs. B2C Websites: Key UX Differences.” URL: https://www.nngroup.com/articles/b2b-vs-b2c/ [Practitioner Article | Empirical | Citations: N/A | Quality: 78/100]

[20] Revella, Adele (mit Jim Kraus). Buyer Personas: How to Gain Insight into your Customer’s Expectations. Rev. Ed. Wiley, 2024. [Practitioner Book | 5 Rings of Buying Insight | Citations: 200+ | Quality: 78/100]

[21] Persona Institut. “Buyer Center: Warum eine Persona im B2B nicht reicht.” URL: https://www.persona-institut.de/en/buyer-center-warum-eine-persona-im-b2b-nicht-reicht/ [Practitioner Article | DACH-specific | Citations: N/A | Quality: 62/100]

[22] Kolko, Jon. “Abductive Thinking and Sensemaking: The Drivers of Design Synthesis.” Design Issues 26, Nr. 1 (2010): 15—28. DOI: 10.1162/desi.2010.26.1.15 [Academic Article | Theoretical | Citations: 400+ | Quality: 78/100]

[23] Nielsen Norman Group. “Thematic Analysis.” URL: https://www.nngroup.com/articles/thematic-analysis/ [Practitioner Article | Step-by-step guide | Citations: N/A | Quality: 78/100]

[24] Gray, Dave, Sunni Brown und James Macanufo. Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers. O’Reilly Media, 2010. [Practitioner Book | Empathy Map Origin | Citations: 1500+ | Quality: 78/100]

[25] Torres, Teresa. Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value. Product Talk LLC, 2021. [Practitioner Book | Weekly discovery cadence | Citations: 300+ | Quality: 80/100]

[26] TestingTime. “The Ultimate GDPR Guide for UX Researchers.” URL: https://www.testingtime.com/en/blog/gdpr-guide-for-ux/ [Practitioner Article | DACH-focused | Citations: N/A | Quality: 65/100]

[27] German UPA. “Keine Angst vorm Datenschutz.” PDF. URL: https://germanupa.de/sites/default/files/2022-11/gupa_keine_angst_vorm_datenschutz.pdf [Professional Association | DACH-specific | Citations: N/A | Quality: 78/100]

[28] Hall, Erika. Just Enough Research. 2. Aufl. A Book Apart, 2019. [Practitioner Book | Research methodology | Citations: 300+ | Quality: 82/100]

[29] Hall, Erika. “The 9 Rules of Design Research.” Mule Design Blog, 2022. URL: https://www.muledesign.com/blog/the-9-rules-of-design-research [Practitioner Article | Quality: 75/100]

[30] M3 Design. “Contextual User Research Pitfalls.” URL: https://www.m3design.com/contextual-user-research-pitfalls/ [Practitioner Article | B2B-specific | Citations: N/A | Quality: 62/100]

[31] Nielsen Norman Group. “How Many Participants for a UX Interview?” URL: https://www.nngroup.com/articles/interview-sample-size/ [Practitioner Article | Empirical guidance | Citations: N/A | Quality: 78/100]

[32] Faulkner, Laura. “Beyond the Five-User Assumption: Benefits of Increased Sample Sizes in Usability Testing.” Behavior Research Methods, Instruments, & Computers 35, Nr. 3 (2003): 379—383. DOI: 10.3758/BF03195514 [Academic Article | Empirical | Citations: 600+ | Quality: 78/100]

[33] Adobe. “Wie gut kennen mittelstaendische Unternehmen ihre Kunden wirklich?” Adobe Mittelstand Study, 2021. URL: https://business.adobe.com/de/resources/reports/cx-mittelstand.html [Industry Report | DACH-specific | Quality: 60/100]

[34] Portigal, Steve. Interviewing Users: How to Uncover Compelling Insights. 2. Aufl. Rosenfeld Media, 2024. [Practitioner Book | Research interviews | Citations: 200+ | Quality: 80/100]