This Is Service Design Doing

Chapter 4. The Core Activities of Service Design

A flexible framework to tailor your service design process to your people, goals, and organization.

Expert comments by:
Christoph Zürn | Francesca Terzi | Jamin Hegeman | Simon Clatworthy

1. 4.1 In search of a process for designing a service

2. 4.2 Core patterns in the design process

   1. 4.2.1 Divergent and convergent thinking and doing

   2. 4.2.2 Make sure to solve the right problem before solving the problem right

   3. 4.2.3 All design processes are alike... and different

3. 4.3 Introducing the core activities of the TiSDD service design framework

1. This chapter also includes

   1. Iterative and adaptive design in a VUCA world

   2. Patience, young Padawan, your time will come

   3. Adapt and iterate forward, or how to not go in circles

   4. Four core activities of the service design process

In Search of a Process for Designing a Service

In this chapter and the ones that follow, we sketch out a framework that will help you understand the underlying activities and the overall process of designing a service. It will also help you to get a sense of its limitations. We’ll consider questions like:

• → How much can you plan for, and how can you professionally manage expectations and uncertainty in the remaining parts?

• → How can you stay on time and on budget while the process still needs to be iterative and explorative?

• → How much structure is necessary? When will too much structure have a negative effect on the quality of the results?

Expert Tip

“I always think of the design process like a music studio with a huge mixer desk. Each project needs a different mix of both instruments and levels (degree of use). Its always good to ask at the start, ‘What mix is this project?’”

— Simon Clatworthy

These questions have no easy answer, and not surprisingly, there is no one process to rule them all, no step-by-step checklist, no silver bullet. However, it is one of the beauties of service design that it allows or even demands flexibility. The best design processes are those that adapt to the problem you want to solve – and not the other way around. Instead of a rigid theoretical process, we have something much more powerful: emerging patterns and activities from real-world projects that are the strategic building blocks for any service design process.

The specific process you need to adopt for a project will vary depending on your organization, the challenge, the complexity of the challenge, the people involved, the underlying ideas or problems, and of course (and not least) the available budget, time, and other resources.

Designing the process and choosing the right methods and tools are core skills in service design. Even though you will see a lot of process charts and agendas in this book, be very aware that it won’t be enough to simply copy them. Always adapt the process to the people, culture, and goals of the project you are working on.

Iterative and adaptive design in a VUCA world

The adoption of iterative and adaptive design processes is in no way a fringe phenomenon.

It is taking place in major organizations – including the very conservative ones and very pragmatic ones, such as the US military. Faced with an operational context that is increasingly VUCA (volatile, uncertain, complex, and ambiguous), the US Army adopted a new approach in 2010 with its field manual FM 5-0. The manual “is a set of guidelines to be adhered to by military commanders when planning and decision-making for the battlefield. FM 5-0 is unique, as it is the first time that design – and specifically ‘design thinking,’ the iterative process of problem-solving that is considered by some typical of design – was introduced into the vocabulary of the military field manual.” ¹

As our world is cranking out innovations at an unprecedented rate, more and more industries are being shaken up by disruptive shifts. The business world is increasingly described as VUCA – volatile, uncertain, complex, and ambiguous. ² With that much pressure, you also need to be able to quickly adapt your problem-solving, innovation, and design skills. You need to be flexible and grow with the ever-changing challenges – and so does your process.

This book provides a framework for flexible service design process planning. It provides a set of proven tools to create and manage exactly the service design technique that your project and organization needs. As you evolve in your service design journey you might discover better ways to do things for yourself within your own context. However, getting to this point requires practice, skill, and a lot of experience.

To add to this, we challenge you to be critical as you read through the following chapters – and when you first apply the TiSDD framework. We challenge you to build your own customized service design process and give it a go. And we also challenge you to always stay critical of your own process. Always ask yourself: What worked? What didn’t work? Why didn’t it work? How might we do it better in the next project?

Core Patterns in the Design Process

Divergent and convergent thinking and doing

At the core of any design process is the recurring pattern of creating and reducing options:

Expert Tip

“Designers need to think critically and not adopt a model of the design process without question, but design the design process itself for the problem at hand.”

— Jamin Hegeman

1. During research activities, you generate a lot of knowledge through research methods which is then focused again through organizing and extracting key insights.

