User Research in Service Design: Methods, JTBD & B2B Practice

Your company launched a new customer portal. The UX tests went smoothly, the interface is modern, the load times are fine. Yet NPS is stagnating. Support tickets are climbing. And in the quarterly meeting, the CEO says: “We did user research.”

You did. But you asked the wrong questions — of the wrong people, at the wrong time. What was tested was the frontstage: buttons, forms, navigation. What was never investigated: why customers use the service in the first place, which internal handoffs between sales and operations break the process, and why the case workers have been relying on a workaround for years that no interview ever captured.

That is the difference between UX research and user research in service design. UX research optimizes touchpoints. Service design research examines the entire service ecosystem — frontstage and backstage, customers and employees, visible interactions and invisible structures [1]. The quality of this research is not determined during data collection, but at three points that no English-language guide adequately addresses: gaining access to the right stakeholders in an enterprise context, synthesizing research data into actionable insights, and distinguishing between research that confirms and research that transforms.

What Is User Research in Service Design?

Sarah Gibbons (Nielsen Norman Group) frames the distinction: UX and service design are “two sides of the same coin” — UX defines what the user experiences, service design orchestrates the internal structures that support that experience [1]. For research, this means: if you only interview the end user, you understand at best half of the problem.

Generative vs. evaluative research

Stickdorn et al. (2018) distinguish two research modes that serve different functions in service design [2]:

Mode	Question	Typical Methods	Phase in the Double Diamond
Generative (exploratory)	What are the actual needs? What problems exist that we don’t yet know about?	Contextual Inquiry, Service Safari, JTBD interviews, stakeholder interviews	Discover
Evaluative (testing)	Does our solution work? Where does it break down?	Usability tests, A/B tests, service prototyping	Deliver

The German SERP landscape addresses almost exclusively evaluative methods — usability tests, surveys, A/B tests [3]. For service innovation, that is too late. Generative research must happen before the first design decision, because it determines what gets built in the first place. Christian Rohrer (NN/g) puts it succinctly: “What people say” and “what people do” are very often fundamentally different — if you only ask instead of observing, you miss precisely the insights that would transform the service [4].

Why service design research differs from product research

Three structural differences:

1. Multiple user types simultaneously. In a B2B context, there is no single “user” — there are users, decision-makers, influencers, buyers, and gatekeepers, each role with different needs [5]. If you only interview the procurement contact, you miss the case worker who uses the service daily.

2. Backstage is part of the research field. A service is delivered by an organization. Internal handoffs, informal workarounds, system breaks between departments — all of this affects service quality but is invisible to the end customer. Birgit Mager (TH Koeln, the world’s first professor for service design) articulates the principle: “You cannot change the frontstage if you don’t impact the backstage” [6].

3. The research object exists in time. You can hold and test a product. A service unfolds over days, weeks, or months — from first contact through usage to cancellation. Research methods must capture this temporal dimension.

The Key Research Methods for Service Design

The following four methods cover the generative research phase in service design. They complement each other: Contextual Inquiry and Service Safari produce observational data, stakeholder interviews unlock organizational knowledge, and organizational ethnography makes invisible structures visible.

Contextual Inquiry — understanding users in context

When to use: When you want to understand how people use a service in their actual work environment — not how they believe they use it.

What it is: Contextual Inquiry is a field research method that Holtzblatt and Beyer systematized in 1997 [7]. The researcher observes and interviews users at their workplace, following the “master-apprentice model”: the user is the master who demonstrates their work; the researcher is the apprentice who watches, listens, and asks targeted questions. The method is based on four principles: context (at the point of use), partnership (exploring together), interpretation (validating interpretations immediately), and focus (staying centered on the research question) [8].

Protocol:

1. Preparation: Define research question, obtain consent (GDPR-compliant — more on this in section 6), prepare observation guide
2. Primer (10 min.): Build rapport, clarify expectations, assure confidentiality
3. Transition: Explicitly switch from conversation to observation mode — “Please show me how you normally proceed”
4. Observation with probing questions (60-90 min.): Alternate between watching and targeted questioning. Validate your own interpretations with the user immediately: “You just switched between two programs — is that always the case?”
5. Wrap-up (10 min.): Summarize the key observations, final corrections from the user

