Data collection for planning

Start with the inputs from the initial brief and do a quick brainstorm of potential research questions. It is not necessary to present them in a beautiful way, as they will only serve to support your planning session.

Select a couple of key questions and start your preparatory research sessions. It is important to remind yourself that this is not yet about doing the research and solving the challenge but planning your research and the rest of your service design process. You need to gather just enough data and insights to be able to set up a workable process structure.

If you have a bit more time for your planning, you can also add data from additional methods that deliver fast first results – for example, current-state stakeholder mapping, secondary research, autoethnography, online ethnography, or first (contextual) interviews. ⁵⁵

Assessment of potential development directions

Based on the data from your preparatory research, you should also create a first assessment of potential development directions. This can give you a sense of what you need to work on as likely outputs and outcomes, as well as whom you might need to involve during ideation, prototyping, and implementation. Of course, this can and will change as you go through your project, but it is important to have this first idea to discuss and allocate reasonable budgets, time, and resources. Hence, no matter what you find (or don’t find, for that matter), it is key to truthfully acknowledge the level of uncertainty with respect to potential types of solutions. For example, if you know your project scope involves updating an existing app, you can plan and budget in the appropriate resources from your UX and development teams. But if you cannot yet tell what type of solution you will be implementing, it might be helpful to plan and budget for a pilot project, giving you the time and resources to clarify more concrete development directions first.

Core project team

The role of the core project team is to manage and support a project and to facilitate the design process through appropriate workshops and activities. You are aiming for a good mix of service design skills and subject matter expertise. However, not everybody on the core project team needs to be an expert in service design. Similarly, not everybody needs to be an expert in your industry or to have a deep knowledge of your organization. ⁶⁰ For a single service design project, the core project team usually consists of a handful of people, but it can be as small as a team of one (e.g., working as a coach within an existing project structure) or as big as a football squad (e.g., running and implementing a project for an internal or external client).

Decide which of the following roles are relevant to your project and organization, or if you need to create new ones (note that each member of the core team might take over multiple roles):

• → Service Design Management Lead: Plans and manages the overall service design process and manages the project team

• → Facilitation Lead: Ensures continuous feedback and learning, facilitates team collaboration, and provides design support or facilitation of co-creation workshops

• → (Service) Design Lead: Focuses on content and quality of service design outputs and deliverables; shapes and delivers design concepts

• → Business Lead: Ensures business viability of developed concepts; deals with business models, KPIs, benchmarks, business strategy, competitor analysis, etc.

• → Technology Lead: Analyzes technology requirements, ensures feasibility of new concepts, and manages and supports prototyping efforts

• → Change Lead: Focuses on the human perspective; assesses the impact on staff and customers from an individual and organizational change management perspective, and develops fitting change solutions

• → Project Manager: Keeps the team on track; manages the service design process in terms of budget, deadlines, and reporting; administratively backs up the project team

• → Project Owner/Sponsor: Takes responsibility for strategic direction and budget – the person who assumes this role is often a key decision maker

Extended project team

Most projects are also supported by an extended project team: a larger group of people with specific competencies that can be involved in specific sections or activities within the project. ⁶¹ Hence, the team size of an extended project team can vary over time and even change from workshop to workshop. Consider including: ⁶²

• → An internal selection of cross-functional members to ensure a holistic perspective.

• → External method or subject matter experts to manage the competencies that your organization does not have (e.g., ethnography, UX, change management, architecture, etc.).

• → Departments and/or external stakeholders that are responsible for earlier or later parts of your project, but also involved in daily operations.

• → Key decision makers from your organization. The success of your project might not just depend on the quality of your output but also on the hierarchical position of the decision makers who support it. Put careful thought into how to integrate them closely into your project team from the beginning. ⁶³

• → Users or customers, as ambassadors of their stakeholder group. This allows quick research and prototyping without a lot of planning.

• → Generally, any people who are directly affected by the project, or who have the power to stop it.

It is crucial that you involve affected staff as early as possible in the design process of their future daily work routines. This makes them co-owners of the new solution, a status which will help implementation and acceptance.

Breaking up your project