2. During ideation activities, you create many opportunities that you filter through decision-making processes to arrive back at a handful of promising ideas.

3. In prototyping and implementation, you open up by exploring and building potential solutions and then focus again through evaluation and decision making.

Figure 4-1. The design process as interplay between divergent phases (seeking opportunities) and convergent phases (making decisions).

These patterns can be described as divergent and convergent thinking and doing; they are some of the most important patterns within any design process. The terms divergent thinking and convergent thinking were first coined by psychologist Joy Paul Guilford in 1956 ³ and were introduced into the field of design and architecture by Paul Laseau in 1980. ⁴ In essence, both found that successful design and problem-solving processes can be described as an interplay between divergence (where we seek or create opportunities) and convergence (where we make decisions). ⁵

From the perspective of a team member who is part of this kind of design process, divergent and convergent thinking require different skills and often come with a different mindset. On one side, you have many people who exhibit a bias toward divergent thinking and doing. They just love to create and explore new ideas. On the other side, there are others who look at an idea and instantly see the risk and potential problems: “Won’t work here. Too expensive. Too political. Not legal.” etc. They spot instantly why something might not work in the world they know. Those two sides are often called the “Yes, and …” (trying to find new solutions) and “Yes, but …” modes (instantly challenging or reality checking every idea). ⁶ However, be careful before judging whether one of them is better than the other. Divergent (“Yes, and...”) and convergent (“Yes, but...”) skillsets are both essential in service design.

For a successful project, you will always need both: divergent skills to create enough base material to have great results or breakthrough concepts, and convergent skills to help you to stay legal, stay within the budget, or manage real risks and – in the end – come to a decision. The key is to consciously plan and manage when to do which, which specific methods to use, and who to involve. This holds true for both the workshop level and the service design process as a whole.

Expert Tip

“The more expertise and experience you have, the greater the likelihood you’ll find yourself in the ‘Yes, but …’ category. This is why it’s sometimes good to bring in an external or naive perspective, as naiveté naturally leads to ‘Yes, and …’ behavior.”

—Jamin Hegeman

Divergent and convergent thinking can be used as a generic, high-level lens when planning for or managing a service design process: Which of the activities or methods you use are divergent or convergent. When inviting stakeholders for your co-creation activities, this can be an additional perspective: What is the required mindset in terms of divergent and convergent thinking? Which mode should you currently be in? Is everybody on the same page?

Make sure you are solving the right problem before solving the problem right

Design processes are consciously designed to make sure you identify the right problem first before wasting time and money on solving the problem right. This sounds almost trivial, but it is indeed fundamental and does not always come naturally. Many organizations are trained to solve problems and implement immediately as part of their DNA – which in many situations might even be considered a good thing. But when facing new problems, how can you be really sure that you are working on the right problem? Or, if you were asked to solve the problem by someone else, how can you be sure that the project sponsor or client has indeed accurately identified the problem in the first place? That you are not being asked to solve just a symptom? Or whether or not she herself actually has access to all the relevant information and has given it to you?

This is what sets design approaches apart: rather than jumping right in – which also often leads to obvious solutions – you first take a step back. You make sure you identify and understand the right problem before you move on and then are able to come up with genuinely better solutions.

In 2005 and 2007, the British Design Council conducted research ⁷ on how successful design teams across many industries work, and they found that the designers were following this very approach. The teams would split their projects into two major parts. During the first part, they would use market/user/design research to learn more about the problem and define the actual project scope, as opposed to the assumed or perceived one. Only then – as part two – would they start to work on a solution using multidisciplinary approaches, visual management, prototyping, and testing until they implemented and launched the new service or product, whether physical or digital, ⁸ and received the first feedback from the market.

Patience, young Padawan, your time will come

Most people have encountered situations in meetings where half the team is in “Yes, and …” mode but the other half is already in “Yes, but …” mode, ready to shoot down every idea that the others come up with. And, hey, you have some friction. The good news is that the friction often can be addressed simply by explaining and acknowledging those two modes of working and clearly establishing which one the team is supposed to be in right now. For example, if you are running an ideation session, explicitly ask the team to switch to “Yes, and …” mode and defer judgement and negative comments. This becomes even more effective when you also mention that there will be a session afterward where the group can filter, review, and critique those ideas – and kindly ask the “Yes, but …” people in the room to be patient, as “Your time will come!” ⁹