Practical tip: The most common mistake is skipping the transition in step 3. Without an explicit switch, the conversation stays in interview mode — the user summarizes instead of showing. NN/g documents an insurance case that illustrates the problem: data entry workers at a car insurer described their workflow in interviews as simple and straightforward. On-site observation revealed a completely different picture: they routinely switched between two software tools and saved manually after each entry, even though auto-save was active. Both habits were so deeply ingrained that they were never mentioned in any interview [8]. Michael Polanyi called this phenomenon “tacit knowledge” — knowledge so deeply embedded in practice that it cannot be verbalized [9].

Service Safari — experiencing the service yourself

When to use: At the start of every service design project, before the first customer interaction takes place — as a foundation for your own understanding of the service experience.

What it is: In a Service Safari, the design team goes through the service from the customer’s perspective — as a first-time user, not as an analyst [2]. You walk into the bank branch, report a claim, call the hotline, go through onboarding. The goal is not evaluation but experience: How does the service feel when you actually use it?

Protocol:

1. Define scenario: Which service path are we going through? (e.g., “Report a claim as a new customer”)
2. Establish documentation framework: AEIOU framework (Activities, Environments, Interactions, Objects, Users) or TACIT (Thoughts, Actions, Context, Interactions, Touchpoints)
3. Go through the service: Individually or in pairs, with photos, screenshots, and notes. No special treatment — you are a customer, not an auditor
4. Immediate debrief (30 min.): Share emotional highs and lows, document surprises
5. Consolidate findings: Transfer into a preliminary customer journey map

Practical tip: The Service Safari is the most accessible research method — no budget, no recruitment, no external vendor required. And it reliably surprises: when your team goes through a claim report at your own insurance company, wait times, redundant forms, and dead touchpoints surface that appear in no process manual. It complements systematic benchmarking with the experiential perspective: benchmarking compares metrics, the Service Safari compares experiences.

Stakeholder interviews — unlocking organizational knowledge

When to use: When you want to understand how different departments perceive the service, where internal conflicts affect service quality, and which organizational constraints limit design possibilities.

What it is: Structured one-on-one conversations with internal and external stakeholders — not as a project kickoff ritual, but as a standalone research method [10]. NN/g identifies five purposes: neutralize politics, better understand requirements, capture organizational priorities, adapt the design process, and build buy-in [10]. For multi-stakeholder design they are indispensable, because they reveal the different definitions of success across roles.

Protocol:

1. Create interview guide: Maximum 8 open questions, of which 2-3 are cross-role (“What does good service mean for your department?”) and 2-3 are role-specific
2. Plan broad coverage: Not just management — include frontline employees, support, operations, and external partners
3. Conduct one-on-one conversations (45-60 min.): No group interviews. The hierarchical dynamics of German companies distort group statements
4. Immediate notes: Within 30 minutes after the interview, capture the three most important statements
5. Identify cross-patterns: After 5-6 interviews, consolidate recurring themes and contradictions between departments

Practical tip: The most valuable question in a stakeholder interview is not “What works?” but “What happens between your department and the next one when a customer case is handed over?” Handoffs are the fracture points in a service — and they are not documented in any process manual, because they evolved organically.

Steve Portigal (2024) documents a phenomenon that every experienced interviewer knows: the most important information often comes only after the formal interview is over — in the doorway, while walking out, when the record button has theoretically already been pressed [34]. Portigal calls it the “doorknob phenomenon.” The reason: the moment the formal conversation ends, social desirability drops away. The tip: keep the recorder running until you leave the building.

Organizational ethnography — making invisible structures visible

When to use: When interviews and process documentation paint a consistent picture but service quality still suffers — an indication of invisible structures that are only accessible through observation in daily work.

What it is: Organizational ethnography transfers ethnographic methods — participant observation, informal conversations, document analysis — to the corporate context. Ybema et al. (2009) define it as the study of the “gap between how organizations say they work and how they actually work” [11]. Segelstrom, Raijmakers, and Holmlid (2009) showed in two case studies that service designers can successfully employ ethnographic methods, albeit with a different communication focus than classical ethnographers: designers prioritize visual communication of findings, ethnographers prioritize “thick description” [12].