It can be helpful to break up your project into a planned sequence of smaller projects to deal with uncertainty and reduce the risk involved. Sometimes a short but well- prepared iteration like a five-day service design sprint can be enough to have a great impact on your results. ⁷³ This structure introduces clear points for reflection and decision in between projects that allow you to stop a certain development direction early if necessary. ⁷⁴

The different projects can also put a different emphasis on certain service design activities compared to others. The following options are certainly not a complete list, but might help to give you some basic orientation:

• → Strategic research and innovation projects

  If you are quite far forward in your innovation funnel, you might want to set up a strategic research project. Strategic research and innovation projects are usually not intended for implementation, but instead help to create meaningful starting points for more incubation, or implementation-oriented service design projects. Their main focus is clearly on research even though they end with a first couple of steps into solution space – for example, creating validated opportunity areas, lighthouse concepts on a prioritized idea portfolio, and first early communication prototypes to make those concepts more tangible.

• → Incubation projects

  If you are trying to explore and validate the market potential of one or more concepts, it makes sense to split your project into a sequence of incubation projects with growing budgets and resources. Incubation projects have a strong focus on experience prototyping, which delivers real data about the risks and market potential of each string of concepts.

• → Implementation projects

  If the solution space is sufficiently defined, you can plan straight for prototyping and implementation in a series of iterations within one project. Even though there still needs to be a strong emphasis on research and prototyping at the beginning, over the whole of the project most of the time and resources will go into implementation activities.

Figure 9-7. PROJECT PORTFOLIO
The mix of service design activities in your project portfolio changes as you move from early stages of strategic research toward implementation.

If you cannot yet see the shape of a potential solution, ⁷⁵ there is no way you can safely create a sound implementation plan or project. This would depend too much on the intermediate results of your research and prototyping activities. Start with a strategic research/innovation project or incubation project first.

Planned iterations

Within your project, planned iterations are iterations you promise to do and deliver on time and within budget/resources. ⁷⁶ Each planned iteration consists of three parts:

1. Iteration planning

2. Service design activities

3. Reflection on content and process

Planned iterations are the predictable timeboxes you set up for your design activities – a safe space to do, learn, and adapt. They are the primary iterations you need to focus on during your planning activities as they also define ahead of time when you will invite stakeholders from outside the project team for co-creation and decision making. A prominent example of planned iterations is the sprint structure you find in agile software development methodologies like Scrum. ⁷⁷

Figure 9-8. The Squiggle: ⁷⁸ This famous illustration shows how people can experience the design process as strange, almost chaotic. Using planned iterations helps to bring a solid structure but at the same time leaves enough space for exploration.

Figure 9-9. Planned versus actual iterations: Planned iterations create a formalized uber-structure for planning, service design activities, and reflection to stay iterative and adaptive at all stages of your service design process.

With planned iterations, you create a formalized uber-structure which establishes a set rhythm of planning, service design activities, and reflection to stay iterative and adaptive within your service design process. This keeps your team on track, and especially helps stakeholders who are not accustomed to this way of working.

Still, people who are experiencing service design for the first time (or looking in from the outside) can perceive it as arbitrary and almost chaotic. “Explorative and iterative work” is often misunderstood as “playing around and doing what you want.” Planned iterations help you to actively address and manage this perception.

The amount of freedom – or “wiggle room” – within your planned iterations depends on the experience of your design team. If you are working with inexperienced designers or an interdisciplinary team not accustomed to this way of working, keep the planned iterations tight and closely coach them through them until they pick it up. ⁷⁹

If you are working with experienced designers, you can trust them to iterate within the given boundaries as necessary. The typical length of planned iterations often ranges between two to four weeks.

It is important to make space regularly for reflection sessions focused on your process and future iteration planning, taking time to adapt to what you have learned so far. Usually, reflection sessions are put at the end of a planned iteration. With shorter iterations they can be quite informal, but make sure you always also conduct formal review and planning sessions at least at the end of higher-level iterations.

In your reflection and iteration planning, you need to consider the content, tools, and methods as well as the way you collaborate within your team: What did you learn in terms of your project content, and what needs to happen in the next iteration in terms of tools and methods? How was the collaboration in the team and what can you do to become more effective as a team? ⁸⁰