“Yes, and …” and “Yes, but …” attach a simple language to the divergent and convergent thinking modes and – if introduced right – soon become symbols for the associated behaviors and frictions within your team: “Hey guys, are we still in ‘Yes, and …’ mode? Or are we already ‘Yes, but-ing’ each other? Let’s align!”

It is a good rule of thumb to challenge initial assumptions and kick off with some planned research. But even though this will often mean starting with research activities, keep in mind that there might be exceptions to that rule (e.g., when you start working on projects that are based on previous research or existing opportunity areas).

Comment

“Visualizations of the service design process are like a lead sheet in jazz. It just shows the basic idea that is needed to get the band playing.”

— Christof Zürn

All design processes are alike... different

Over the last couple of decades, a plethora of different design processes have either been published by practitioners or described in literature.

This is also true in the field of service design. There might be differences in the exact wording and the number of activities, steps, or phases – usually between three and seven. But they ultimately share the same mindset and the same principles of service design we described in the previous chapter. Here are just a few examples:

Expert Tip

“Our best practice is to brainstorm on processes and tools adaptation at the beginning of each project, with the aim to tailor our very own design process as much as we can to the project with all its challenges we will face.”

— Francesca Terzi

1. Discover, Define, Develop, Deliver ¹⁰

2. Explore, Create, Evaluate ¹¹

3. Exploration, Creation, Reflection, Implementation ¹²

4. Identify, Build, Measure – or – Orientate and Discover, Generate, Synthesize and Model, Specify, Measure, Produce, Transfer and Transformation ¹³

5. Insight, Idea, Prototyping, Delivery ¹⁴

6. Discovering, Concepting, Designing, Building, Implementing ¹⁵

One thing that becomes obvious very quickly is that at this level there are few (if any) differences in the core design process between service design and other design disciplines. The difference is rather in the specific set of tools and methods service design uses (e.g., customer journeys, service blueprinting, service prototyping), not in the design process itself. No matter what you design, you always need to understand user needs, you always work iteratively, you always have diverging and converging phases, and so on. So we need to look more deeply at exactly how these service design projects are run and what the underlying patterns and activities are. ¹⁶

THE DOUBLE DIAMOND

Adapt and iterate forward, or how to not go in circles

It is important to understand as early as possible that the service design process is never a linear process (i.e., a sequence of activities that is planned in advance and can be executed step by step with expected results). In fact, it’s quite the opposite. A service design process always needs to be explorative and iterative. It has to be able to adapt, building on a series of more or less repeating, deepening, explorative loops: iterations.

This adaptive and iterative nature makes design processes difficult to visualize. Even though they are not meant to, many visualizations still somehow suggest a linear structure – especially to people who are new to this way of working. It is just difficult to graphically visualize iterations as a process. Some use circles to illustrate the iterations – but a circle also describes a linear process, starting again with the first step after the last one. In reality, at any moment within a design process, you can move on to any other activity – if it makes sense. Design processes do not go in circles. They do not go back. Instead, they constantly move forward and adapt. Strictly following a linear process, like ticking checkboxes off of a task list or a rigid how-to-guide, might restrict your design work and in fact slow you down.

For example, you might do some initial research, then some ideation based on what you learned, and start some prototyping activities, only to find out that you have to go back to do more ideation or even more research to address issues you have discovered during prototyping. But you keep on iterating through varying combinations of the core activities toward working prototypes and finally into implementation.

There seems to be a fundamental friction between the explorative aspects and the pressures from the daily business to deliver results on time and in budget. Chapter 9, Service Design Process and Management, describes how you can use concepts like planned iteration to build an overarching project structure that not only creates trust in the process but also creates predictability for your organization without giving up on the iterative and explorative principles.

You will soon notice that while there might be useful patterns between the various core activities, there is no generally implied sequence. This is the reason why in this book we have decided to stop talking about core “phases” or “stages,” and talk about core “activities” instead.

Introducing the Core Activities of the Tisdd Service Design Framework

We will discuss the four core activities of the service design process in Chapter 5–Chapter 8 before moving on to explain the detailed mechanics of the overarching service design process in Chapter 9.

Comment