Protocol:

1. Negotiate access: Obtain formal approval (in companies with a works council (Betriebsrat), this can take weeks — plan ahead, do not underestimate)
2. Define observation focus: e.g., handoffs between departments, informal workarounds, communication paths during escalations
3. Participant observation (2-5 days): Shadow the work environment, do not sit in the break room. Conversations arise naturally when you experience the work firsthand
4. Document: Workarounds, sticky notes on monitors, Excel spreadsheets that no system knows about — the artifacts of informal processes
5. Synthesize patterns: Where does lived practice deviate from documented practice? Which informal rules stabilize the service?

Practical tip: The biggest insight from organizational ethnography is almost always what is not in the process documentation. The Excel spreadsheet that a case worker has been maintaining for three years because the official CRM does not capture the information says more about service quality than any process map. If that spreadsheet is eliminated during a system relaunch, a piece of invisible infrastructure collapses.

The methods described so far produce observational and contextual data. But data alone does not tell a story. To derive actionable insights from observations, you need an interpretation framework — and that is exactly what Jobs to be Done provides.

Jobs to be Done (JTBD) as a Research Framework

Two schools — and which one fits service research

JTBD is not a unified framework but two fundamentally different interpretations under the same name [13]:

Dimension	Ulwick / ODI	Christensen / Moesta
Core concept	”Jobs” are activities with measurable outcomes	”Jobs” are the progress someone wants to make in their life
Method	Quantitative: outcome statements, importance-satisfaction surveys	Qualitative: switch interviews, timeline reconstruction
Strength	Systematic, repeatable, quantifiable	Deep understanding of motivation and context
Weakness	Poorly captures emotional and social dimensions	Difficult to scale, subjective interpretation

For service design research, the Moesta/Christensen approach is recommended as a starting point: the qualitative switch interview method uncovers why someone switches service providers or stays — a question that is central to service innovation [14]. Ulwick’s ODI method complements during the prioritization phase, when it becomes necessary to quantify which outcomes are most underserved [15].

JTBD in a B2B context: organizational vs. personal jobs

In a B2B service context, every stakeholder has at least two “jobs” simultaneously: an organizational one and a personal one [16].

Job dimension	Example (insurance)	Example (manufacturing)
Functional	”Accelerate claims processing"	"Reduce machine downtime”
Emotional	”Feel confident that I’m making the right decision"	"Not be the one who ordered the wrong equipment”
Social	”Be seen as innovative by the board"	"Be perceived as reliable by the team”

Most enterprise research projects capture only functional jobs. That is not enough. Forrester (2024, n=16,000+) found: 99% of B2B purchases are triggered by organizational changes, and 86% stall — often because emotional and social concerns of individual stakeholders were never addressed [17]. The question “What happens for you personally if this project fails?” uncovers a dimension that no questionnaire captures.

JTBD interviews for services: the Forces of Progress

Bob Moesta, co-developer of the JTBD framework, operationalized the switch interview technique with the Forces of Progress model [14]:

• F1 — Push (pressure of the current situation): What bothers you so much about the current service that change becomes necessary?
• F2 — Pull (attraction of the new): What does the new service promise that the old one does not?
• F3 — Habit (inertia of the status quo): What keeps the customer with the current provider — despite dissatisfaction?
• F4 — Anxiety (fear of the new): What does the customer fear about switching?

When F1+F2 > F3+F4, the switch happens. In an enterprise context, F3 and F4 are often the dominant forces: organizational inertia, training effort, career risk for the decision-maker, and the sheer complexity of switching providers block progress, even when the current service is poor. The Forrester data supports this observation: 86% of B2B buying processes stall [17] — often not due to budget questions, but to the accumulated anxiety (F4) of those involved.

From JTBD data to the next step: once switch interviews have identified the “jobs” and “forces,” these feed directly into a service blueprint. Each identified “job” is mapped to a touchpoint; each “force” informs which backstage processes must support or counteract.

B2B Personas: Role-Based, Not Demographic

The dual-persona problem: users and decision-makers