The key driver for cyclical and iterative methodologies like the service design process is the desire to reduce the risk at each single step while at the same time maximizing learning to make subsequent steps more efficient.

Planning core activities

The most important aspect of this part of the planning process is to create a preliminary plan which accounts for continuous iteration planning and content/process reviews along the way. These activities will become the cornerstones of your adaptive and iterative process. In the following pages, we sketch out how to create a more detailed picture of your research, ideation, prototyping, and implementation activities. Initially this will help you to put together a proposal, including a roadmap, a list of resources you need, and a budget. Later on, this becomes a living document as you adapt and improve.

The planning of your service design activities is also iterative in itself. So, plan your first iterations quickly, then come back and adapt and improve. Chapter 5–Chapter 8 ⁸¹ give you in-depth descriptions on how to plan your research, ideation, prototyping, and implementation activities when you are about to do them. During the process of planning, however, you need to balance the uncertainty at the time of planning (pre-project) with the need for just enough detail to at least be able to create a budget and key milestones. For each iteration, it is helpful to be able to communicate a clear picture of how you want to work, creating trust in your process and your project team.

Be aware that at some stage it might become pointless to plan for an iteration which is too far into the future – even if your client is pressing for it. In those cases, it might be helpful to sketch out an exemplary project framework based on a typical service design process, knowing that you only will be able to properly plan it when you get there.

Figure 9-10. PLANNED ITERATIONS VS. FORCED ITERATIONS
In the forced iteration model, necessary changes are only forced onto the team by imminent implementation deadlines. The team is mostly reactive; changes are expensive.
Using systematic research, ideation, and prototyping loops, the planned iteration model pushes design changes toward the beginning of the project. The team operates proactively; the cost of changes is low. ⁸²

Plan for research

• → Review your initial research question(s), preparatory research, and high-level iteration structure.

• → Select research methods: Line up a sequence of research methods and decide how to analyze and visualize them. Roughly guesstimate typical setups in terms of sample selection, sample size, researcher team, data types, and triangulation strategy.

• → Consider potential researchers: Briefly refer back to your stakeholder map or do a quick informal brainstorming on potential stakeholders. How much of the research can be done by the project team? Where do you need external help?

• → Split activities into planned research loops: Sketch out how you want to arrange the selected methods into different research and analysis/visualization sessions and how they feed into each other. Add adaptive iteration planning and review sessions.

Plan for ideation

• → Review your initial assessment of potential development directions.

• → Consider potential participants: Very briefly (as this will certainly change after your research activities) refer back to your project stakeholder map or do a quick informal brainstorming on potential experts or stakeholders for key opportunity areas.

• → Select methods: Line up a sequence of ideation and decision-making methods to fill your idea portfolio and select them. Guesstimate how many ideas you might want to take forward into prototyping.

• → Split activities into planned ideation loops: Sketch out how you want to line up the selected methods into different ideation and decision-making sessions and how they feed into each other. Add adaptive iteration planning and review sessions.

Plan for prototyping

• → Review your initial assessment of potential development directions. ⁸³

• → Assess what you might have to make: Remember that at this point you might only be able to plan for approximate types of prototypes (e.g., if you already know you are going to work on an app, a consulting session, a physical product, etc.). It might also be impossible to say what needs to be prototyped just yet. However, in many projects the expected outputs are quite well defined and can guide your planning. It might be important to assess the uncertainty of your planning so you can adjust as you move forward.

• → Select explorative and evaluative prototyping methods and plan supporting research: Line up a sequence of explorative and evaluative prototyping methods. Roughly guesstimate the typical fidelity, multitracking, context, audience, and audience size for each of those methods. Remember to select supporting research methods to learn from for each of your prototyping activities.

• → Consider potential prototyping skills and team(s): Do a quick informal brainstorming on potential skills you need and experts or stakeholders who have those skills to create the prototypes you need. Plan for interdisciplinary prototyping teams – who can make almost anything – at early iterations and include specialized skills later on.

• → Split activities into planned prototyping loops: Sketch out how you want to line up the selected methods into different explorative and evaluative prototyping sessions and how they feed into each other. Add adaptive iteration planning and review sessions.

Plan for implementation

