Service Prototyping in Service Design: Methods, Fidelity Framework & Practice

Your team has spent six months working on a new claims settlement process. The strategy is in place, the Service Blueprint is documented, IT has given the green light. At rollout, it turns out: customers don’t understand the new online form, the claims adjusters bypass the intended process with an old workaround, and the external surveyor service delivers results in a format the system can’t process. Six months of work, three problems that a two-day test with real participants would have uncovered.

This is not a planning failure — it is a testing failure. And it happens in German companies more often than most will admit. Fraunhofer IAO estimated the failure rate of new services at over 50% in their first year as early as 2012 [1]. The cause is rarely a wrong idea. It is an idea that was never tested under realistic conditions before it went into the organization. Service prototyping rarely fails because of the wrong method — it fails because of the missing connection between the hypothesis in the blueprint, the fidelity level of the test, and the target audience being tested.

Service prototyping closes this gap. But not the way you might know it from product prototyping. Services cannot be touched, stored, or tested in isolation. They emerge from the interplay of people, processes, and systems — and they unfold over time. That is precisely why you need a different tool than a 3D model or a Figma click dummy.

This article gives you a complete framework: what distinguishes service prototyping from product prototyping, six methods along a fidelity framework, the path from the Service Blueprint to a testable prototype, the design of a controlled pilot, and the six mistakes experienced practitioners observe most frequently. At the end is a compliance section that no international prototyping guide offers: what you need to consider regarding GDPR (DSGVO) and the works council (Betriebsrat) in German companies.

What Is Service Prototyping — and Why Isn’t Product Prototyping Enough?

Service prototyping is the simulation of future service experiences before the service exists [2]. Johan Blomkvist (Linkoping University) defines service prototypes as representations of “future service situations” — staged encounters that simulate an experience unfolding over time [2]. The crucial difference from product prototyping: you are not testing an object. You are testing an experience.

Marion Buchenau and Jane Fulton Suri (IDEO) coined the term “Experience Prototyping” in 2000 and formulated the core principle: “Experience Prototyping enables design teams, users, and clients to experience future conditions through active participation in the prototype firsthand” [3]. Not observing — experiencing. This distinction sounds subtle but changes everything about the method: instead of inspecting an artifact, you live through a situation.

Why Your Product Prototyping Muscle Doesn’t Apply Here

Services differ from products in three dimensions that fundamentally change prototyping:

Dimension	Product	Service	Consequence for Prototyping
Intangibility	You can touch, turn, and test the product	The service exists only at the moment of delivery	You must simulate the experience, not build an object
Temporal extension	The prototype exists in a single moment	A service unfolds over hours, days, or weeks	A single test moment captures only a fraction
Co-production	The user uses the product	The user co-produces the service (providing information, keeping appointments, making decisions)	You need real participants, not just observers

A Customer Journey Map visualizes this temporal extension from the customer’s perspective — the service prototype makes it tangible.

Blomkvist identified eight perspectives in his dissertation that characterize a service prototype: purpose, fidelity, audience, position in the process, technique, representation, validity, and authorship [2] — building on the six-perspective framework he published with Holmlid in 2011 [4]. The last two — how validly the prototype represents the real service experience and who creates it — are specific to services and absent from every product prototyping framework.

In the Double Diamond of Service Design, prototyping belongs in the Deliver phase: you have understood the problem (Discover), defined the solution space (Define), developed ideas (Develop) — and are now testing whether the most promising idea works in reality. But unlike product testing, you are not only testing whether the solution works, but whether the organization can deliver it.

6 Methods in the Fidelity Framework: From Sketch to Live Test

The following systematic framework arranges six service prototyping methods along increasing fidelity. Each level answers different questions and requires different resources. The logic: start as low as possible, increase fidelity only when the current level can no longer answer your question [5]. The dimenSion research project (KIT/Hochschule Furtwangen) has systematized this selection process and provides a multidimensional evaluation model for method selection [33].

Desktop Walkthrough (Low Fidelity)

What it is: A miniature simulation of the entire service experience on a table. You use figurines, LEGO, paper props, and sticky notes to move customers, employees, and systems through the service — step by step, from first contact to outcome [6].

When to use: At the beginning. When you want to walk through a service concept for the first time, find gaps in the logic, and bring the team to a shared understanding. The desktop walkthrough is faster than any other method and requires zero infrastructure.

Protocol:

1. Define scope and test questions: What do you want to learn from the walkthrough?
2. Prepare workspace: flipchart paper on a table, sticky notes for stations and touchpoints
3. Assign figurines: one figurine per role (customer, claims adjuster, surveyor, system)
4. Distribute roles: Who speaks for which figurine? Who documents insights?
5. Walk through: move figurines through the journey, speak dialogues aloud, make handoffs explicit
6. Iterate: after each run, collect insights, test variations (3-5 runs are typical)

Practical tip: Watch for “teleportation” — moments when a figurine suddenly appears at a different location without anyone explaining how it got there. Every teleportation marks a gap in the service design that will become a handoff without an owner in real operations [6]. Stickdorn et al. recommend playing every walkthrough through to the end consistently, even when problems arise: “Don’t interrupt to discuss — simulate the discussion point instead” [5].

Resources: 3-6 people, 1-2 hours, materials: under 50 EUR.

---

Storyboard & Service Scenario (Low Fidelity)

What it is: A sequential visual narrative of the service experience — like a comic strip that shows the interaction from the customer’s perspective. Each panel captures a moment: What happens? What does the customer feel? What happens in the background? [5]

When to use: When you need to communicate a service concept before it is tested. Storyboards are excellent for stakeholder alignment — they make the invisible service experience tangible without anyone having to act out the service. They also help anticipate the emotional dimension of a service, which a desktop walkthrough alone can only capture with difficulty.

Protocol:

1. Define protagonist: Who is the customer? In what context do they encounter the service?
2. Identify key moments: 6-12 panels covering the service from trigger to outcome
3. Draw frontstage and backstage in parallel: upper panel half = what the customer experiences; lower = what the organization does
4. Add emotional indicators: How does the customer feel at each point?
5. Review with team: Where are steps missing? Where are unrealistic assumptions?

Practical tip: Drawing quality is irrelevant. The rougher the storyboard, the more honest the feedback. IDEO puts it this way: low-fidelity prototypes invite honest feedback because they look changeable [7]. A professionally designed storyboard signals “finished” — and stakeholders hold back criticism.

Resources: 1-3 people, 1-2 hours, materials: paper and pens.

---

Role Play / Bodystorming (Medium Fidelity)

What it is: Participants physically act out the service — they step into the roles of customers, employees, and partners and enact the service process in a real or simulated environment [8]. Bodystorming combines empathy, brainstorming, and prototyping in a single exercise: instead of talking about the service, you experience it with your own body [3].

When to use: When you want to test the interaction quality between people — tone of voice, timing, emotional dynamics, handoffs between roles. The desktop walkthrough shows you the logic; the role play shows you how the service feels. Adam Lawrence (co-author of This Is Service Design Doing) emphasizes: Investigative Rehearsal, a structured form of role play, is “a significantly more powerful tool than simple role play” because it creates a “special mental space” for genuine discovery [5].

Protocol:

1. Define roles: Who plays the customer? Who plays the employee? Who observes?
2. Brief the scenario: initial situation, customer need, expected flow
3. Prepare props: forms, screen mockups, phone, queue number — everything that establishes the service context
4. Act it out: let the scene run without interruption (5-15 minutes per run)
5. Debrief: What worked? What was uncomfortable? Where did the service break down?
6. Variation: same scenario with swapped roles or changed initial conditions

Practical tip: The most common resistance in German enterprise contexts: “We don’t do role plays here.” Call it “service simulation” or “process rehearsal” instead — the method is the same, but acceptance measurably increases when you avoid theatrical vocabulary [5]. Fraunhofer IAO uses the term “Service Theater” in their ServLab in Stuttgart — one of the few dedicated service prototyping labs worldwide, alongside the SINCO Lab at the University of Lapland [9].

Resources: 4-8 people, 2-4 hours, materials: props as needed.

---

Wizard of Oz (Medium-High Fidelity)

What it is: The user interacts with a service that appears automated or system-driven but is actually controlled by a human behind the scenes [10]. The name comes from L. Frank Baum’s novel: behind the impressive system sits a person pulling the strings. The method originates from HCI research (Dahlback, Jonsson & Ahrenberg 1993) and was originally developed to test natural language interfaces before the technology existed [10].

When to use: When you want to test whether an automated or AI-driven service process works from the user’s perspective — without actually building the automation. Typical use cases: chatbot experiences, automated recommendation systems, intelligent claims processing, automatic classification of requests. The method is particularly valuable when the technology is expensive or time-consuming to develop and you want to know before investing whether users will accept the outcome.

Protocol (after NN/g) [11]:

1. Create prototype: build a frontend or interface that looks “real” to the user
2. Define response mode: pre-scripted responses (closed), improvised responses (open), or hybrid
3. Define wizard protocol: response times, answer logic, escalation rules
4. Prepare wizard: the person behind the curtain must understand the concept and respond consistently
5. Internal pilot test: test with colleagues first to find technical and logistical problems
6. Test with real users: 5-8 sessions, ideally 1:1 with think-aloud protocol

Practical tip: Don’t confuse Wizard of Oz with the Concierge MVP. In Wizard of Oz, the user does not know that a human is behind the system — you are testing the system design. In the Concierge MVP — a concept from Eric Ries’ Lean Startup methodology [32] — the user knows that a human is delivering the service — you are testing the value proposition [11]. In GDPR-sensitive contexts, Wizard of Oz requires careful ethical consideration (more on this in the compliance section).

Resources: 2-4 people, 1-2 days preparation, 1-week testing phase.

---

Experience Prototype (High Fidelity)

What it is: A live simulation of the service experience in an environment that comes as close as possible to the real usage situation [3]. Instead of using miniature figurines or role-play scripts, real users live through the service in an environment that resembles the actual service setting — with real or realistic touchpoints, real employees, and a flow that simulates real-world conditions.

When to use: When you want to validate the holistic service experience — not individual touchpoints, but the interplay of all elements across a coherent flow. Experience prototyping is the last stop before the pilot: here you test whether the experience works as a whole, not just the individual building blocks. Polaine, Lovlie, and Reason underscore the connection: only at this fidelity level can experience quality and measurable service metrics be linked [31].

Protocol:

1. Recreate service environment or use real environment (e.g., an empty office as a branch, a conference room as a consulting setting)
2. Prepare all touchpoints: forms, digital interfaces, physical evidence
3. Staff employee roles with real or trained employees
4. Define scenarios: standard case, exception case, complaint case
5. Invite participants: ideally real customers or representative users
6. Run + observe: researchers observe and document, do not intervene
7. Debrief with participants: What was convincing? What was confusing? What was missing?

Practical tip: The most famous experience prototyping example comes from Livework Studio and the Norwegian insurer Gjensidige: in 200+ interviews, customers said they wanted a simpler contract. Livework prototyped a one-page contract — and the reaction in the experience prototype was the opposite: customers didn’t trust a one-page insurance document [12]. No interview, survey, or desktop walkthrough could have delivered this result. It revealed the difference between what people say and what they do when they actually experience it.

Resources: 5-10 people, 2-5 days preparation, 1-3 days execution.

---

Live Service Pilot (Highest Fidelity)

What it is: A controlled live test of the service under real conditions — with real customers, real staff, real systems — but in a limited scope (region, customer segment, time period). The pilot marks the transition from “Does the concept work?” to “Does this work under operating conditions?” (Details on pilot design in the next section.)