Alan Cooper introduced personas as a design tool in 1999 [18]. In a B2B context, a single persona is not enough, because the person who uses a service is almost never the person who buys it. NN/g articulates the key distinction: “Users” (daily operators) and “Choosers” (budget decision-makers) have fundamentally different needs [19].

Adele Revella (2015/2024) operationalizes B2B persona research with the “5 Rings of Buying Insight”: Priority Initiative, Success Factors, Perceived Barriers, Buyer’s Journey, and Decision Criteria [20]. Her recommendation: 8-10 interviews per homogeneous market segment, 30 minutes each, are enough to identify the core patterns.

For the different user types in service design and the in-depth framework for persona and prototype development, we have written separate articles. Here is the core insight for the research phase: before you build personas, clarify for which role you are researching. A research plan that only interviews the buyer produces personas that describe the buyer — not the user.

From the buying center to the service persona

The buying center model (Webster & Wind, 1972) identifies five roles: user, buyer, influencer, decision-maker, and gatekeeper [5]. For service persona research, this means: you do not need five personas, but you need research data from at least three of these roles — user, decision-maker, and gatekeeper as a minimum.

A common mistake: persona creation starts with demographic attributes (age, industry, company size). The Persona Institut explicitly warns: “B2B companies that create only one persona risk ignoring important stakeholders in the buying center” [21]. Start instead with the roles and their “jobs” — the demographic attributes emerge from the research data, not the other way around.

Synthesis & Insight Generation — Beyond Affinity Mapping

This is where the wheat is separated from the chaff. Every German-language guide explains methods. None explains what you do with the data afterward. Jon Kolko (2010) identified the problem in Design Issues: design synthesis “appears magical” — it takes place inside the researcher’s head, and only the result becomes visible [22]. We make this invisible process transparent here.

Step 1: Thematic analysis and coding

Thematic analysis goes beyond affinity mapping. Instead of clustering sticky notes, you work systematically through your data [23]:

1. Read all data — completely, not just the highlights. Transcripts, observation notes, photos, artifacts
2. Assign codes: Every relevant statement or observation gets a label. Not by topic, but by meaning: “workaround-as-symptom,” “handoff-break,” “emotional-burden”
3. Form candidate themes: Codes that belong together are grouped into themes. A theme is not a category label — it is a statement: “Case workers compensate for system breaks through informal spreadsheets” rather than “IT problems”
4. Review themes: Do all assigned codes fit the theme? Are there counterexamples in the data? NN/g recommends: take a break after the third step before evaluating the themes — distance improves judgment [23]

Step 2: Formulating insight statements

An insight is not an observation. An observation describes what happens. An insight explains why it happens and what it means:

Observation	Insight
”5 of 8 case workers maintain their own Excel spreadsheet alongside the CRM"	"The CRM does not capture the actual information needs of claims processing — the case workers have built a parallel system that is at risk with every software update"
"Tradespeople order on Fridays for the following week"	"The actual ‘job’ is not ordering but planning certainty — the tradespeople want to make sure their job site doesn’t stand still on Monday”

The formula for an insight statement: [User group] + [surprising behavior or need] + [underlying cause] + [implication for design].

The most common mistake in insight formulation: teams confuse observations with insights. “Users switch between two programs” is an observation. Only when you add the cause and the implication does it become an insight. Kolko (2010) describes why this is so difficult: synthesis is an abductive process — a leap from data to meaning that cannot be derived algorithmically [22]. If your team has produced 40 “insight statements” after synthesis, and they all begin with “Users do X” rather than “Users do X because Y — therefore Z,” then they are still observations.

Step 3: From insights to “How Might We” questions

“How Might We” (HMW) is the hinge between research and design [2]. A well-formulated HMW question describes the challenge without preempting the solution:

• Too broad: “How might we improve the service?”
• Too narrow: “How might we build a better CRM field for claims processing?”
• Just right: “How might we ensure that all relevant case information is available to case workers without them having to maintain a parallel system?”

Insight statements can be translated into HMW questions that lead directly into the ideation phase. The research synthesis is then complete — and the bridge to design is built. For those who want to systematically generate solution variants after synthesis, the morphological box is a fitting tool.