• → Assess what you might have to make: Planning implementation means planning based on assumptions of what you might have to make. This will be based on your guesstimations of the prototyping activities and will share a similar uncertainty.

• → Consider potential implementation skills and team(s): Break down the implementation task into the involved disciplines. Do a quick informal brainstorming on potential skills you need and experts or stakeholders who have those skills to implement the project as it is planned today. Just like when you are planning for prototyping, it is often useful to plan for a core interdisciplinary implementation team – who can plan and manage almost anything – at early implementation iterations and move toward more specialized setups later on. Those might change, but having the interdisciplinary team at the beginning buys you the necessary time to adapt and communicate any changes as early as possible.

• → Involve specialists to do implementation planning: Line up seasoned project managers to give feedback on planning the implementation part(s). Co-create individual implementation plans together with the specialists.

• → Split activities into planned iteration loops: Sketch out how you want to line up the selected methods into different implementation loops and how they feed into each other. Add adaptive iteration planning and review sessions. As implementation activities are often done in parallel, make sure you sync those activities and continuously check the progress of single work packages against the holistic customer experience.

At any given stage, the higher the uncertainty in the outputs of your design process, the more parallel concepts or prototypes you should keep in the game.

Identify and map project phases

Have a look at periods of iterations within your design process where you can identify a dominant activity or scope. Mark them as overarching project phases for your project. Often they combine a distinct mix of activities, methods, and deliverables. Map them to align with existing iterations. Sometimes it is useful to play with the naming of your project phases to match with existing terminology. For larger service design projects, mapping project phases onto your service design process can also be used to give a sense of orientation and progress. Here are some examples of project phases:

• → Preparation phases, setup phases, scoping phases, or initial iterations often include project planning and prep research, but sometimes also some first research, ideation, and even prototyping activities. You might even do a very quick first iteration including all these activities to better plan the entire project.

• → Discover phases, insight phases, pre-project phases, or research phases might package early, research-heavy high-level iterations, but will usually also contain some ideation and lightweight prototyping.

• → Concept (development) phases, design phases, or ideation phases might package ideation-focused high-level iterations but will also contain research and at least some lightweight prototyping.

• → Prototyping phases, build phases, or incubation phases allow you to package prototyping-focused high-level iterations, but might also include some research and ideation activities.

• → Internal alpha, local beta, beta, or rollout phases allow you to plan phases around user engagement or the user learning curve.

• → Delivery phases, implementation phases, pilot phases, or rollout phases allow you to package different implementation-focused high-level iterations.

• → Operation phases or in-production phases allow you to package the continuous improvement iterations of the standard daily operations after your go-live. Service design is then set up as an ongoing activity in an organization and brings holistic cycles of research, ideation, prototyping, and implementation activities to the daily operations of your service.

Set outputs and milestones

Milestones mark specific points on your project timeline at which you reach an agreed status. They often are also the points in a project where you present to or involve a wider audience and communicate the progress and status of your project.

Set up your milestones to match your planned iterations – and carefully manage the expectations of what you can or cannot deliver at those points. The outputs you promise should be specific, measurable, and realistic and will often be called deliverables here. ⁸⁶ Typical milestones include:

• → Intermediate research report done

• → Key insights identified and prioritized

• → Opportunity areas identified and prioritized

• → Ideation sessions done with key stakeholder groups

• → A defined number of ideas generated

• → A defined number of detailed concepts developed

• → A certain number of low-, mid-, or high-fidelity value/look-and-feel/feasibility/integration prototypes tested and feedback analyzed

• → A certain number of prototypes tested with real customers and feedback analyzed

• → Business cases for a defined number of prototypes validated

• → Pilot with frontline staff done and analyzed

In contrast to traditional projects, your deliverables stay living outputs. They will grow further and change as you go forward.

In some organizations these milestones might be squeezed into an existing stage-gate process, often consisting of phases like discover, scope, plan, develop, test, launch, and review. Even if this is not ideal, it unfortunately often reflects business reality. Between these stages, there are gates – decisions on whether a project will get a (conditional) go, be put on hold, be recycled, or be killed. Be aware that if you “black-box” an iterative structure with labels like these, you’ll still need to meet existing hard criteria at each gate to get a go for the next stage. Often, you can define “must-have” and “nice-to-have” criteria for each project stage. Try to define the criteria mentioned in this chapter as “must-haves,” since you can be certain you will meet them if you follow the process.