“Just like beginning cooks follow a recipe at first, it’s okay to follow a process. As you gain experience, you will discover opportunities to tweak, rearrange, and ultimately design your own design process.”

— Jamin Hegeman

• → Chapter 5, Research: In service design, research is used to understand people and their behavior in relation to a service or product, whether physical or digital. Design research enables a design team to empathize with the people they design for and build up a genuine understanding of their practices and routines. This allows the team to work from a user-centered perspective throughout a project and potentially also include people they encounter during research at a later stage to ideate or prototype concepts.

• → Chapter 6, Ideation: Producing ideas is a vital part of a service design project – but it is not as all-important as many people seem to think. In service design, ideas are just starting points within a bigger evolutionary process. They need to be, however, generated systematically en masse, mixed, recombined, culled, distilled, and evolved or parked. Their real value often lies not in the ideas themselves but in the outcome(s) that stem from them.

• → Chapter 7, Prototyping: In service design, prototyping is used to explore, evaluate, and communicate how people might experience or behave in future service situations. Prototyping enables the design team to identify important aspects of a new concept, explore alternative solutions, and evaluate which one might actually work in the everyday business reality.

• → Chapter 8, Implementation: Implementation describes the step beyond experimenting and testing, moving into production and rollout. The implementation of service design projects can involve various fields, such as change management for organizational procedures and processes, software development for apps and software, and product development or engineering for the production of physical objects, as well as architecture and construction for the creation of environments and buildings.

• → Chapter 9, Service Design Process and Management: Research, ideation, prototyping, and implementation are the major building blocks of a working service design project. This chapter provides a framework to plan and prepare as well as to manage and continuously adjust your iterative approach to build trust and deliver results for your organization.

Four core activities of the service design process

Figure 4-2. Overview of the four core activities of the service design process as presented in this book.
Please note that the four core activities are not mutually exclusive; there can be overlaps. For example, prototyping might contain some ideation and research activities, or an implementation activity might have elements from all the others – research, ideation, and prototyping.

¹ In its foreword, the manual states: “With [...] the introduction of design into our doctrine, we highlight the importance of understanding complex problems more fully before we seek to solve them through our traditional planning processes.” From US Army (2010). The Operations Process FM 5-0. Headquarters Department of the Army.

² For example, see Bennett, N., & Lemoine, J. (2014). “What VUCA Really Means for You.” Harvard Business Review, 92(1/2), 27.

³ Guilford, J. P. (1956). “The Structure of Intellect.” Psychological Bulletin, 53(4), 267.

⁴ Laseau, P. (1980). Graphic Thinking for Architects and Designers. John Wiley & Sons.

⁵ Sometimes also called elaboration and reduction.

⁶ See the “Yes, and …” warm-up method in Chapter 10, Facilitating workshops.

⁷ Design Council (2007). “11 Lessons: Managing Design in 11 Global Companies: UK Design Council.

⁸ The term “products” describes anything a company offers – no matter if this is tangible or not. In academia, products are often divided into goods and services. However, products are usually bundles of services and physical/digital products. As “goods” is colloquially understood as referring to something tangible, we prefer to speak of physical/digital products. Read more on this in the textbox on Service-dominant logic in 2.5.

⁹ Consider using the “Yes, and …” warm-up to introduce the two modes of working to a group. See “Yes, and…” warm-up in Chapter 10, Facilitating workshops.

¹⁰ Design Council (2007). “11 Lessons: Managing Design in 11 Global Brands,” UK Design Council.

¹¹ Dark Horse Innovation (2016). Digital Innovation Playbook. Murmann Publishers.

¹² Stickdorn, M., & Schneider, J. (2010). This is Service Design Thinking. BIS Publishers.

¹³ Overview and broken-down stages of Engine’s service design process. See Engine (n.d.). “Our Process.” Retrieved December 27, 2012, from http://www.enginegroup.co.uk/service_design/our_process.

¹⁴ Reason, B. (2009). “Service Thinking for Health Services” [slides]. Retrieved from http://liveworkstudio.com.

¹⁵ DesignThinkers Academy (2009). “DesignThinkers Service Design Method” [slides]. Retrieved from http://www.slideshare.net/designthinkers/designthinkers-service-design-method.

¹⁶ This leads to a discussion about the difference between goods, services, products, and experiences. See the textbox Services? Products? Experiences? in 1.1 for more details.