When to use: When previous prototype tests have validated the concept and you now need to answer the operational questions: Can our employees deliver the service at scale? Is the cost structure viable? Do the IT systems perform under load? Do real customers accept the service once the novelty euphoria has faded?

Practical tip: A pilot is not a “soft launch.” A pilot has defined success criteria, a fixed time period, a controlled participant group, and a planned end. Without these elements, it is an uncontrolled rollout disguised as an experiment — and the most common form of “innovation theater” [13].

Resources: Depends on service scope; typical: 4-12 weeks, dedicated team.

---

Decision Matrix: Which Method for Which Test Goal?

Method	Test Goal	Fidelity	Participants	Time	Cost
Desktop Walkthrough	Concept logic, process gaps, team alignment	Low	3-6 internal	1-2 h	< 50 EUR
Storyboard	Stakeholder communication, emotional arc	Low	1-3 internal	1-2 h	< 20 EUR
Role Play / Bodystorming	Interaction quality, handoffs, tone of voice	Medium	4-8 internal	2-4 h	< 200 EUR
Wizard of Oz	Automation assumptions, system design	Medium-High	2-4 + 5-8 users	1-2 wk.	1,000-5,000 EUR
Experience Prototype	Holistic experience, frontstage + backstage	High	5-10 + users	3-8 days	2,000-10,000 EUR
Live Service Pilot	Operational feasibility, scalability, business case	Highest	Real team + real customers	4-12 wk.	10,000+ EUR

Ground rule: Start at the lowest fidelity level that can answer your current question. Increase fidelity only when the previous level no longer yields new insights. Stickdorn et al. formulate the economic principle: “The best prototype is the one that makes the possibilities and limitations of a design idea visible and measurable in the simplest and most efficient way” [5].

From Service Blueprint to Prototype: Deriving and Testing Hypotheses

If you have already created a Service Blueprint, you are sitting on a goldmine of testable hypotheses. Every layer of the blueprint — Customer Actions, Frontstage, Backstage, Support Processes — contains assumptions about how the service will work. Prototyping is the method you use to systematically verify these assumptions before turning them into a live service.

Blueprint Layers as Hypothesis Source

Each blueprint component generates a different type of hypothesis:

Blueprint Layer	Example Hypothesis	Prototyping Method
Customer Actions	”Customers will be able to fill out the online form without instructions”	Wizard of Oz, Experience Prototype
Frontstage Actions	”The claims adjuster can explain the damage assessment within 10 minutes”	Role Play
Backstage Actions	”The handoff between the claims department and the surveyor service works without a media break”	Desktop Walkthrough
Support Processes	”The document management system can automatically assign damage photos”	Wizard of Oz
Physical Evidence	”The confirmation email gives the customer enough information not to call the call center”	Storyboard, Experience Prototype

Frontstage vs. Backstage Tests

The most common mistake when transitioning from blueprint to prototype: teams test only the frontstage — the visible customer interaction — and ignore the backstage processes [14]. Fabian Segelstrom (Linkoping University) pointed out in his research that service visualizations systematically emphasize visible touchpoints and neglect invisible structures [14]. The result: a “Potemkin village” — a facade that looks good in testing but collapses in reality because the backstage processes were never tested.

Countermeasure: For every frontstage test, plan at least one backstage test. When you test whether the customer understands the online form (frontstage), simultaneously test whether the completed dataset is correctly transferred to the backstage systems. A service prototype that only tests the stage is testing at best 30% of the service.

Practice: How to Derive 3 Testable Hypotheses from a Blueprint

Step 1: Identify the riskiest assumption. Go through your blueprint and ask at each step: “What happens if this doesn’t work?” The steps with the highest damage potential and the greatest uncertainty are your prototyping candidates.

Step 2: Formulate the hypothesis as a testable statement. Not: “Claims settlement should be fast.” But rather: “We believe that customers can complete the digital claims reporting process without phone support in under 8 minutes. We know we are right if 7 out of 10 test participants complete the process without assistance.”

Step 3: Choose the lowest fidelity that can test the hypothesis. The question “Does the customer understand the process flow?” doesn’t require a functional digital prototype — a storyboard or desktop walkthrough is sufficient. The question “Can the customer tell the difference between automated and manual processing?” requires Wizard of Oz.

The insights from User Research provide the raw data for these hypotheses. The blueprint structure gives you the systematic framework. The prototype delivers the evidence.

Pilot Design: From Prototype to Controlled Market Launch

Prototype vs. Pilot — Where Is the Boundary?

Dimension	Prototype	Pilot
Goal	”Does the concept work?"	"Does this work under operating conditions?”
Participants	Internal + selected test users	Real customers in real context
Fidelity	Low to high (simulated)	Real (real systems, real employees)
Duration	Hours to days	Weeks to months
Consequence of failure	Learning effect, no damage	Real damage possible (customer loss, reputational risk)
Outcome	Qualitative insights, design decisions	Quantitative data, scaling decision

Tim Brown (IDEO) describes the prototyping process as “build to think” — prototypes are thinking tools, not deliverables [15]. The pilot marks the point where thinking ends and validation under real conditions begins. Stefan Thomke (HBS) makes a useful distinction: a prototype that yields a negative result is a success (learning effect). A pilot that yields a negative result is a signal for a hard decision [16].

Defining Pilot Scope: Time Period, User Group, Success Metrics

A pilot without a defined scope is not a pilot — it is an uncontrolled rollout. Three elements must be established before launch:

1. Participant group: Who participates? In a B2B context, this means not just “which customers” but “which roles in the buying process” [17]. If your service involves a buyer, an operational user, and an IT director, all three roles must be represented in the pilot. Test decision-makers and operational users in separate rounds: the question of whether a service is desirable (buying decision) is different from whether it works in daily use (usage experience). Anyone who tests both in a single session gets honest answers from neither group. Test with at least one “skeptical stakeholder” — someone who did not volunteer to participate and represents the silent majority. And bypass account manager gatekeeping: AMs instinctively select customers with stable relationships and exclude exactly those who would give the most honest feedback — the ones who filed a complaint last time.

2. Time period: Long enough for the novelty effect to wear off. NN/g documents that the novelty effect typically subsides after one to two weeks [18]. If your metrics are still stable after a month, you probably have a real signal. For B2B services with long cycles (onboarding, claims settlement), you must cover at least one complete cycle.

3. Success metrics: What needs to happen for you to scale? What needs to happen for you to stop? Define both before launch. Typical metrics: completion rate, processing time, customer satisfaction, employee satisfaction, cost per case. The kill criteria are more important than the success criteria — they prevent a weak pilot from being extended indefinitely.

Pilot Results and the Scaling Decision

This is where the biggest trap lies. Earley Information Science analyzed technology pilots and found: over 70% fail at scaling — not because the technology or service fails, but because the company lacks a clear strategy for the transition from pilot to regular operations [19]. Although this data comes primarily from AI and technology pilots, experienced service designers describe the same pattern with service pilots: the pilot conditions are too good to represent reality. Pilot conditions — small scale, motivated participants, dedicated resources, management attention — are fundamentally different from operating conditions. A successful pilot proves that the service works under ideal conditions. Nothing more.

Three questions before the scaling decision:

1. Does the service work without the pilot team? If the pilot only works because a dedicated project team manually fixes every error, it is not scalable.
2. Do the costs hold at scale? The cost per case in the pilot is almost always lower than at scale because the processes have not yet been industrialized.
3. Is the organization ready? Successful pilots can trigger an “immune response” from the organization — departments that were not involved in the pilot see the new service as a threat to their status quo [20]. Plan for this reaction.

Practical Example: Service Prototyping in Insurance

Starting Point: Blueprint Reveals Breakpoint in Claims Reporting Process

A mid-size property insurer has documented its claims reporting process in a Service Blueprint. The analysis reveals a critical breakpoint: between the customer’s digital claims report (frontstage) and the internal claims assessment (backstage), an average of 4 business days pass. During this time, the customer receives no status update. The support hotline records 60% of all incoming calls during this phase — customers wanting to know “whether anyone is taking care of my claim.”

The blueprint analysis yields three testable hypotheses:

• H1 (Frontstage): Customers accept an automated status tracker when they can see the current processing step in real time.
• H2 (Backstage): Claims assessment can be shortened from 4 days to 1 day through AI-assisted pre-classification.
• H3 (Handoff): The media break between claims reporting and surveyor assignment can be eliminated through automated routing.

Method: Desktop Walkthrough + Wizard of Oz

Phase 1: Desktop Walkthrough (Days 1-2). The project team — claims adjuster, UX designer, IT architect, a customer service representative — simulates the new process with figurines on a table. They move the “customer” through the new journey: claims report, automatic confirmation, status tracker, AI pre-classification, surveyor assignment, response. Result: the handoff between AI pre-classification and human approval is unclear — who decides when the AI is uncertain? Iteration 2 introduces an escalation logic: below 80% confidence, the case goes to a human assessor.

Phase 2: Wizard of Oz (Weeks 2-3). For the status tracker and AI pre-classification, a Wizard of Oz test is set up. The customer sees a dashboard that “automatically” displays the claims status. In reality, a claims adjuster updates the dashboard manually based on the internal processing steps. The “AI pre-classification” is simulated by an experienced claims adjuster who evaluates cases according to a simplified decision tree.

Results and Iteration

• H1 confirmed with qualification: Customers appreciate the status tracker, but 3 of 8 test participants found the technical language (“Pre-assessment completed, forwarded to claims adjustment”) incomprehensible. Iteration: rewrite status messages in plain language (“We are currently reviewing your case. We will get back to you in 1-2 days.”)
• H2 partially refuted: Pre-classification by the “wizard” works in 70% of cases, but for combination damages (e.g., water + electrical), the simplified decision tree lacks the necessary granularity. Iteration: combination damages go directly to the human assessor, no AI attempt.
• H3 confirmed: Automated routing works smoothly in the wizard test — the claims adjuster was able to assign the surveyor within 30 minutes of receipt instead of placing the case in a queue.

Transition to the Pilot

Based on the prototype results, a 6-week pilot is defined: one region, 200 claims cases, real customers, real system (but with manual AI simulation in the background). Success criteria: hotline calls during the waiting phase decrease by at least 30%; customer satisfaction (CSAT) remains stable or increases; average processing time decreases from 4 to a maximum of 2 days. Kill criterion: if CSAT drops by more than 10 points, the pilot is terminated and the process is revised.

6 Common Mistakes in Service Prototyping

1. Prototyping Too Late — After the Concept Instead of During It

What goes wrong: The team develops a complete service concept, writes a requirements specification, aligns it with three departments — and only then prototypes. By this point, so many organizational commitments have been made that a fundamental change of direction is no longer politically possible.

Why: In organizations with a strong planning culture (Hofstede’s Uncertainty Avoidance Index for Germany: 65 [21]), “thorough planning” is equated with “proper work.” Prototyping is understood as downstream verification, not as part of concept development.

What to do instead: Tim Brown: “One of the measures of an innovative organization is its average time to first prototype” [15]. Start with a desktop walkthrough on the first or second day of concept work — not at the end. The walkthrough is the thinking tool, not the review authority.

2. Over-Polished Prototypes — the “Demo Trap”

What goes wrong: The prototype looks so finished that stakeholders mistake it for the final service. Three consequences: stakeholders focus on visual details rather than the concept. The team becomes emotionally attached to the prototype and resists negative feedback. Decision-makers set launch timelines based on a facade [5].