Going beyond the tangible

Many service design activities will have tangible outputs (e.g., research data, documented insights, idea sketches, prototypes, research and project reports, etc.). However, as we have seen throughout the previous chapters, sometimes the more intangible or implicit outcomes of your design activities will be more important for you. For example, early prototyping activities might primarily be used to create a shared understanding and alignment amongst the interdisciplinary project team – and are not just done for the ideas. ⁸⁷ Or take qualitative research: while you collect a lot of concrete data on your research wall, one of the key goals might be to create empathy with your stakeholders within the design and management team. That’s not something you can put into a report.

Even though the rest of your organization will usually be looking at the tangible outputs, it is equally important to carefully assess and plan your intangible outcomes. They often turn out to be the driving factors for successful co-creation, reducing resistance within the organization and increasing your chances to implement in the long run.

Flow of project knowledge, ideas, and insights

Key intangible outcomes (like empathy and deeper contextual knowledge and understanding of the stakeholders, the problem, and potential solutions) are almost inseparable from the people who developed these in your team. While some stakeholders are part of the project from beginning to end, many more will only join for some parts of the journey. This offers an opportunity for new ideas and perspectives and raises the challenge of passing on the important knowledge so they can meaningfully contribute. When people leave the project there is also a danger of losing essential parts of that hard-earned empathy, deep knowledge, and understanding. Plan to keep the flow of knowledge and empathy intact by building an unbroken chain of people across the project,supported by tangible documentation.

It can be helpful to map out the flow of people, key outputs, and outcomes across your design process to better understand where empathy, deep knowledge, and understanding are generated and how they are passed on to upcoming steps – through people or through tangible outputs like documentation or prototypes.

Figure 9-11. FLOW OF EMPATHY
Handover through documents will not carry over empathy. Keep up the flow of empathy by keeping key people in the project from beginning to end.

Document your process and decisions

The service design process is adaptive and iterative. As you are constantly reviewing your progress and making changes, the real process will deviate from your original plan. As you go along, create concise documentation of the changes you made and the underlying reasons. This can be as simple as filing handwritten meeting minutes, or just taking photos of flipcharts or sticky notes that contain those details. However, it might also be necessary to prepare a glossy slide deck to run a decision past the board or to follow an official template for change requests.

Important decisions that are undocumented might be challenged, creating unnecessary discussions or, in the worst case, forcing you to do over.

Document your tangible outputs

Most activities in the service design process have tangible outputs which in turn act as the inputs for the next set of activities. These outputs are important for your documentation as they allow you to trace back outputs like prototypes to the underlying insights from research or even back to the original quotes from your research data. ⁸⁹ A simple indexing system can help to connect the original data from your research to your prototypes or implemented solutions.

If a piece in the chain is challenged, you can retrace some steps and re-examine the underlying assumptions or conclusions, or explain where it came from and who contributed. ⁹⁰

Keep the documentation accessible

You should decide up front how and where to store your tangible outputs so you can make them accessible quickly at any stage later in the project. In smaller projects, a big project room with plenty of wall space might be enough. There, you can sort all the assets onto your research wall and idea/concept wall and exhibit your prototypes on tables or in a distinct area. In more complex projects, you should still keep a physical project space for key assets, but also plan for a structured virtual space where you keep the complete dataset. ⁹¹

Figure 9-12. A BREADCRUMB CHAIN OF EVIDENCE
As tangible outputs are the physical evidences of your service design process, your documentation trail becomes your chain of (physical) evidence, complementing your chain of empathy. Such a chain helps to find raw data revealing the problem your developed prototype strives to solve. Indexing helps to keep track. ⁹²

Documenting the intangible outcomes

Decide which of your intangible outcomes you want to add into the official documentation, and how. Many organizations have a bias toward the tangible outputs, and making sure you document the intangible outcomes can help you shift that focus toward a more balanced view. For example, you might include photos and use storytelling from a high-energy prototyping jam to underline the effects on interdisciplinary collaboration and alignment on shared goals (“We have never seen them work together before!”).

