Why can a service design book leave the reader unsatisfied?
Someone beginning to explore service design may expect a complete set of recipes: how to conduct research, how to build a prototype, how many participants to invite, what to observe and when to consider the test complete.
“This is Service Design Thinking”, however, mainly offers a broad perspective and a collection of tools. It shows how to map experiences, involve stakeholders, visualise processes and support co-creation. It does not always guide the reader step by step through the construction of a prototype for a specific service.
This may be disappointing, especially for readers who have previously used highly detailed design thinking toolboxes. Well-prepared workshop materials often describe:
- the purpose of a method,
- the necessary materials,
- the estimated time,
- the facilitator's next actions,
- questions for participants,
- common mistakes,
- how to analyse the results.
A service design book may be less prescriptive because the discipline depends strongly on context. Healthcare, telecommunications and retail returns all require very different forms of prototyping.
The absence of one universal recipe does not mean that service prototyping is vague. It means that the prototype must be built around a specific risk, process and group of people.
A service prototype is not a website wireframe
In digital projects, the word “prototype” often means a clickable mock-up. The user sees a sequence of screens, performs a task and the designer observes whether the navigation and messages are clear.
In a service, the interface may be only one of many touchpoints. The customer may:
- see an advertisement,
- call a helpline,
- visit a service point,
- sign a document,
- receive a text message,
- wait for an installer,
- speak with a technician,
- submit a complaint,
- use an online account.
Each of these elements can be designed well or badly. Even when individual touchpoints are well designed, the overall experience may still fail if they are inconsistent.
For example, a customer may order a service easily online, while the installer receives incomplete information. The customer portal may display one appointment date, while the call centre sees another. The terms may promise an easy return process, while the internal procedure requires several approvals.
A service prototype should therefore test not only a screen, but also information transfer, responsibility, timing, employee behaviour and customer reactions.
What can actually be prototyped in a service?
The scope is much broader than it may initially appear. A team can prototype:
- the first contact with an offer,
- a sales conversation,
- the way a price is explained,
- a registration process,
- appointment booking,
- handover between departments,
- complaint handling,
- notifications and messages,
- employee behaviour in a difficult situation,
- the layout of a physical service point,
- the experience of waiting in a queue,
- a decision-making procedure,
- a system supporting an employee,
- the complete customer journey from beginning to end.
There is no need to build everything immediately. A prototype may cover only one fragment of the service if that fragment contains the greatest uncertainty.
If the problem is offer comprehension, the team can prototype the consultant's conversation and information materials. If the risk concerns service time, it may be useful to simulate the flow of information between employees. If the team does not know whether customers will accept a new payment model, several trial transactions can be performed manually.
First the question, then the form of the prototype
A common mistake is selecting an attractive technique before deciding what the team wants to learn. A workshop may look impressive but still produce no useful knowledge if the research question is unclear.
Before prototyping, it is worth answering:
- Which assumption is the most risky?
- What must be true for the service to make sense?
- Which moment may cause the customer to abandon the process?
- Where may employees make mistakes?
- Which element will be the most expensive to implement?
- What can be tested without building the full solution?
- Which user behaviour will show that the idea works?
The form of the prototype should follow the question. If the question concerns a conversation, the prototype may be a role-played conversation. If it concerns information flow, the team may need a process map or a simulation involving several people.
Stakeholder mapping as a starting point
A stakeholder map helps reveal all people and organisations that influence the service or are influenced by it.
A project may involve more than the customer and the company. Relevant stakeholders may include:
- frontline employees,
- sales teams,
- technicians,
- external partners,
- technology suppliers,
- payment operators,
- regulatory institutions,
- the user's family,
- the person making the purchase decision,
- the person actually using the service.
A stakeholder map helps answer important questions:
- Who influences the success of the service?
- Who carries additional work?
- Who can block the change?
- Who holds knowledge unavailable to the project team?
- Who should participate in the test?
This tool is especially useful before prototyping because it reveals whose behaviour must be included in the simulation.
Desktop walkthrough – putting the service on the table
A desktop walkthrough recreates the service using simple objects placed on a table. These may include figures, cards, blocks, mock locations, device symbols and arrows showing information flow.
The method allows the team to walk physically through the service:
- the customer notices the offer,
- contacts the company,
- an employee verifies the data,
- the system transfers information,
- another person performs an action,
- the customer receives the result.
Moving elements across the table may reveal problems that are difficult to see in a written description:
- unclear handovers,
- missing information,
- too many steps,
- repeated activities,
- waiting without information,
- dependency on one person,
- conflicting actions by two departments.
A desktop walkthrough does not need to look realistic. Its purpose is to make the process visible and open to joint analysis.
Customer journey maps and service blueprints
A customer journey map shows the experience from the user's perspective. It helps organise:
- the customer's actions,
- touchpoints,
- questions and needs,
- emotions,
- problems,
- decision moments.
A service blueprint extends the map with elements of the organisation that the customer cannot see:
- employee actions,
- backstage processes,
- IT systems,
- documents,
- data flow,
- responsibility,
- dependencies on partners.
These tools are not complete prototypes by themselves, but they show what should be prototyped. They reveal where the greatest tensions and uncertainties are located.
If the journey map reveals frustration while waiting, the prototype may focus on status communication. If the blueprint shows manual data entry, the team can test a new way of passing information between systems and employees.
Role-playing and service simulation
Role-playing allows participants to perform the roles of customer, consultant, technician, partner or another employee. The scenario can be simple and run in a provisional space.
Role-playing helps test:
- whether the employee knows what to say,
- whether the customer understands the next steps,
- whether the procedure is actually executable,
- whether awkward moments appear,
- whether the employee has the necessary information,
- whether the service time is realistic,
- how the service behaves in unusual situations.
It is important to test more than the ideal scenario. The team should also explore cases such as:
- a missing document,
- a system failure,
- a late employee,
- an angry customer,
- a changed decision,
- a payment problem,
- a handover to another person.
A service that works only under ideal conditions is not yet well designed.
Bodystorming – thinking through action
Bodystorming involves physically entering the user's situation and performing the process in an environment similar to the real one.
The method is useful when the experience depends on:
- the layout of the space,
- distances,
- the visibility of information,
- the order of movement,
- interaction with devices,
- the presence of other people,
- noise,
- waiting time.
A provisional service point can be built with tables, chairs and cardboard. Participants then walk through the process as customers and employees.
This may reveal that the customer does not know where to stand, the employee must repeatedly leave the workstation or a conversation involving confidential data can be heard by others.
Wizard of Oz – manually delivering an apparently automated service
In the Wizard of Oz technique, the user believes they are interacting with a functioning system while part of the process is actually performed manually by a person.
This makes it possible to test a service before building expensive technology. For example:
- instead of an automated recommendation, an employee selects the offer manually,
- instead of an algorithm, an operator prepares the messages,
- instead of a complete customer portal, the customer submits a simple request and the process is completed manually backstage,
- instead of automatic pricing, a consultant prepares the price using temporary rules.
This method helps determine whether the service itself creates value before the company invests in automation.
Ethics must be considered carefully. The user should not be misled in a way that may cause harm, violate privacy or create real financial obligations.
Concierge prototypes – delivering the service personally
In a concierge prototype, the service is delivered manually and highly individually. The team observes the customer, talks to them and adjusts the process in real time.
This form is useful when the team does not yet know:
- which steps are genuinely necessary,
- which information the customer expects,
- which elements create the most value,
- what may later be automated,
- what the service standard should look like.
A concierge prototype is not scalable and does not need to be. Its purpose is to learn how the service should work before it is standardised.
Prototyping communication
A large part of a service experience is created through communication. A team may prototype:
- emails,
- text messages,
- notifications,
- conversation scripts,
- instructions,
- terms and conditions,
- confirmations,
- error messages,
- delay information,
- the way an apology is communicated.
A simple test may involve showing several versions of a message and checking what the customer understands. A stronger test runs the full scenario: the customer performs an action, receives the message and then decides what to do next.
This reveals not only whether the text is clear, but also whether it appears at the right time and leads to the intended action.
Prototyping space and physical evidence
Services often use physical places and objects. These may include service desks, signs, devices, forms, cards, packaging or equipment.
There is no need to build the final interior. A team can use:
- cardboard,
- tape on the floor,
- printed signs,
- temporary forms,
- simple device models,
- movable furniture.
Such prototypes help test visibility, sequence, privacy, accessibility and human behaviour in the space.
How to build the first prototype of a real service
The first prototype should not cover the whole organisation. It is better to select one important moment in the experience.
Step 1. Choose a specific scenario
Example: a new customer wants to activate a telecommunications service and arrange installation.
Step 2. Write down the key hypothesis
Example: the customer will understand the difference between the packages and select the correct option independently.
Step 3. Identify the participants
The test may require a customer, salesperson, employee verifying the data and someone acting as the system.
Step 4. Prepare the minimum elements
These may include printed offers, a provisional form, a conversation script, a confirmation text message and an appointment calendar.
Step 5. Perform the process
Participants go through the scenario without additional explanation. The designer observes where questions, errors, waiting and assistance appear.
Step 6. Collect evidence
Useful questions include:
- What was unclear?
- At which moment did the customer lose confidence?
- Which information did the employee lack?
- Which activity took the longest?
- Where was a manual workaround required?
Step 7. Change and repeat
Prototyping becomes useful only when the findings lead to another version. The aim is not a one-time presentation but iterative learning.
Example: prototyping a telecommunications service
A telecommunications service is a useful example because it combines the offer, contract, system, installation, device, support and payment.
Assume that a company wants to introduce a new home internet service. The team may prototype:
- the way packages are presented,
- address availability checking,
- appointment selection,
- visit confirmation,
- customer preparation before the technician arrives,
- the installation itself,
- service activation,
- the first login to the customer portal,
- reporting a problem after installation.
A working system is not required. An employee may select dates on a paper calendar, send the text message manually and use printed screens instead of a real portal.
The test can show whether the customer understands the offer, whether the employee has all the required data, whether the appointment timing is realistic and whether the next steps are clear after installation.
The level of prototype fidelity
A prototype may have low, medium or high fidelity. Starting with a realistic version is not always useful.
Low fidelity
Cards, simple scenarios, role-playing, paper messages and a schematic space. This form is inexpensive and easy to change.
Medium fidelity
More realistic materials, prepared forms, working fragments of the process and a partially recreated environment.
High fidelity
A prototype close to the real service, using target channels, employees and technology.
Fidelity should be as low as possible but high enough to answer the research question.
How to test the invisible part of the service
The backstage is often the most difficult part to prototype because the customer cannot see it.
It can be tested through:
- employee work simulations,
- manual data transfer,
- simulated system failures,
- different permission models,
- time measurements,
- counting handovers,
- observing where management decisions are required.
The team should analyse not only whether the customer received the result, but also the organisational cost required to deliver it.
A service may look excellent from the outside while demanding a large number of manual actions. A useful prototype should reveal this as well.
What should be measured during the test?
Depending on the objective, the team may observe:
- whether the customer understands the next steps,
- task completion time,
- the number of questions and errors,
- the moment at which trust is lost,
- the number of handovers,
- waiting time,
- the number of manual actions,
- employee workload,
- customer willingness to use the service,
- the cost of one service delivery.
Not every prototype test needs to generate precise statistical data. Early prototypes are often intended to discover problems and understand the mechanism behind them.
Who should participate in the test?
Depending on the prototype, participants may include:
- representatives of target customers,
- frontline employees,
- people responsible for the system,
- process managers,
- external partners,
- complaint-handling staff,
- financial decision-makers.
A test conducted only by designers may not reveal real limitations. An operational employee will notice procedural problems, while a user will show that a message is unclear.
The designer's role during prototyping
The designer does not have to create every element of the service personally. Their main responsibilities are:
- defining the question,
- selecting the right prototype format,
- inviting the right people,
- facilitating the scenario,
- observing behaviour,
- separating facts from opinions,
- structuring the findings,
- helping create the next version.
The designer acts as researcher, facilitator, simulation director and connector between the customer perspective and organisational capabilities.
Service design, UX, product design and brand
The boundaries between these concepts are not completely fixed.
User experience
Concentrates on the experience of using a product or a specific solution.
Product design
Concerns the creation and development of a product, its functions, operation and value for the user and the business.
Service design
Covers the complete experience and the organisational system required to deliver it.
Brand experience
Shapes expectations, emotions and the interpretation of every contact with the company.
Customers do not separate these areas. They may judge the product through a conversation with support, the brand through the complaint process and the application through whether the promise made in an advertisement was fulfilled.
Service design helps connect these elements into one coherent experience, although the exact boundaries depend on the project and organisation.
Where does the product end and the service begin?
In many industries, separating product from service is artificial. A phone without activation, updates, warranty and support is only an object. An internet service without a router, installation and technical help is not complete either.
One useful distinction is to see the product as an element that delivers value and the service as the full system that enables the customer to obtain that value.
The boundary depends on perspective. For the manufacturer, the device may be the product. For the customer, it is part of a wider experience involving purchase, configuration, use, support and replacement.
The role of brand in service prototyping
A brand creates expectations before the first contact with the service. The customer may expect speed, simplicity, luxury, safety or low price.
A service prototype should test whether the real experience matches the brand promise.
If the brand promises simplicity while activation requires five documents and three conversations, there is a contradiction. If the company promotes care but handles complaints with automated replies, the service weakens the brand.
The test should therefore examine not only functionality but also emotion:
- Does the customer feel confident?
- Do they understand what will happen?
- Does the company appear trustworthy?
- Does the service style match the brand promise?
A book for designers and a book for business
The reception of a publication depends on the professional perspective of the reader. A designer may look for method language, visualisation examples and ways to facilitate a process. A manager will more often ask about cost, decisions, risk, implementation and results.
For this reason, one book may feel highly practical to a designer and too general to a business reader. Another publication written for managers may explain more clearly how to connect design thinking with decision-making and company growth.
Neither perspective is superior. Service design requires both:
- sensitivity to human experience,
- understanding of processes,
- visualisation skills,
- feasibility assessment,
- economic thinking,
- the ability to implement change.
The aesthetics of the book as part of the experience
In a publication about service design, the design of the book itself has additional meaning. Layout, typography, illustrations, page rhythm and navigation shape the experience of using the content.
Good form does not replace substance, but it can:
- support understanding,
- show relationships,
- encourage browsing,
- make it easy to return to a tool,
- create consistency with the idea of designing experiences.
In this sense, the book itself can become an example of a consciously designed touchpoint with knowledge.
Common mistakes in service prototyping
Trying to prototype everything at once
An excessively broad scope makes observation difficult and leads to an expensive simulation. It is better to begin with the most important uncertainty.
Making the first version too polished
A highly refined prototype increases the team's attachment to the idea and makes radical change more difficult.
Testing only the ideal scenario
A real service must handle errors, delays and unusual customers.
Excluding operational employees
The concept may look good but be impossible to deliver in everyday work.
Focusing only on participant opinions
Behaviour, timing, errors and hesitation are as important as asking whether participants like the idea.
Skipping the next iteration
A one-time role-play is not a prototyping process if the results do not lead to changes.
When is a prototype good enough?
A prototype does not need to be complete. It is good enough when it answers an important question and enables the next decision.
The result of the test may be a decision to:
- develop the idea further,
- change the process,
- conduct additional research,
- simplify the service,
- change the target group,
- reject the solution,
- build a more realistic version.
The purpose of a prototype is not to prove that the team was right. It is to gain enough knowledge to make a better decision.
How to begin without experience
The best way to understand service prototyping is to build a simple prototype. There is no need to wait for an ideal project.
A team may select an existing service and one problem, for example:
- customers do not know what happens after submitting a request,
- an employee spends too long searching for information,
- booking requires several phone calls,
- the customer does not understand the first invoice,
- a complaint is passed between departments.
The team can then prepare a simplified scenario, invite several people and perform the new version of the process.
The first prototype will probably be imperfect. That is not a problem. Its main function is to turn an abstract discussion into an experience that can be seen, felt and improved.
Summary
Service prototyping is harder to grasp than interface prototyping because a service is not one object. It is a sequence of actions, relationships, messages, systems and decisions distributed over time.
There is no single universal service prototype. Depending on the question, the team may use a stakeholder map, desktop walkthrough, service blueprint, role-playing, bodystorming, the Wizard of Oz technique, a concierge prototype or a simple communication simulation.
The most important step is to begin with a risky assumption rather than a favourite tool. The prototype should be as simple as possible, involve the right people and reveal both the customer experience and the organisational effort required to deliver it.
“This is Service Design Thinking” may not provide a complete recipe for every test, but it helps reveal the breadth of the field and provides the language needed to work on services. The rest requires practice, iteration and the willingness to create imperfect first versions.
Service prototyping stops being an abstract concept only when the team dares to perform the first real process, identify its weaknesses and build a better version.
Issues: → service design thinking, service prototyping, service prototype, service design, This is Service Design Thinking, stakeholder map, desktop walkthrough, service blueprint, customer journey map, service role playing, bodystorming, Wizard of Oz prototype, concierge prototype, service testing, design thinking for services, process prototyping, UX and service design.