Why: In B2B contexts, sales teams push for “presentation-ready” prototypes for client meetings. And German corporate culture — particularly in the Mittelstand with its sector-specific innovation patterns [34] — often equates presentation quality with professional competence.

What to do instead: Jake Knapp calls it “Goldilocks Quality” — not too rough, not too polished, just realistic enough for testing [22]. Deliberately use materials that signal “work in progress”: paper, cardboard, hand-drawn elements. Tom Chi (Google X) built the first Google Glass prototype in one day from a coat hanger, plexiglass, and a pico projector — he tested the core experience without any polish [23].

3. Testing the Wrong Audience — Colleagues Instead of Real Users

What goes wrong: The team tests the prototype with internal employees, the project team, or “friendly” customers selected through the account manager. The result: systematically biased, excessively positive feedback [24].

Why: NN/g documents four bias types when testing with colleagues: relationship bias (colleagues are gentle), loyalty bias (employees evaluate the company, not the prototype), social desirability (politeness after a bad experience), and false consensus (projecting one’s own usage patterns onto everyone) [24]. In the B2B context, account manager gatekeeping is an additional factor: AMs select customers where the relationship is stable and exclude exactly those who have the most to lose — and therefore would give the most honest feedback [25].

What to do instead: Test with at least one person who doesn’t want the service — the skeptical operations manager, the overworked claims adjuster, the customer who filed a complaint last time. These “hostile witnesses” represent reality better than the innovation champions who volunteer.

4. Only Testing Frontstage — Ignoring Backstage Processes

What goes wrong: The prototype tests the customer interaction perfectly — online form, status notification, response. But the backstage processes (handoffs between departments, system integrations, exception handling) are never tested. At rollout, the service breaks at exactly these points.

Why: Frontstage prototyping is visible, presentable, and makes stakeholders happy. Backstage prototyping is unglamorous and requires collaboration between departments that don’t normally work together. Segelstrom (2013) shows that service visualizations systematically overemphasize visible touchpoints [14].

What to do instead: Use your Service Blueprint as a checklist: for every frontstage test, there is at least one corresponding backstage test. Don’t just test “Does the form work?” but also “Does the completed dataset arrive correctly in the backend? Can the claims adjuster process the case without re-entering data?“

5. Going Straight from Prototype to Rollout — Skipping the Pilot Phase

What goes wrong: The prototype got good feedback, the board is excited, IT says “We can build this in six weeks.” So the service is rolled out directly — without a controlled pilot phase. At scale, everything the prototype couldn’t uncover under lab conditions emerges: peak loads, exceptions, untrained employees, missing process documentation.

Why: Prototype enthusiasm creates momentum. Decision-makers fear losing momentum if they insert a pilot phase. And the experience from Earley Information Science shows: pilot conditions (small group, high attention, motivated participants) systematically produce better results than regular operations [19].

What to do instead: A pilot is not a brake — it is insurance. Define a controlled pilot with clear scope, time period, and kill criteria. Explicitly test the things a prototype cannot test: scaling, exceptions, consistency over time, employee behavior without project team support.

6. Iterating Endlessly — Prototyping as Procrastination

What goes wrong: The team is prototyping in round 7, even though the core questions were answered in round 3. Each new iteration finds “one more point” that needs to be tested. The pilot gets postponed, the scaling decision is deferred. Prototyping becomes the socially acceptable form of decision avoidance.

Why: In risk-averse organizations, “let’s test one more round” provides perfect cover: it sounds like thoroughness but is procrastination. In the German enterprise context, there is the added factor that the decision to pilot feels irreversible — real customers, real systems, real risk — while another prototype round feels consequence-free.

What to do instead: Before the first prototype, define the maximum number of iterations and which criteria trigger the decision to pilot. A pragmatic rule: if two consecutive prototype rounds yield no new insights that would fundamentally change the design, it is time for the pilot. Stefan Thomke formulates the principle: an experiment that fails is a success — but an experiment that never leads to a decision is a waste of resources [16].

How to Tell If Your Prototyping Is a Potemkin Village

Three questions as a quick diagnosis:

1. Are you also testing the backstage? If your last prototype only tested customer interactions but no handoffs, no system integrations, no exception handling — then you are testing a facade.
2. Are you testing with real users? If your test participants are exclusively project members, colleagues, or “friendly” customers hand-picked by the account manager, you are not testing the service — you are testing your network’s willingness to please you.
3. Are you testing edge cases? If your prototype only covers the happy path (standard case, cooperative customer, functioning technology), you don’t know how the service behaves under stress — and that is exactly what will happen in regular operations.

If you have to answer any of these questions with “no,” your prototyping is missing a critical dimension. Use your Service Blueprint as a checklist: every layer of the blueprint must have been tested in at least one prototype cycle. Compare your results with a systematic Benchmarking of similar services to identify blind spots.

GDPR & Works Council: Compliance in Service Testing

This section covers compliance requirements that no international service prototyping guide addresses — because they are specific to the German legal framework. If you are testing service prototypes in a German company, two regulatory frameworks apply: GDPR (DSGVO) for handling customer data and the Works Constitution Act (BetrVG) for employee participation.

Customer Data in Service Tests: What GDPR Permits

Ground rule: the use of personal data for testing purposes was already restricted before GDPR by the BDSG (Federal Data Protection Act) and is now strictly regulated by Art. 5 and Art. 6 GDPR [26]. Violations can be penalized with up to 20 million euros or 4% of global annual revenue [27].

For service prototyping, this means concretely:

• Use synthetic test data: Create fictitious customer cases for desktop walkthroughs, role plays, and Wizard of Oz tests. No real customer names, no real claim numbers, no real contract data.
• Inform participants: Anyone participating in a service prototype test must know they are part of a research study — even if you don’t disclose all system details to maintain test realism [28]. This also applies to Wizard of Oz tests: you don’t have to reveal that a human is behind the system, but you must disclose participation in the study.
• Document consent: For each participant, a consent form covering the purpose of data collection, type of data collected, storage duration, and right of withdrawal. For informal prototyping sessions without personal data collection (e.g., desktop walkthroughs with purely internal participants), the duty to inform suffices under conservative interpretation — but as soon as you document observations that can be traced back to individual persons, we recommend formal consent.
• Anonymize during analysis: If you record test sessions (video, audio), anonymize the data during analysis. Retain raw data only as long as necessary for analysis.

Employee Participation in Tests: Involve the Works Council Early

Section 87(1) No. 6 of the Works Constitution Act (BetrVG) gives the works council (Betriebsrat) a co-determination right regarding the “introduction and use of technical devices designed to monitor employee behavior or performance” [29]. The interpretation is broad: according to Luther Rechtsanwalte, “virtually every IT system that processes employee data potentially falls under co-determination, even if it is not explicitly intended for monitoring” [29]. Recent case law (as of 2024), however, tends toward a narrower interpretation: co-determination rights apply only when the technology creates actual “monitoring pressure” [30]. Informal service prototyping sessions without digital recording (role plays, desktop walkthroughs) likely do not fall under co-determination requirements under this narrower interpretation — we nevertheless recommend proactively informing the works council to build trust and avoid later conflicts.

For service prototyping, this means:

1. Inform the works council before the first test when the prototype includes digital touchpoints that affect employee workflows.
2. Plan 2-4 weeks lead time for the works council consultation in your prototyping timeline — a deadline that no international sprint framework accounts for.
3. Document the test purpose in writing: No performance monitoring, no behavioral surveillance, but service optimization. This documentation is your protection in a later review.

Synthetic Test Data and Anonymization

For all fidelity levels above the desktop walkthrough, we recommend:

• Use a test data generator: Create a set of 20-50 fictitious but realistic customer cases covering the variance of your service (standard case, exception case, complaint case, major damage).
• Pseudonymization rather than anonymization in the pilot: In the pilot, where real customers are involved, use pseudonymization (reversible keys) to be able to re-identify data if needed — but only by authorized persons.
• Documentation of anonymization: Record the anonymization process in writing. Regulators may require demonstrable anonymization processes.

The paradoxical strength: German regulatory frameworks enforce what international prototyping frameworks merely recommend [21]. GDPR compliance from day one prevents the “we’ll handle data protection later” fallacy. Works council involvement ensures that the employee perspective enters the prototyping process early — exactly what many prototyping guides recommend as “best practice” but rarely implement in reality. German companies that understand these regulatory frameworks as part of the prototyping process (rather than as an obstacle) produce more realistic, better-validated service prototypes.

FAQ — Frequently Asked Questions

What is the difference between service prototyping and product prototyping?

Product prototyping tests an object — its functionality, tactility, aesthetics. Service prototyping tests an experience — how a service feels when it is delivered over time by people for people [2]. Services are intangible, are co-produced at the moment of delivery, and span multiple touchpoints and points in time. This requires different methods: instead of 3D prints or Figma mockups, you use role plays, desktop walkthroughs, and Wizard of Oz simulations that capture the interplay of customers, employees, and systems.

When in the service design process should you prototype?

As early as possible, and then continuously [15]. In the Double Diamond, prototyping belongs in the Deliver phase, but that doesn’t mean you wait until then. A desktop walkthrough on the second day of concept work is more valuable than a perfect experience prototype three months later. Tim Brown puts it: “Prototypes slow us down to speed us up” [15] — the apparent time loss from early prototyping prevents expensive mistakes during implementation.

What is Wizard of Oz Prototyping?

Wizard of Oz Prototyping is a testing approach in which users interact with a service that appears automated or system-driven but is actually controlled by a human behind the scenes [10]. The name comes from the children’s classic “The Wizard of Oz”: behind the impressive system sits a person pulling the strings. The method is particularly suited for testing AI-driven or automated service functions before you actually build the automation. Important: unlike the Concierge MVP, in Wizard of Oz the user does not know that a human is acting behind the scenes.

How are service blueprint and service prototyping connected?

The Service Blueprint is your hypothesis source, the prototype is your test. Every layer of the blueprint — Customer Actions, Frontstage, Backstage, Support Processes — contains assumptions that you verify through prototyping. Concretely: identify the riskiest assumptions in your blueprint, formulate them as testable hypotheses, and choose the prototyping method that can test these hypotheses with minimal effort. The blueprint shows you what you need to test; the prototype shows you whether your assumptions hold.

What is the difference between a prototype and a pilot?

A prototype tests the concept — under controlled conditions, with simulated or limited elements. A pilot tests operational viability — under real conditions, with real customers, real staff, and real systems, but in a limited scope (region, customer segment, time period). The prototype answers: “Is the idea right?” The pilot answers: “Can we deliver it?” Don’t skip the pilot — a successful prototype does not prove that the service works under operating conditions [19].

How does iSEP integrate prototyping into the service development process?

In the Integrated Service Development Process (iSEP), prototyping is not a downstream verification step but an integral part of every phase. The key mechanism: every phase has an explicit fidelity gate. In the Discovery phase, initial assumptions are tested with desktop walkthroughs (low fidelity); the gate to the Concept phase opens only when core hypotheses are confirmed. In the Concept phase, service scenarios are validated with role plays and Wizard of Oz tests (medium fidelity); the gate to the Deliver phase requires evidence that both frontstage and backstage processes work. In the Deliver phase, experience prototypes and controlled pilots are deployed (high/highest fidelity). The feedback loops ensure that prototyping insights flow directly into the next iteration — the team returns to the research participants and tests the modified concepts with the same stakeholders, rather than recruiting new test subjects.

---

Methodology & Disclosure