Be careful though, since this is not always easy to do. Some of the effects can be quite subtle or hard to show. Reflect on this within your core project team and strategically include the parts you feel comfortable with.

Manage focus between big picture and details

One of the key elements of service design is the constant switching between different aspects of the service – from the big picture to the details. Practically this means, for example, going back and forth between a focus on details (like single steps of the customer journey or even specific user stories or jobs to be done) and the orchestration of the end-to-end customer journey across all those steps. Make sure to balance your attention between working on single touchpoints versus consistent and iterative development of holistic service experiences.

When you are managing a service design process, it is important to do this systematically. Decide which perspective might be most valuable as a next organic step in your process (e.g., customer experience, stakeholder network, business model, organizational feasibility, or technological feasibility). But then also check the effects of the changes you’ve made on the service as a whole. This is especially important when you have split up the project team and started to work in parallel. Build those checks into your regular project structure – for example, by attaching them to specific milestones in the process.

Manage problem and solution

The same back-and-forth applies to the interdependence of problem and solution. When navigating through your iterations, make sure to keep a constant eye on both your potential solutions and whether they trigger new problems which might lead to new, better solutions. These kinds of iterations can be observed in the design behavior of experienced designers and often happen organically. If you and your team are new to this, you might have to explicitly step back and reflect on where you stand in this problem-and-solution space: “Proposed solutions often directly remind designers of issues to consider. The problem and solution co-evolve.” ¹⁰⁰

Day-to-day project management

In terms of the daily tasks of project management, service design projects are not much different than other projects. Here are a few tips to help you stay sane:

• → Do. Now.

  Service design is about doing. Refer to Chapter 5, Chapter 6, Chapter 7, and Chapter 8 for tips on how to do and manage specific activities.

• → Talk briefly. But talk often.

  If you do not align with your fellow project team members, things can quickly go astray. But outside your core service design activities, try to keep coordination efforts lean and efficient. Consider introducing a daily stand-up meeting (see textbox) to align the team on a day-to-day basis and make sure problems get identified and solved quickly.

• → Make process and progress visible – preferably physically.

  One of the biggest problems in projects arises when activities are stuck and no one notices. Create visual process and progress boards and put them up in your workspace so everybody can see them and trigger action if necessary. Of course, if you are working with a distributed team you might have to switch to a virtual solution. But the rule stays: make sure it does not get buried in a file folder far, far away, but becomes visible in a popular virtual space (e.g., the start page of your internal social network).

• → Keep your rhythm.

  When a project hits a tricky problem, it can be tempting even for experienced designers to lengthen the current iteration until team members feel they have the perfect solution. Resist this temptation! Timeboxed iterations with regular reviews ¹⁰¹ are even more valuable at times like this.

• → Orchestrate quiet times and times of intense collaboration/exchange.

  Service design can be used to seek solutions for wicked problems. This can be hard and requires a deep understanding of the matter. Try to create safe spaces of uninterrupted work time for people to dig into those challenges. During those periods, prefer asynchronous communication like email over instant or face-to-face communication. At the same time, make sure there are enough opportunities for formal exchange (i.e., workshops) as well as plenty of informal opportunities to just run into each other to lower the barriers for personal exchanges.

• → Choose your context.

  This sometimes is neglected, but try to choose wisely where you and your team plan to work. Working on location at your client’s office will be different than just visiting every now and again. When do you need to limit external exposure? When do you need the (informal) exchange? ¹⁰³

• → Deal with unavoidable conflicts in a timely manner.

  You will find that the service design approach has many built-in strategies that help you to avoid conflicts in the first place. You can find them in the overall approach (e.g., the strategic use of boundary objects or prototypes for communication and development of a shared understanding, and the iterative nature of the process to reduce risks) as well as in specific toolsets. ¹⁰⁴

Conflicts that are more emotional or arise from interpersonal relationships (“I just cannot stand that guy!”) are harder to tackle and usually require a different skill set. Hence, in the long term, consider training your team in conflict resolution up front. That allows them to quickly notice and resolve conflicts themselves before they interfere with the atmosphere in the team. Consult with a professional mediator on how you should proceed or check the conflict resolution literature for an overview on available options. ¹⁰⁵

