A Practical Guide to Service Design

Why am I writing this?

When I started out on my journey with Service Design, I found it difficult getting my head around what it really meant.

I came across lots of new terminology and frameworks. It was hard getting an end-to-end view of the Service Design process. Articles often covered a specific part of the overall lifecycle, such as Service Blueprinting.

So, I’m writing the guide I wished I’d had when first starting out.

It’s a consolidation of my research and experience in the field so far. Aiming to provide a simple end-to-end guide, of how you can apply Service Design in your next project. Naturally, I won’t go into too much detail in this article, but I reference further readings and resources throughout.

Why Service Design Matters

From a managerial perspective, it makes sense to break down functions in an organisation into silos to benefit from specialisation and economies of scale. Yet, this leaves the customer to navigate through different channels and teams. This can lead to a fragmented experience.

Service Design addresses this issue by putting users at the centre. It aims to create a great user experience across the entire service journey, by adjusting processes, teams and systems.

In this way, Service Design differs to UX design as it’s more holistic in nature. It spans the entire Service journey and often many teams and systems. This invites more complexity, and Sevice Design provides useful tools and methods to navigate that.

If you would like to dive deeper into the “Why” of Service Design, I have a dedicated article on that here.

The Service Design Journey in a Nutshell

In this section I summarise the key phases of Service Design. It is the same structure I will elaborate on for the rest of the article.

I created the diagram below as a visual illustration, with examples exercises in each stage:

📌 Research & Synthesis

You start by gathering as much information as possible to understand the customer journey, making notes of any pain points or opportunities identified along the way.

Then, develop a Service Blueprint to synthesise and visualise this information. This invites further feedback, refinement, and developes a common understanding across stakeholders. This provides a foundation for prioritising key areas of the service that you will work on.

📌 Ideation & Prototyping

The ideation stage involves brainstorming possible solutions to the focus areas identified in the Service Blueprint, before deciding on the most promising ones for the prototyping.

The most promising ideas are then prototyped for user feedback, and refined over time.

📌 Implementation

Once you’ve validated the prototypes, you’re ready to deliver this new service to real users and start the implementation. This would include change management, effective communication, and possibly involvement with software development folk.

Now that you have the overview, let’s dive into each phase in more detail.

Research & Synthesis

The goal at this early stage is to gain an understanding of the overall service, the elements that make it happen, and the experience of the users and staff involved.

Following the “double diamond” model, you first diverge as you collectively expand your knowledge of the situation, and then converge as you synthesise this into a Service Blueprint(s).

An illustration of the double diamond model used in Design Thinking circles. There are many parallels here with the Service Design approach.

At this point it can be easy getting too bogged down into various processes, systems and departments, losing sight of the bigger picture. So when encountering new information, it helps to reflect on its impact on the user experience. This will help to you stay focused on gathering the most relevant information.

Here I will focus on 3 commons ways of gathering insights, drawing on the book “From Service Design to Implementation”:

Interviews

As interviews can be time consuming, both for the interviewers and interviewees, you’ll need to adjust the approach based on the needs and constraints of your project.

A minimal amount might involve 1:1 interviews with 4-5 participants lasting around 45mins. The output would be an executive summary with the top 5 observations and quick wins based on the research.

A mid-level analysis would involve around 10 participants, allowing deeper insights. This is especially useful when seeking long term value beyond the specific project, or for sharing across the company.

  • 💡Tips for Interviews:
    • Try to involve a diverse set of stakeholders to gain a bigger picture of what’s going on. For example, include interviews with customers, but also those involved in delivering the service.
    • Leave space for silence, and avoid interjecting with your own opinions or emotions – this is all about them.
    • You should find you’re asking “why” more than any other type of question, as this can help get to root causes. Yet you should still encourage specific details where appropriate. You can achieve this with questions like “describe a time when…”.

Observation

Sometimes it can be difficult for users to explain their experience or pain points. For example, when they have already figured out hacks or workarounds to cumbersome processes. These types of insights can be gleaned better through direct observation.

Example taken from Polaine, Løvlie, and Reason. 2013. Service Design: From Insight to Implementation. New York: Rosenfeld Media. rosenfeldmedia.com/books/service-design/
Sales staff build their own routines to make their process more efficient. Link to image source.