This article is based on a systematic evaluation of 80 sources: academic studies (Blomkvist 2014, Buchenau & Suri 2000, Dahlback et al. 1993, Thomke 2003, Ostrom et al. 2015, Hofstede), reference books (Stickdorn et al. 2018, Brown 2009, Ries 2011, Knapp 2016, Polaine et al. 2013), practitioner sources (NN/g, IDEO, SDN, Fraunhofer IAO), regulatory sources (GDPR, BetrVG), and contrasting critical perspectives (Earley, Astrafy, Blank 2019). 34 sources are directly cited in the bibliography. The research was conducted on February 22, 2026. The insurance practical example is a realistic scenario based on industry-typical processes, not a documented individual case.

Editorial assessments (“In practice, it shows…”) are based on the cited sources and the synthesis of the 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 case studies originate from B2C contexts (insurance, healthcare, financial services). The transfer to B2B enterprise requires adaptations that have not yet been systematically evaluated.
• The fidelity debate is unresolved. The question of which fidelity level is optimal for which type of question has not been conclusively answered in the literature. Our recommendation of “as low as possible” is based on the economic principle, not on empirical comparison studies.
• Legal landscape in flux. The interpretation of Section 87(1) No. 6 of the Works Constitution Act (BetrVG) continues to evolve. The assessment presented in this article is based on the state of affairs as of 2024 and may be changed by future case law. In particular, the question of whether informal service prototyping sessions without digital recording fall under co-determination requirements has not been conclusively settled in law; the proactive information of the works council recommended here is a conservative recommendation, not binding legal advice. Likewise, the distinction between a formal consent requirement and a mere duty to inform for prototyping sessions without personal data collection has not yet been decided by the highest courts.
• Not covered: Remote prototyping methods for distributed teams, AI-assisted prototyping (generative prototype creation), digital twins for service simulation, and the systematic measurement of prototyping ROI. Each of these topics warrants its own treatment.

Disclosure

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

Bibliography

[1] Fraunhofer IAO. “Dienstleistungs-Prototyping: Von der Serviceidee zur markttauglichen Dienstleistung.” Fraunhofer IAO Blog, 2012. URL: https://blog.iao.fraunhofer.de/dienstleistungs-prototyping-von-der-serviceidee-zur-markttauglichen-dienstleistung/ [Industry Research | Fraunhofer Institut fur Arbeitswirtschaft und Organisation | Quality: 78/100]

[2] Blomkvist, Johan. Representing Future Situations of Service: Prototyping in Service Design. PhD thesis, Linkoping University, 2014. URL: http://liu.diva-portal.org/smash/record.jsf?pid=diva2:712357 [PhD Thesis | Eight-perspective taxonomy for service prototyping | Citations: 200+ | Quality: 90/100]

[3] Buchenau, Marion und Jane Fulton Suri. “Experience Prototyping.” Proceedings of the 3rd Conference on Designing Interactive Systems (DIS ‘00), 424-433. ACM, 2000. DOI: 10.1145/347642.347802 [Academic Conference Paper | Foundational — Experience Prototyping | Citations: 1400+ | Quality: 95/100]

[4] Blomkvist, Johan und Stefan Holmlid. “Existing Prototyping Perspectives: Considerations for Service Design.” NorDes 2011, Helsinki. URL: https://archive.nordes.org/index.php/n13/article/view/101 [Academic Conference Paper | Six-perspective framework | Citations: 150+ | Quality: 85/100]

[5] Stickdorn, Marc, Markus Edgar Hormess, Adam Lawrence und Jakob Schneider. This Is Service Design Doing: Applying Service Design Thinking in the Real World. Sebastopol: O’Reilly Media, 2018. ISBN: 978-1491927182. [Practitioner Handbook | Ch. 7: Prototyping methods | Citations: 1500+ | Quality: 88/100]

[6] Stickdorn, Marc et al. “Desktop Walkthrough.” This Is Service Design Doing — Method Library. URL: https://www.thisisservicedesigndoing.com/methods/desktop-walkthrough [Practitioner Method Card | Step-by-step protocol | Quality: 85/100]

[7] IDEO.org. The Field Guide to Human-Centered Design. 2015. URL: https://www.designkit.org/resources/1.html [Practitioner Toolkit | 57 design methods | Quality: 85/100]

[8] Interaction Design Foundation. “Bodystorming.” URL: https://www.interaction-design.org/literature/topics/bodystorming [Practitioner Article | Method definition and context | Quality: 78/100]

[9] Fraunhofer IAO. “ServLab.” Accessed February 22, 2026. URL: https://www.iao.fraunhofer.de/en/labs-equipment/servlab.html [Research Laboratory | World’s only dedicated service prototyping lab | Quality: 85/100]

[10] Dahlback, Nils, Arne Jonsson und Lars Ahrenberg. “Wizard of Oz Studies: Why and How.” Knowledge-Based Systems 6, Nr. 4 (1993): 258-266. URL: https://www.semanticscholar.org/paper/817078a19b41c435f95cd0eb3bc0d8b73f3adf76 [Academic Article | Foundational WoZ methodology | Citations: 425+ | Quality: 90/100]

[11] Nielsen Norman Group. “The Wizard of Oz Method in UX.” April 2024. URL: https://www.nngroup.com/articles/wizard-of-oz/ [Practitioner Article | 5-step protocol, WoZ vs. Concierge distinction | Quality: 90/100]

[12] Service Design Network. “Extreme Customer Orientation in Insurance: Livework.” URL: https://www.service-design-network.org/headlines/extreme-customer-orientation-in-insurance-livework [Case Study | Gjensidige Insurance, Livework Studio | Quality: 80/100]