Onboarding and communicating with co-creators

Co-creation is at the heart of service design. Over the course of a project you might need to onboard many people to your extended project team. Make sure you plan for this, as it takes time. You might need to get permission before you can invite or work with people from other departments or external experts. In any case, almost everybody needs lead-in time to make space in their own schedule for your project. The people you might want to work with are probably not sitting around doing nothing and waiting for you to call. You even might have to get through their natural defense mechanisms (“Oh, another project …”) before they will commit themselves to join your process – even if it is just for one workshop.

True co-creation means you also need to create and maintain a sense of co-ownership with your co-creators beyond their direct involvement. This implies that they are not just involved but can also see or at least sense the impact of their own contributions later on. Try to regularly update your co-creators on what is happening. This, in turn, ensures buy-in. There is a real danger in a “co-create-and-forget” mentality. Buy-in will only work if you keep people in the loop and give them the opportunity to see and experience the effects of their own contributions.

Be aware, however, that you still need to carefully manage expectations during your co-creation sessions so everyone understands that not all contributions will make it into concepts or prototypes, let alone the eventual service solution.

Regardless of how small the contribution is and whether it is used later or not, it is always good practice to track it and give credit. In its simplest form, this involves keeping lists of participants for all the activities you do during your process. Decide how you want to and can best give credit in your project – considering the realities within your organization – so it is actually meaningful to your participants.

Content reviews

At many steps in your service design process, you need to do a content review – that is, reflect on the quality of your outputs and make decisions based on that. Many of the core activities of service design have those key reflective elements already built in. In research, have a look at methods of data synthesis and analysis. ¹⁰⁶ In ideation, especially check out the pre-ideation methods or any methods on selecting ideas. ¹⁰⁷ And for prototyping, there is reflection mainly in the evaluative prototyping methods and subsequent synthesis and analysis stages. ¹⁰⁸

Content reviews are usually done by the core project team together with selected stakeholders from the extended team. It can be useful to include an additional content review as part of your iteration review session before moving on to the team retrospective.

Team retrospectives

You also need to address your learnings on the process itself, your mindset, and the quality of your collaboration within the core or extended project team. This is done during team retrospectives, usually carried out within the core project team.

There are many ways to do an effective retrospective of past iterations, and there are many useful questions you can ask. See the textbox Conducting a team retrospective for one common approach. ¹⁰⁹ In a project with people working full-time, a more formal iteration review should be done at least every couple of weeks.

Unless there is an escalation or your project sponsor requests formal documentation, your iteration planning and any of your intermediate documentation can usually be quite rough. Create visual notes on flipcharts that everyone writes on simultaneously or take photos of your sticky notes. It’s important that you do it and learn from it. But do not try to make it pretty – it will change again too soon.

Continual improvement of the Olympic spectator experience (when you know it won’t be right on day one)

AUTHOR

Alex Nisbett Service Designer, Spectator Experience, London Organizing Committee of the Olympic and Paralympic Games

When it finally came to game time, the organizers of the London 2012 Olympic and Paralympic Games were clear on one thing: that it wouldn’t be right on day one. Or day two, or even day three. In fact, they were well prepared for things to go wrong (they did), and understood the value of continual improvement of the spectator experience.

As part of the team who designed and delivered the spectator experience at London 2012, one of my roles as Games time approached was to design for, and then support this continual improvement.

We created a simple, repeatable process to help identify the positive and negative experiences across the Games, which could be shared with venue and functional teams to help them make improvements to the services they were providing to the 12+ million spectators who made it to the Games:

Vodafone: Retail meets service design

AUTHORS

Marta Sánchez Serrano Head of Commercial Strategy and Operations, Vodafone

Jesús Sotoca Consultant and Strategic Design Director, Designit

Vodafone, one of the world’s leading multinational communications companies, was ready to transform its approach from focusing on sales to focusing on clients. As part of that plan, the company envisioned developing a new store concept focused on user experience. They wanted to interact with customers in a different way and increase customer satisfaction by creating a unique experience. Designit came on board to help them conceptualize, design, and implement the new service experience in their stores in Spain.