Empathy maps as synthesis artifacts

Dave Gray developed the empathy map as a synthesis tool — not as a workshop warm-up [24]. In a B2B context, annotate every entry with “P” (personal motive) or “O” (organizational motive). “Fear of making an expensive wrong decision” (O) is different from “Fear of losing face in front of the team” (P) — even though both apply to the same stakeholder [21]. The empathy map reveals where research gaps exist: an empty quadrant shows which dimension must be covered in the next research round.

Research Access in an Enterprise Context

Using existing touchpoints as research channels

The most common objection to user research in B2B is: “We can’t reach the users.” Most companies already have regular customer contacts — they just don’t use them for research.

Four channels that almost every B2B company already has:

1. Sales conversations: Every acquisition meeting contains research data — if someone takes notes and asks the right questions
2. Support tickets: The complaints database is an archive of unmet needs that nobody uses as a research source
3. Onboarding sessions: The moment new customers use the service for the first time is a natural observation opportunity
4. Quarterly Business Reviews (QBRs): Structured customer conversations that can be extended with research questions with minimal adjustment

Teresa Torres (2021) defines Continuous Discovery as “at least weekly touchpoints with customers, by the team building the service” [25]. For companies new to research, this is more realistic than a large research project — because it uses existing contacts rather than creating new ones.

Navigating GDPR (DSGVO), NDAs, and compliance

Germany operates under a three-tier data protection regime that does not prevent user research but shapes how you plan it [26]:

1. GDPR (DSGVO): Consent must be freely given, specific, informed, and unambiguous (Art. 7 GDPR). Obtain it before any data collection — without exception.
2. BDSG (Federal Data Protection Act): Supplements the GDPR with German-specific provisions, including for employee data.
3. TDDDG (Telecommunications Digital Services Data Protection Act): Regulates data processing for digital services. In effect since May 2024, substantively largely identical to its predecessor, the TTDSG.

What this means for research practice:

• Recordings: Video and audio recordings in the workplace require explicit consent from every participant. In companies with a works council (Betriebsrat), formal approval may additionally be required — plan weeks ahead of the scheduled date.
• Data minimization: Only collect what is necessary for the research question. The challenge: qualitative research depends on context, and “necessary” is a matter of interpretation.
• Third-party providers: Transcription services, cloud storage, and remote research platforms must be GDPR-compliant. Many US-based tools are not.
• Retention: Delete or anonymize raw data containing personal information (recordings, photos) after a defined period. The German UPA recommends two years as a guideline [27].

The German UPA published a guide titled “Keine Angst vorm Datenschutz” (“No fear of data protection”) that makes the central point clear: “User research remains possible as before; however, certain aspects must be considered during planning, execution, and follow-up” [27]. GDPR compliance is not an obstacle — it is a quality marker that builds trust with research participants.

B2B recruitment: beyond consumer panels

Standard test-participant panels do not work in B2B. The participants are highly specialized professionals who cannot be recruited through online ads. Four approaches that work:

1. Account management as a recruitment channel: Ask existing account managers to identify research-willing customers. Important: explain to the AMs why the research benefits the customer, not just your own company.
2. Customer advisory boards: If your company has a customer advisory board, its members are ideal research participants — they already have an interest in the service’s evolution.
3. Industry associations and professional events: The German UPA, VDI, VDMA, and industry-specific associations provide access to professionals interested in methodological development.
4. Incentivization: B2B participants often cannot accept monetary rewards (compliance rules). What works better: exclusive access to the results, early access to new features, or a shared lunch — the relationship aspect outweighs the monetary one in B2B.

The 7 Most Common Research Mistakes

1. Confirmation instead of discovery (confirmation bias)

What goes wrong: The research goal is not insight but confirmation of a decision already made. Erika Hall calls it “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].

Why: The research question was never open. Hall’s litmus test: “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].

What to do instead: Before the first interview, formulate the research question in writing and share it with the team. Agree in advance: if the results contradict our hypothesis, how will we deal with it? Who makes which decision then? If nobody can answer that question, research at this point is a waste of money.

2. Interviewing the wrong participants