[13] Blank, Steve. “Why Companies Do ‘Innovation Theater’ Instead of Actual Innovation.” Harvard Business Review, October 2019. URL: https://hbr.org/2019/10/why-companies-do-innovation-theater-instead-of-actual-innovation [Practitioner Article | Innovation theater diagnostic | Citations: 200+ | Quality: 85/100]

[14] Segelstrom, Fabian. Stakeholder Engagement for Service Design: How Service Designers Identify and Communicate Insights. PhD thesis, Linkoping University, 2013. URL: https://www.semanticscholar.org/paper/4e024a0290777f73e3db72ef4e9b2bc3e377face [PhD Thesis | Visualisation bias toward visible touchpoints | Citations: 100+ | Quality: 80/100]

[15] Brown, Tim. Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation. New York: Harper Business, 2009. ISBN: 978-0061766084. [Practitioner Book | “Build to think” philosophy | Citations: 5000+ | Quality: 85/100]

[16] Thomke, Stefan H. Experimentation Matters: Unlocking the Potential of New Technologies for Innovation. Boston: Harvard Business School Press, 2003. ISBN: 978-1578517503. URL: https://www.hbs.edu/faculty/Pages/item.aspx?num=13733 [Academic Book | Failure vs. mistake distinction; 6 experimentation principles | Citations: 1500+ | Quality: 90/100]

[17] 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]

[18] Nielsen Norman Group. “The Hawthorne Effect and Observer Bias in User Research.” URL: https://www.nngroup.com/articles/hawthorne-effect-observer-bias-user-research/ [Practitioner Article | Novelty effect, observer bias | Quality: 80/100]

[19] Earley Information Science. “Why Your GenAI Pilot Won’t Scale.” URL: https://www.earley.com/insights/why-your-genai-pilot-wont-scale [Industry Analysis | 70%+ pilot failure rate | Quality: 75/100]

[20] Growth Institute. “Recognizing and Overcoming the Corporate Immune System.” URL: https://blog.growthinstitute.com/exo/corporate-immune-system [Industry Article | Organizational resistance to innovation | Quality: 70/100]

[21] Hofstede Insights. “Country Comparison: Germany.” Accessed February 22, 2026. URL: https://geerthofstede.com/culture-geert-hofstede-gert-jan-hofstede/6d-model-of-national-culture/ [Academic Framework | Germany UAI 65; deductive preference | Citations: 100000+ | Quality: 90/100]

[22] Knapp, Jake, John Zeratsky und Braden Kowitz. Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days. New York: Simon & Schuster, 2016. URL: https://www.thesprintbook.com/the-design-sprint [Practitioner Book | “Goldilocks quality”; Day 4 prototyping | Citations: 2000+ | Quality: 80/100]

[23] Collective Campus. “Common Prototyping Mistakes and 5 Ways to Prototype Better.” URL: https://www.collectivecampus.io/blog/common-prototyping-mistakes-and-5-ways-to-prototype-better [Practitioner Article | Tom Chi / Google X example | Quality: 70/100]

[24] Nielsen Norman Group. “Employees as Usability-Test Participants.” URL: https://www.nngroup.com/articles/employees-user-test/ [Practitioner Article | 4 bias types documented | Quality: 85/100]

[25] Ostrom, Amy L., A. Parasuraman, David E. Bowen, Lia Patricio und Christopher A. Voss. “Service Research Priorities in a Rapidly Changing Context.” Journal of Service Research 18, Nr. 2 (2015): 127-159. DOI: 10.1177/1094670515576315 [Academic Article | 12 service research priorities | Citations: 1500+ | Quality: 85/100]

[26] Libelle IT Group. “Test Data Management Compliance.” URL: https://www.libelle.com/blog/test-data-management-compliance/ [Practitioner Article | GDPR and test data | Quality: 75/100]

[27] TestingXperts. “Is your Test Data GDPR Compliant?” URL: https://www.testingxperts.com/blog/Is-your-Test-Data-GDPR-Compliant [Practitioner Article | GDPR penalties | Quality: 70/100]

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

[29] Luther Rechtsanwalte. “Dauerbrenner: Software vs. Mitbestimmung (Section 87 Abs. 1 Nr. 6 BetrVG).” URL: https://www.luther-lawfirm.com/en/newsroom/blog/detail/dauerbrenner-software-vs-mitbestimmung-87-abs-1-nr-6-betrvg [Legal Analysis | IT co-determination scope | Quality: 85/100]

[30] GOERG Partnerschaft von Rechtsanwalten. “IT Co-Determination Updates.” March 20, 2024. URL: https://www.goerg.de/en/insights/publications/20-03-2024/it-co-determination-updates [Legal Analysis | Narrower interpretation: “monitoring pressure” | Quality: 80/100]

[31] Polaine, Andy, Lavrans Lovlie und Ben Reason. Service Design: From Insight to Implementation. New York: Rosenfeld Media, 2013. ISBN: 978-1933820330. [Practitioner Book | Prototyping connected to service metrics | Citations: 500+ | Quality: 85/100]

[32] Ries, Eric. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. New York: Crown Business, 2011. ISBN: 978-0307887894. [Practitioner Book | MVP concept, Build-Measure-Learn loop | Citations: 10000+ | Quality: 85/100]

[33] KIT / Hochschule Furtwangen. Multidimensionales Service Prototyping: Service Innovationen kreieren, kommunizieren und bewerten. Berlin: Springer, 2020. URL: https://link.springer.com/book/10.1007/978-3-662-60732-9 [Academic Book | dimenSion project; systematic method selection | Quality: 85/100]

[34] De Massis, Alfredo, Josip Kotlar, Mike Wright und Frank T. Kellermanns. “Sector-Based Entrepreneurial Capabilities and the Promise of an Integrated Perspective.” Journal of Product Innovation Management 35, Nr. 5 (2018): 623-644. DOI: 10.1111/jpim.12373 [Academic Article | Mittelstand innovation traits | Citations: 300+ | Quality: 85/100]