A multidisciplinary team of 12 people from both Vodafone and Designit led the project (although more than 90 professionals were involved in the extended team), in which 30 key processes in the shop and the back office were redesigned. Eight weeks of live prototyping were carried out after the first implementation.

Itaú’s design challenge: New brand’s tone of voice for digital channels

AUTHOR

Clarissa Biolchini Design Consultant and Service Design Specialist, Laje

In December 2015, Ana Couto Branding and Laje, a Brazilian branding agengy and its innovation cell, were invited by Itaú – one of the biggest private banks in Latin American – to develop a project for them.

The project’s goal was to help Itaú’s team to redefine their brand’s tone of voice for digital channels. The bank’s team would have to co-create their own results. The interesting detail of this project was the type of challenge to which we applied service design tools, since our client’s main challenge was related to a communication problem, not a specific product or service issue.

Ana Couto Branding’s team, for which I was one of the main facilitators, created a 5-day design sprint for 25 participants from across the organization and selected external stakeholders. This included participants from different areas of the bank and a couple of representatives from Itaú’s advertising agencies; on top of that we requested 12 end users and a research mediator for the tests. We worked for a few weeks with a team of four people to prepare the sprint and align it with the sponsor.

Itaú is known to be an innovative company in Brazil, already very focused on customer experience with a strong design culture. As Danielle Sardenberg, Itaú’s Marketing Channels Superintendent, said, “It was Itaú’s request to have a co-creative sprint for this specific brand demand, in order to create a collaborative approach, with deep understanding of the problem and excellent results, in a much faster time frame, compared to normal agency processes.”

Although Itaú’s internal culture is familiar with new co-creative and innovative methods, this design sprint with a specific focus on branding required careful preparation. “One of our main challenges during the process was finding the right design thinking tools that would be effective in a co-creation approach to redesign the brand’s tone of voice in its digital channels,” said Danilo Cid, Creative Director and Partner at Ana Couto Branding.

At first, we created activities to help the participants empathize with the bank customers’ needs, applying tools such as digital user-based personas, empathy maps, and expectation maps. The teams co-created their customer journeys based on a daily use of Itaú’s digital channels, and another specific journey focused on one digital activity. This allowed them to analyze the bank’s digital services in detail, giving us answers about the amount of time end users utilized the digital channels and also the appropriate tone of voice. We also used card sorting and a “physical voting” method, where the participants had to walk around in the room to vote “yes” or “no” using their body movements. This ultimately helped them to define some specific criteria regarding their brand’s communications, like what expressions should or should not be used in the bank’s digital channels when communicating with clients.

1. Day 1: Participants were invited to interact with some communication material from the bank.

   

2. Day 2: Participants were led through customer journey maps.

   

3. Day 3: We brainstormed a plethora of ideas on words for the brand’s tone of voice.

   

4. Day 4: Participants did an energizer in which they had to draw their partner without looking at the person.

   

5. Day 5: The team helped the participants to consolidate the results of the design sprint.

   

Regarding the customers, Sardenberg said, “Along the process we had great insights for communication from the perspective of the clients.” We realized that the customers prefer red a more direct and friendlier tone, compared to the more formal one the bank had previously used in its communications. During the ideation phase, the teams co-created new rules and guidelines for the communication touchpoints and were able to build prototypes of the bank’s communication items, such as ads, text replies to the digital devices, and customer service scripts. These prototypes were tested with real clients on the fourth day of the sprint.

During the sprint days, “Itaú’s teams reacted very well to the sprint, since the process involved many of the bank’s departments that understood the complexity and relevance of the project,” said Patricia Martins, Itaú’s Marketing Channels Manager. We were easily able to notice the empowerment of the participants and their engagement with the project.

In just five days our team, together with the client’s team, was able to deliver the new guideline for Itaú’s communication across all digital channels and create a shared understanding of the tone of voice across all teams involved in the bank’s communication and sales materials.

Our main takeaway from the project was to understand and be able to create a more assertive way for the bank to communicate, in a friendlier and less authoritative tone of voice. And from the organizational point of view, the project has inspired us and made it possible to apply its results in the bank’s other divisions.

— Patricia Martins, Marketing Channels Manager, Itaú