Another advantage of direct observation, is seeing the user engage with the service in their original context. This can bring out insights otherwise missed in an interview setting.

Experience

Lastly, it can be a great idea to experience the journey for yourself, taking note of your impressions. On top of the advantages mentioned with “direct observations” above, direct experience can be a powerful way of gaining empathy for users.

Naturally, any quantitative or written information you can get your hands on (e.g. Flow Charts) can also be a big help. But keep in mind those will better answer the “what” and “how” questions and not the “why”. The latter of which are much better gleaned using the qualitative methods above.

The Service Blueprint

A service blueprint builds a picture of the user journey and the elements that make it happen. This includes any service personnel, systems, and supporting teams/ processes.

A blueprint helps to construct a common picture of the service across different stakeholder groups. It bridges the traditional siloed mentality by looking at how each element or team contributes to the overall user journey.

By taking note of how users perceive each part of the service, you can identify areas of improvement. This will inform the later ideation and prototyping stages.

In this section, I draw a lot from the online course “Introduction to Practical Service Blueprinting“, made by the team behind “Practical by Design”. I would highly recommend checking out their website for those wanting to dive deeper. They also have plenty of free resources on Service Blueprinting you can use for your planning and workshops.

There is no standard format for a Service Blueprint, but they tend to follow a grid-like layout and include:

Rows:

  • The user journey overlayed at the top – phase by phase, step by step 
  • The touchpoints – channel by channel, touchpoint by touchpoint (sometimes I like to have them all in one/two row(s) to reduce the size of the diagram)
  • The backstage processes – stakeholder by stakeholder, action by action

Columns:

  • The different phases of the service lifecycle e.g. Aware -> Join -> Use -> Leave

Here are some examples:

Taken from: https://commons.wikimedia.org/wiki/File:Service_Design_Blueprint.png
Made by the team behind “Practical By Design”. You can use their free Mural template here.

Steps to (Co)creating the Service Blueprint

Using the insights gained from your research, you can start drafting the Service Blueprint.

Start by identifying the key phases of the Service you’d like to map, such as the onboarding, usage, servicing flows. This might be based on key problem areas you identified in your research.

Then, outline the key steps of the user journey within each of these phases. For example, the user registers on the website, receives a confirmation e-mail, gets a call from sales staff etc. Make sure to keep track of where these touchpoints take place (Channels) as these are big contributors to the user experience.

Once you have the outline in place, map out the back stage processes, people and systems that enable each step of the user journey. This could be admin support, systems involved or even physical resources that are used.

To start off with, it can be only yourself and members of the core team creating this draft. Later, sharing it with the relevant stakeholders for feedback and enrichment. This can done on digital whiteboarding tools, like Mural or Miro, or even simple sticky notes.

In comparison to creating the blueprint from scratch with the entire stakeholder group, this approach takes up less of everybody’s time. It also allows you to ask more targeted questions during these follow up sessions which maximises your time together.

As you create the blueprint, be sure to include critical feedback you gathered about the user experience, such as any paints points or opportunities identified. Make these noticable by marking or colour coding them. This will be useful for the synthesis and prioritisation step later:

As this stage can take some time, one approach is to build it iteratively. Starting with a “Minimum Viable Blueprint” for initial feedback (perhaps with simple sticky notes), before building it in higher fidelity.

Once you have an initial draft, you can present it users and staff involved in the service and gather their feedback. Make sure to include stakeholders across the entire journey, both front and back end (front end meaning staff who customers directly interact with), who are well versed with the actual process.

Generally 6-8 people are viewed as the sweet spot for workshops. Allow 1.5 – 2 hours for the session(s).

When it comes to planning the actual blueprinting workshop(s), as mentioned, “Practical by Design” have some great free resources which go into a lot more detail than I cover here.

  • 💡 Tips for Service Blueprinting:
    • Try to stay at the same level of abstration through each step, and avoid diving into rabbit holes that don’t contribute meaningfully to understanding the overall user experience/ journey.
    • Try to get enough data to generalise 80-90% of cases, you’re not trying to capture all possible scenarios.
    • During workshops, it helps to have a dedicated scribe to support the facilitator in updating the whiteboarding tool or capturing notes.
    • For remote sessions, live whiteboarding tools like Miro or Mural can be great for presenting the blueprints and capturing stakeholder feedback in real-time.