What goes wrong: In B2B, the procurement contact is interviewed, not the case worker who uses the service daily. Or only satisfied customers — because sales controls the access and keeps critical voices at bay.

Why: M3 Design documents the structural problem: “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].

What to do instead: Recruit research participants by role, not by availability. Cover at least three of the five buying center roles: user, decision-maker, gatekeeper. And include at least 2-3 former customers or “lost deals” — they deliver the most honest insights.

3. Research without synthesis (“research theater”)

What goes wrong: 12 interviews conducted, 200 pages of transcripts produced, a 40-page presentation created. The presentation is delivered in one hour and then filed in a folder that nobody ever opens again. In enterprise projects, this pattern costs EUR 60,000-80,000 and 3-6 months — not because of the research itself, but because of the service that is then built past user needs anyway.

Why: The step between data collection and action is missing. Kolko (2010) shows: most teams can collect data, but synthesis — the path from data to insight to decision — is neither taught nor practiced [22].

What to do instead: Synthesis starts after the first interview, not after the last. Torres (2021) recommends: conduct a 30-minute debrief with the entire project team after each interview. Whoever was present at the interview shares the three most important observations. Whoever was not present asks questions. This creates shared understanding rather than a solitary report [25].

4. Using only one method (lack of triangulation)

What goes wrong: The team conducts 10 interviews and treats the statements as facts. Interviews capture what people say — not what they do. The gap between the two is often where the most valuable insights lie.

Why: Budget constraints, time pressure, or unfamiliarity with other methods.

What to do instead: Combine at least one inquiry method (interviews, JTBD conversations) with one observation method (Contextual Inquiry, Service Safari). Triangulation does not mean “more effort” but “different perspectives on the same phenomenon.” 5 interviews + 2 Contextual Inquiries deliver better results than 15 interviews.

5. Ignoring the organizational context

What goes wrong: The end user is perfectly researched, but the internal structures that deliver the service are left out. The result: a service concept that is ideal for the customer but fails because of internal silos, IT constraints, or compliance requirements.

Why: UX thinking prioritizes the end user. Service design must additionally understand the organization that delivers the service.

What to do instead: Plan at least 30% of research time for internal research: stakeholder interviews, process observation, document analysis. Do not just ask “What does the customer need?” but also “What prevents the organization from delivering it?“

6. Not feeding back findings

What goes wrong: Research participants invest their time but never receive feedback on the results. Next time, they decline.

Why: Returning results is not planned for. The team views research as a completed phase, not a relationship.

What to do instead: Plan the feedback loop during recruitment: “In 6 weeks, we will share the summarized results with you.” Torres (2021) makes the point explicitly: Continuous Discovery only works if participants come back — and they only come back if they see that their contributions made a difference [25]. In B2B, this feedback loop is not a nice-to-have but the foundation for the next research round.

7. Jumping to solutions too early

What goes wrong: In the third interview, a customer says “I’d like an app for that” — and the team sketches the app that same afternoon. Research is abandoned because the team has “found the solution.”

Why: Erika Hall: “Ask first, prototype later. If we only test bottle openers, we may never realize customers prefer screw-top bottles” [28]. Customers describe solutions in the language of solutions they already know. The actual “job” lies underneath.

What to do instead: Note every solution idea from interviews — but do not pursue them immediately. Collect all research data first, conduct the synthesis, and then check whether the proposed solutions actually match the identified “jobs.” Usually, they do not.

Frequently Asked Questions About User Research in Service Design

What is the difference between user research and UX research?

UX research examines how users interact with an interface — buttons, forms, navigation. User research in service design expands the focus to the entire service ecosystem: all touchpoints, all actors involved, all backstage processes. In practice, the methods are partly identical (interviews, observation), but the research object is broader [1].

How many interviews do I need?

There is no universal number. NN/g recommends: start with 5-6 participants per user segment and analyze after each interview. If no new patterns emerge after 3-4 interviews, you have reached saturation [31]. Griffin and Hauser (1993) found that 20-30 interviews uncover 90-95% of all customer needs. For a typical B2B service design project: plan 12-15 interviews across all stakeholder roles, with the option to stop at early saturation. Laura Faulkner (2003) cautions: 5 test participants find between 55% and 99% of problems — the variance is enormous [32].