Synthesis and Prioritisation

Now you’ve constructed the Service Blueprint, you can begin collating the key problem/ opportunity areas you’ve identified. This will be easier if you’ve already distinguished these e.g. through a colored sticky note. This can involve only the core project team, or with a wider set of stakeholders, depending on the needs of the project.

As you group similar notes, themes will start to emerge. For example, customers needing to re-enter information, or lack of internal training leading to an inconsistent customer experience.

You can then share these findings with the relevant stakeholders for prioritisation, ideally involving end users. Consider highlighting these within the relevant parts of the service blueprint so it’s tied to the overall context.

Make use of prioritisation/ decision matrices such as value vs. effort to identify the best areas to focus on. For larger groups, you can also utilise dot voting exercises or polls to identify the best opportunity areas.

Value vs. Effort Decision Matrix

Ideation

I won’t delve much into ideation strategies in this article, as it’s been done better elsewhere. But the general principle is to follow the Double Diamond approach: diverge then converge. This means you’ll focus first on fostering the quantity over quality of ideas. For these exercises, try to involve a broad representation of different stakeholders and encourage lateral thinking. You can find a great free library of methods at This is Service Design Doing.

To ground the ideation in the insights gathered during the research phase, highlight the key pain points in the Blueprint and invite participants to think of how to resolve these and deliver value.

Once you’ve captured these ideas, you can make use of the same decision matrices and voting methods to gain consensus across the group. The free library I mention above has tools and methods to help with this under the “Ideation” section.

Prototyping

Now for the fun part. Drawing on the list of prioritised ideas you want to focus on, you can start prototyping – testing ideas with users and other stakeholders.

Prototyping allows you to get feedback early, with little upfront effort, allowing you to adjust and improve the idea before launching it. Unlike products, service prototypes usually require participants to interact with multiple touchpoints and key stages across the entire service. Doing this ensures the improvements make sense across the service as a whole, and reduces the risk of optimising a “part” within an ultimately fragmented service.

Deciding on Scope & Fidelity

The time and effort required for prototyping can vary a lot based on the goal. So it’s important to gauge the resource and time constraints of your project to guide its scope.

It’s also important to consider what you’re looking to understand, assumptions you’d like to validate, and how this can be achieved with the minimal amount of time and effort. You should focus on prototyping the areas where the research found to be critical, and require significant re-work.

The diagram below illustrates some possible prototyping options, based on the above criteria. For the “Cost” section, keep in mind the book where this was taken from was targeted at Design companies/ Consultancies doing projects for clients:

The four levels of experience prototyping. Polaine, Løvlie, and Reason. 2013. Service Design: From Insight to Implementation. New York: Rosenfeld Media. rosenfeldmedia.com/books/service-design/. Link to image source.

The authors of the book elaborate on 4 different prototyping methods, which I’ve summarised below:

1. Discussion Prototype:

This is the cheapest and simplest option. It involves bringing mockups or storyboards of various touchpoints, and sharing it with a set of customers in a 1-hour interview.

These customers are asked to act as themselves, and respond to different parts of the user journey as if they were experiencing them for real. Through this simple exercise you can already get a sense of what works and what might need revising.

2. Participation Prototype:

This is like the discussion prototype, but takes place where the service would be delivered, thus involving more of the local context. You might, for example, invite a few representatives to a store to try out a new purchasing flow. This would involve mockups of the new ideas whether digital or physical.

The benefit of this approach is that you can simulate more aspects of how the service unfolds over time, taking into account things which you would miss in a standard discussion. Usually for this you would involve 2-6 customers, as well as any key service reps.

3. Simulation Prototype:

This involves a combination of the above two prototyping methods, but in more detail. It would also take place where the service would be delivered, and include more realistic prototypes and mockups, better representing how the actual service would be. Given the upfront investment required, you might want to have a longer testing period with users, to gain richer insights across more aspects of the journey.

Aim for 2-6 customers, though 2-3 customers is typically more realistic due to time and budget constraints.

4. Pilot:

Lastly, if the project conditions allow, you can run a pilot which involves delivering a near-finished service to actual users. This goes beyond a prototype as mockups are no longer used at this stage and users might not even know that they are experiencing this beta service. Given it’s a beta, you’ll need to bake in an iterative feedback and improvement cycle to refine the service over time before the actual full scale implementation.