What is the difference between JTBD and personas?

JTBD asks: “What is the person trying to achieve?” Personas ask: “Who is this person?” The two complement each other: JTBD identifies the needs, personas make the people who have those needs tangible. In B2B service design, you need both, because the same “job” is pursued by different roles with different priorities.

How do I convince my management to invest in user research?

Reframe research as risk mitigation, not cost. The Adobe Mittelstand Study 2021 documents: Mittelstand companies know their customers “through years of collaboration,” but this knowledge does not scale [33]. Concretely: “We are investing EUR 15,000 in research before we invest EUR 300,000 in a service that possibly nobody needs.” In a German engineering context, “risk mitigation” is more persuasive than “user-centricity.”

Which research method is right for my project?

Start with two questions: (1) Do you know what the problem is, or do you need to discover it first? If discover: generative methods (Contextual Inquiry, JTBD interviews). If test: evaluative methods (usability tests, prototype testing). (2) Can you visit the users? If yes: observation methods (Contextual Inquiry, Service Safari). If no: inquiry methods (remote interviews, diary studies).

How does user research fit into the Integrated Service Development Process (iSEP)?

In iSEP, user research forms the foundation of the discovery phase — but research does not end there. In each subsequent phase, the team returns to the research participants: in Phase 2, the insight statements from Phase 1 are validated with the same stakeholders (“Did we understand this correctly?”); in Phase 3, service prototypes are tested with the same users. These feedback loops prevent the most common synthesis problem: insights becoming distorted unnoticed over the course of the project because nobody checks them against reality. A typical cycle takes 2-3 weeks per phase.

Methodology & Source Notes

This article is based on a systematic review of 34 directly cited sources: academic studies (Holtzblatt & Beyer 1997, Kolko 2010, Segelstrom et al. 2009, Ybema et al. 2009, Faulkner 2003), practitioner books (Stickdorn et al. 2018, Moesta 2020, Revella 2015, Hall 2019, Portigal 2024, Torres 2021, Cooper 1999), industry reports (Forrester 2024, Adobe 2021), practitioner sources (NN/g, IDEO, German UPA), and regulatory sources (GDPR, BDSG, TDDDG). Sources were selected according to four criteria: methodological rigor (empirical studies preferred), practical relevance (service design context prioritized), citation impact (more highly cited works weighted more strongly), and recency (sources from 2015 onward preferred, foundational works excepted). All DOIs and URLs were verified before inclusion. The SERP analysis covered 11 German-language competitor articles.

Editorial assessments (“In practice…”) are based on the cited sources and the synthesis of research dossiers, not on unpublished data.

Limitations

• No proprietary efficacy data: This article describes methods based on published sources. We have not conducted our own study measuring the effectiveness of the described combinations in German enterprise contexts.
• B2B evidence is thin. Most cited studies on research methods come from B2C or academic contexts. Transferring them to B2B enterprise requires adaptations that have not yet been systematically evaluated.
• The JTBD debate is unresolved. The theoretical tension between Ulwick/ODI and Christensen/Moesta is not settled. Our recommendation for the Moesta approach in the discovery phase is based on the qualitative character of service design research, not on an empirical comparison of the two schools.
• Organizational ethnography requires expertise. The method is more accessible in description than in execution. Without experience in participant observation, there is a risk of mistaking superficial impressions for deep insights.
• Not covered: Remote research methods for distributed teams, quantitative research methods (surveys, analytics), research governance and repositories for large organizations, and the integration of research into agile development processes. Each of these topics deserves its own treatment.

Disclosure

SI Labs advises companies on service design. The Integrated Service Development Process (iSEP) is mentioned in this article; readers should be aware of the commercial interest. All recommendations are grounded in published sources. The limitations of the methods are stated in the Limitations section.

References

[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 Analysis, February 2026. 11 German-language competitor articles on “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, p. 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. 2nd ed. 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 (eds.). 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 (with 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+ global B2B buyers. 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 (with 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. 2nd ed. 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. 2nd ed. Rosenfeld Media, 2024. [Practitioner Book | Research interviews | Citations: 200+ | Quality: 80/100]