On top of generating the richest insights in real-world situations, this approach can be useful for services where effects on users have a certain lead time or the service itself is prolonged and complex, such as with certain public services.

  • 💡 Tip for Prototyping:
    • These prototyping approaches don’t have to be an either/ or decision. For example, it might make sense to start with a simple discussion prototype, leading to a more detailed simulation, before doing a small-scale pilot. It is common practice to start rough and build the prototypes in higher and higher fidelity as you gather more feedback.

Preparing for Service Prototyping

The Service Blueprint can act as a basis for building your prototypes, as you can overlay your proposed changes in a separate version. This is useful for keeping the team aligned, and can act as a direct input to any storyboards or mockups you create.

Example taken from “Practical by Design”. Direct link to Mural board here

Additionally, the format of the Service Blueprint will help you think holistically in your prototyping. For example any physical props, backend processes or systems involved in each proposal.

After Service Prototyping

After completing the prototyping stage, you’ll want to communicate the findings and possibly build an investment case.

The Service Blueprint can once again be a huge asset, as it acts as a platform to illustrate the proposed changes in an end-to-end, front to back way. But, as the Blueprint is more geared towards the technicalities of the service, you will might want to produce a slimmed down version for communication purposes.

Additionally, as outlined in the book “Service Design: From Insight to Implementation” you can even transform the Blueprint itself into a visual business case. Here, instead of describing the design, you outline the expected impacts on costs and revenue of each proposed change in the service:

Taken from Polaine, Løvlie, and Reason. 2013. Service Design: From Insight to Implementation. New York: Rosenfeld Media. rosenfeldmedia.com/books/service-design/. Link to image here.

Implementation

I won’t go into implementation in too much detail, as it depends a lot on the type of service you are designing for. It may not even be within the scope of the design project itself.

However, the principles of change management should be considered here, as this will influence how effective the new proposition is. It is important that employees are aware of the changes, have been involved in the design, and understand how it will value add for customers.

As Service Design projects involve many dimensions of an organisation, it’s important to take a similarly holistic view during implementation. Luckily the Service Blueprint already helps with this, as many of the key stakeholders will have been identified and even involved in the process. On top of this, Frameworks like the POPIT model can also be useful for evaluating the different aspects of a new proposition:

The POPIT Model

Here are some questions you might ask, based on the 4 dimensions above:

  • Organisation: Do we need to reorganise, or create any teams to support this new service? Should we tie any metrics to people’s performance targets?
  • People: What training do we needed? How will we make customers aware of the new/ improved service?
  • Process: Do we need to document any changes to the process? How might this affect the way teams collaborate in future?
  • IT: Do we need to develop any new technical capabilities? Have we defined and prioritised these developments to ensure a smooth service delivery?

If the proposal requires any new IT capabilities, you can feed the insights already gained into agile software development approaches, such as creating personas, and writing user stories. Partner closely with the Product Owner/ Manager (or equivalent), as they are responsible for the backlog prioritisation. Make sure they understand how these technical deliveries tie into the overall service proposition.

Conclusion

So there we have it, an end-to-end overview of a typical Service Design journey. Of course this is just a birds-eye view, so I’ve referenced additional sources throughout for further reading (see also the list I compiled at the bottom of the article).

That said, one takeaway from speaking with other Service Designers and my own experience, is the importance of being adaptable. You may well need to skim over or adjust parts of this journey based on the needs of your project. It’s also not a linear process, so you may need to revisit earlier stages to check assumptions or gain further insights.

Despite having its roots in design thinking methodologies, and drawing parallels with the likes of UX Design and Interaction Design, Service Design complements these by taking a more holistic approach and evaluating the entire service journey. This helps to ensure that we don’t end up with a situation where we have beautiful interfaces lying within a fragmented, unsatisfactory overall service.

As Management Guru and Systems Thinker Russell L. Ackoff once said:

“It’s far better to do the right thing wrong than to do the wrong thing right”

Thanks for taking the time to read this. What did you make of it? Was there anything you felt was unclear or missing? Would love to see your comments below!

—————————-

List of sources and suggests for further reading:

  • Books:
    • Service Design: From Insight to Implementation – Polaine, A., Løvlie, L., & Reason, B. (2013)
    • This is Service Design Doing – Stickdorn, M., et al. (2018)