Why?

Services, as co-created value exchanges, are fundamentally human interactions. They are often human-to-human exchanges, like in retail, medical, hospitality, or advisory services. But even in many digital or machine-based services, the technological platform essentially mimics the functions of a human being as it processes your order, connects you, gives you information, or sells you a ticket.

Theater offers perhaps the ultimate toolkit to model, prototype, and play around with human–human or human–digital interactions. It’s important to think not only of the theater stage, but of the rehearsal room, technical desk, prop studio, backstage areas, and everything else which enables a theater to both develop and deliver experiences. With thousands of years of history, theater – or more generally, the performing arts² – enjoys a uniquely mature, highly creative, and utterly practical toolset which is fast, effective, and fun. Unlike almost every other prototyping method, the tools of show business focus on emotion, the core of a great experience. And once you have gotten past the initial inhibitions of your team, they are easy to use as everyone understands the terminology. There is no need to introduce confusing new terms like touchpoints, personas, processes, and tangibles when everyone can already talk about scenes, characters, stories, and props.

The relevance of theatrical thinking and practice to services has been explored for many years, starting perhaps with Goffmann’s dramaturgical examination of human life in the 1950s,³ and becoming more explicit with Grove and Fisk since the 1980s.⁴ They point out many further parallels between the worlds of service and performing arts – such as the observation that services and theater performances share a transitory nature and “must be experienced in real time if they are to be appreciated.” Important themes are staging, actors/audience, performance, and improvisation – all considerations which apply to both worlds, and where theater can be a reference for service designers.

What are the techniques?

Theatrical techniques in service design should not be confused with business theater. This is the performance, usually by a visiting troupe of professional actors, of small playlets that have been developed to carry a message to a particular audience on a certain theme. Business theater can help develop empathy for users, get buy-in for a service design project, and spread awareness of the need for or results of a service design project, but it is not in itself truly a design technique.

Yet there are other theatrical techniques and lenses that can be applied or adapted as service design techniques, especially in the prototyping phase. Empathy techniques, storytelling, character work, improvisation, Forum Theater, storywriting, scripts, subtext, message, status, direction, an actor’s interpretation of a script or role, dramatic arcs, surprise, staging (especially considerations of the use of space and of backstage and frontstage boundaries) – all these concepts and tools can be used in the practical creation of a new service.

1. Theater offers perhaps the ultimate toolkit to model, prototype, and play around with human–human or human–digital interactions.

   

Step-by-step guide PREPARATION

1. Decide or reflect on purpose and prototyping or research questions: Before you start, decide or reflect on the purpose and the prototyping or research questions. What do you want to learn? Do you want to test the whole or just a part of the experience? Which part are you most interested in? How detailed do you need or want to get?

2. Create safe space: An investigative rehearsal is an unusual tool, so it needs to take place in a situation of safe space.⁷ For a newer team, you will need some time to create that mental and physical setting. Consider doing some warm-up activity (see #TiSDD Chapter 4, Facilitating workshops, for examples) and establish the Rules of Rehearsal to agree on how to work:

   

3. Find a starting point: The rehearsal will also need a starting point – and finding that starting point can be part of creating the safe space. For a project based on existing services or experiences, the starting point might be a set of stories generated from research or assumptions by the workshop participants (e.g., created through storytelling games). Extreme stories of emotional customers or difficult situations are most productive. You can quickly turn these into storyboards to help people get them straight and to act as a reference during the rehearsal. For a very new service, you can start with some future-state customer journey maps instead.

4. Set up teams, room, and initial story: Depending on the group size, divide the room into several teams of about 4–7 people each. Each team starts with one story or one version of the prototype journey. They will need a little time to prepare a (key) scene of the story, but don’t give them too long – the longer they have, the more nervous they will be. Tell them you only expect a rough draft as a starting point and give them no more than a few minutes. If anyone in the team was part of the original story being played, they should not play themselves in this re-creation.

Step-by-step guide USE/RESEARCH

1. Rehearse to investigate: The investigative rehearsal process itself has three phases. With inexperienced groups, it is wise to stick to this quite rigid structure, or else the creativity can get out of hand and the work will become unfocused and trivial.

   • Watch: First, ask each team to play through their scene in just a couple of minutes, to give everyone an overview of what happens. Ask them to use the whole set, entering and leaving the room as a real person would (they should use a real door as the entrance if possible). Do not comment on the scene, but applaud when it is done. You might look at all the teams’ scenes quickly, then decide which one to explore first.

   • Understand: Now ask a team to start again, and ask people outside the scene to call “stop” when they notice anything interesting. This might be a physical challenge, an odd process step, a particular choice of words, or revealing body language. There might be a “stop” every few seconds – as a facilitator, try stopping after just three seconds of the scene and asking, “What do we know already? How do we know that?”

     The goal of this phase is a deep understanding of what is happening on a physical and motivational level. Ask questions like “How is he feeling?” or “What’s happening right now?” You might want to help participants by encouraging them to be specific. If they say, “I see the clerk being open and honest,” ask them, “How exactly is the clerk being open and honest? What is she doing which makes her seem open and honest?” Note the insights and move on – do not change the scene. If the scene is a long one, you might not need to run through all of it in detail – just keep going as long as is meaningful. End with applause.

   • Change and iterate: Now ask the team to play the scene again, but this time the audience should call “stop” when they have an idea of what could be different on the service side. Ask for alternatives, not improvements. When a “stop” comes, tell them not to describe the idea, but to show it by taking over a role in the scene (Rule 1: “Doing, not talking”). If possible, change only one thing at a time and let the changed scene run for a while, so the group have a chance to see the effect of each change before stopping again.

     When you have had enough time to see the effects (if any) of a change, stop the scene again and ask the audience – not the volunteer who suggested the change – what the volunteer’s tactics were (“What did they change?”) and what they noticed (“What happened then? How did it feel?”). You might then ask the other people inside the scene how they experienced the change. Sometimes – quite rarely – it can be helpful to ask the volunteer to explain their intention. In your discussion of the changes, try to avoid judgment – a change is neither good nor bad, it simply has a certain effect which you might be able to use. Try to pinpoint what the effect was, and record the idea (and perhaps its effect in this scene) on the flipchart. Then decide if you want to follow it up by continuing the scene from there, look at alternatives, or return to the original version. Iterate, iterate, iterate.

2. At all times, keep a concise list of bugs, insights, ideas, and questions: It is key to keep track of everything you learn during any part of the rehearsal session. After each step, ask the team to take a few moments to reflect on what worked, what didn’t work, what they would like to change or try next. Document the results on a flipchart with separate sections for insights, bugs, ideas, and new questions.

3. Decide on a next scene and repeat: After the current scene has been finished, switch to the next team or revisit your original starting points and decide on which part to try next. Then go again. Stop when either the set time for your workshop is up or the group have hit a roadblock that requires them to switch to other core activities next – for example, doing some more research, more intensive ideation, or switching to other prototyping methods.

4. Document: Document and finalize your work. Use customer journey maps, photo storyboards, or a video to document the latest version of the service experience from your rehearsal. Briefly reflect on your documentation flipcharts and identify key insights, ideas, bugs, and questions. Try to agree on potential next steps to advance the project based on your new learnings.

1. A team “stress testing” the returns procedure of a retail service using investigative rehearsal. Two team members simulate the encounter, while others are ready to step in with alternatives to process, setting, systems, or behavior. The designer behind the laptop represents a human being in the original scene – but she could easily represent (or become) a digital system.

   

2. After each step the team reflect on what worked, what didn’t work, what they would like to change or try next. Keep it brief. Then move on, sticking to “Please don’t tell me, show me!”

   

Method notes

• Keep them focused and moving: The facilitator will need to keep the team focused, moving, and honest. At the same time, they must keep the team realistic, making sure they are not creating a perfect world where everyone really needs their service and is enthused about it. Experience shows it’s better to demonstrate a problem or advantage within the scene than to talk about it, so they will often have to say, “Please don’t tell me, show me!”

• Explorative or evaluative – studio or contextual: The investigative rehearsal as described here is a great explorative prototyping activity. In its most basic form it only requires people, an empty room, and an inspiring prototyping question. However, if you decide to run the session in context – perhaps at the actual workplace of your users with real staff taking over the roles, or in a very good simulated environment – investigative rehearsal can produce real and valid learnings to support your decision making.⁸

• Keeping track: As you go through the scene, you will quickly build up a long list of tested ideas, generated by the participants themselves from their own real stories or their prototype. You can reflect on these later, and decide which ones to incorporate in your next prototype, future-state customer journey map, or implementation.

Don’t call it “role-play”! The term is unpopular because it is misused in many training courses. Technically, investigative rehearsal is not role-play, but it looks very similar. So, call it rehearsal, simulation, bodystorming, a service walkthrough, or don’t call it anything – just say “show me.”

Variants: Partial rehearsals or walkthroughs

Based on the investigative rehearsal, there are several more types of often accelerated partial rehearsals or walkthroughs. They are intended to help people who are designing or delivering a service become familiar with the sequence, connections, and intentions of an interaction without (for the moment) considering their presence or own effect on others – their body language, tone of voice, facial expressions, etc. In the following rehearsal variants, the communication is usually directed inward at the team, not outward toward a customer or audience:

• Sitzprobe or seated investigative rehearsal or talkthrough: The Sitzprobe usually is a spoken rehearsal⁹ – the team speak through a service scene, e.g. seated in a circle. They do not worry about timing, movement, or technicalities. They simply go through the verbal element of the service, perhaps with quick descriptions of the actions which cannot now be seen, such as “Then I give him the envelope …” Variants include speaking through the service very fast, taking on each other’s roles, or even running the service scene backwards. Seated rehearsals can involve customers as well as frontstage and backstage staff and are great to get a first impression of the bigger context, allowing us to explore the generic flow of conversations across the holistic service experience.

• Blocking rehearsal: During a blocking rehearsal, the team move through the actions of a service scene, if possible in the real context or a simulated environment. There are no verbal elements, or verbal elements are reduced to the beginning and end of each statement, such as, “So let me explain how you open … blah blah blah … and now you can see the reading.”

• Technical rehearsal: The team move through all the technical aspects of a service scene, making sure that every single technical action is performed – flipping the switch, starting the software, packing the envelope. Everything non-technical (movements in the room, spoken elements) is abbreviated or skipped. The technical rehearsal is sometimes combined with the blocking rehearsal.

Partial rehearsals are flexible tools that can be used all across the design process. During research, they can help to elicit and document existing service processes. Try getting all stakeholders of a business process in one room and doing a seated rehearsal. Have them simulate a typical case, talking through each individual step, and record the results. Later, during prototyping, these techniques can help you to choose the best lens to efficiently move your prototypes forward. Moving toward implementation, these types of rehearsal are often employed when the structure of a service scene is already quite well developed, but the participants need to become more familiar with it and understand the structure, content, and connections better – until they become internalized and automatic.

Variant: Rehearsal for rollout

An employee’s demeanor and behavior are a crucial part of the service experience for customers. Just like an actor playing a role, a staff member needs to appear professional, show appropriate emotions, and master a complex “script” (the service process) while still being their authentic self, not an automaton. Like actors, too, they need to be able to use stage, costume, and technology to support their performance, and must be able to read their audience and adjust their actions appropriately. When will they have the chance to explore their options, share their discoveries, and find their own voice within the service? Rehearsal during rollout, and indeed during the regular running of a service, can be this opportunity.

Step-by-step guide ROLLING SUBTEXT

1. Introduce subtext: In your rehearsal session, choose a key scene you want to understand more deeply. Make sure everybody already has at least a basic understanding of the scene before diving into the subtext activity. Run the key scene one last time, then stop the rehearsal for a moment and quickly explain the concept of subtext (“Subtext is what we mean, but don’t say”).

2. Add subtext actors to your service scene: Add new actors to the rehearsal and ask them to speak the unspoken thoughts of the people in the scene as it runs. It’s easiest to have one subtext actor for each character, and they can either sit offstage or (more fun) be inside the scene, with their hand on the character’s shoulder. This is simply a visual shorthand for “I am not here, I am invisible,” but it seems to help each pair of actors coordinate.

3. Play through with live (“rolling”) subtext: The character actors play the scene as usual – or perhaps a little slower – and the subtext actors simply speak what they believe their characters are thinking at any moment, using “I” or “me” statements when possible. For example, the character actor might say, “Can you prioritize that?” and the subtext actor might rage, “For f*ck’s sake! Help me before I lose my job, you idiot!”

   To make it possible to follow the action, you might want to start by giving subtext to only one or two characters, then shift focus to others in the scene. It is usually most interesting if the subtext actor and the character actor do not discuss this beforehand – sometimes the character actor will be surprised by the subtext, and this can be revealing.

4. Iterate: Run the scene a few times with variations on the subtext. What do they suggest? Document your key insights, ideas, bugs, and questions, and return to your rehearsal session.

1. Rolling subtext: as two actors play characters in a scene, another actor (wearing a black shirt) speaks aloud the unspoken thoughts of one character. Subtext is what we mean, but usually don’t say. Bringing it into an investigative rehearsal can reveal deeper motivations, needs, and many new opportunities to create value.

   

Step-by-step guide SUBTEXT CHAINS

1. Identify a starting statement: In a rehearsal session, hold the scene at one key statement by a customer or employee, and ask the team, “What would be the subtext of that statement?”

2. Build the chain: Continue by asking, “What would be the subtext of that subtext?” Repeat. As you go deeper, it might be easier to ask, “Why is that important?”

3. Document and/or build a physical chain: Document the different levels of subtext on a flipchart. If you have enough people it can also be helpful to create a physical subtext chain of people in the room. Standing in a line behind the key character, each person represents one level of subtext.

4. Explore emotional and practical chains: After several steps, you will get deeper and deeper into the motivations and emotional lives of the character. For example, a group working on stories from a telecommunication shop might decide that the statement “Look, I really need the internet!” has a possible subtext of “I can’t get the information I need.” Investigating the subtext chain, they might decide it goes like this:

   Statement: “Look, I need the internet!”

   • 1st-level subtext: “I can’t give my clients what they want.”

   • 2nd-level subtext: “I might lose the deal!”

   • 3rd-level subtext: “I won’t get paid!”

   • 4th-level subtext: “I will lose my home!”

   • 5th-level subtext: “I will be unable to protect my family!”

     This is a rather emotional chain. A more practical one for the same situation might be:

     Statement: “Look, I need the internet!”

   • 1st-level subtext: “I need to get online.”

   • 2nd-level subtext: “I need to download a movie.”

   • 3rd-level subtext: “I need to show a movie to my client.”

   • 4th-level subtext: “I need to show my client what I offer.”

   • 5th-level subtext: “I need to help my client make a choice.”

5. Iterate: Explore a few chains with variations on the subtext. What do they suggest? Document your key insights, ideas, bugs, and questions, and return to your rehearsal session.

Method notes

• Assumption-based vs. research-based: This tool supports the deeper analysis of service situations. Often the subtext levels you identify are based on assumptions, but they can still be valuable as they generate great questions that feed back into explorative research or guide your prototyping. However, when used with research data, the method becomes a fuller-bodied way of reflecting on and analyzing that data.

• Basic needs: Usually after 5–7 levels on the emotional chain we get down to very basic human needs like protection, family, acceptance, and love – and these deep levels explain why the customer values our service or is angry about the problem.

• Middle steps: The middle steps of a subtext chain suggest potential offerings we could make. For example, from the practical chain we could ask ourselves: How else could we help the speaker get online? Can we offer them an internet stick, a tablet, a WiFi dongle? How else could we get the movie to them, or help them show it to the client? Could we offer a downloading service, burn a disc, rent out a screening device or location? How else could we help them show the client what they can do? And so on. The emotional chain also offers potential value: How can we help the speaker give the client what they need? Get more deals? Handle cashflow? And so on.

1. A visual sketch of a subtext chain.

   

2. Building a subtext chain works like a deep dive into the motivations and needs of a stakeholder in a rehearsal session.

   

Step-by-step guide PREPARATION

1. Review scope and clarify prototyping questions: Briefly reflect. What is your scope? What do you want to learn from this prototyping activity? Do you want to test the whole experience or just a part? What are the aspects and details you want to test for later? Also think about who you want or need to involve in this walkthrough. Is it just for within the project team, or are you planning to involve potential users or other stakeholders?

2. Prepare workspace and materials: Pick up your desktop walkthrough materials and a couple of big sheets of flipchart paper. Set up the paper on a table. Make sure the table is not too big so everybody can stand around it and contribute at the same time.

3. Brainstorm an initial journey draft: Select a customer/persona and do a brief brainstorm: looking at your new service concept, what are possible steps in the customer journey? Then, quickly sort your sticky notes in chronological order. There is no need to create a full-fledged customer journey yet. Do just enough to get a sh!tty first draft of what the journey could look like.

4. Create maps and stages: Based on your initial journey, what locations are important? Start by creating a big overview map that contains all the relevant locations of the service experience. Then, decide if and where you need to zoom in on certain locations for some part of the service (e.g., zooming in on the interactions that happen in one store inside a shopping mall). If necessary, create a detailed stage plan for each of these locations.

5. Create roles, set, and props: Which roles need to be cast? What needs to be built? Pick a figurine for each of the roles/key stakeholders in your service and quickly build the essential set and props, using paper, cardboard, plasticine, or LEGO bricks to set the stage.

6. Set up roles: Find your actors. Who is going to play which role? Also, it can be helpful to assign someone to keep track of the bugs, insights, and ideas queue during the walkthrough.

Step-by-step guide USE/RESEARCH

1. Do a first walkthrough: Who or what has to move at each step in the journey? Does everything fit together? Put all the actors and props onto their starting positions and, loosely following the events from your journey draft, play through the service from beginning to end. Move your figures around on the map/stages. Act out all necessary dialogue and do all the interactions with other actors, devices, and so on.

2. Keep a list of bugs, insights, and ideas: After each run-through, take a few moments to reflect on what worked, what didn’t work, what you would like to change or try next. Document the results on a flipchart, noting insights, bugs, new ideas, and questions.

3. Decide on the next variation and iterate: Check off the idea that has just been simulated and, in your team, quickly decide (show of hands, simple majority) which of the still open changes and ideas you want to try next. Then go again. If you think that last walkthrough was a real cracker, create a quick, less-than-60-second video pitch of the walkthrough to capture it for later. Stop iterating either when the set time for your workshop is up or when the group have hit a roadblock that requires them to switch to other core activities next – for example, doing some more research or more intensive ideation.

4. Document: Document and finalize your work. Use customer journey maps, photo storyboards, or videos to document the latest version(s) of the service experience from your walkthroughs. Briefly reflect on your documentation flipchart and identify the critical steps in this journey, other key elements, as well as problem areas or questions that need to be addressed in the next steps in the design process.

5. Present (optional): Using a storytelling approach, present your last iteration and key learnings to other stakeholders and gather feedback. It is often useful to also capture the presentation and the final feedback rounds on video and add them to your documentation.

Method notes

• Introduce an observer: Try having at least one observer for each walkthrough to balance judgment and counter the bias of the active players. The observer takes an independent view of the resulting experience and gives feedback to the team.

• See it through: Always force yourself to play a walkthrough all the way to the end. Especially in early iterations, ideas come in abundance and can disrupt the flow. To address that, ask everybody to write their ideas and reflections down and wait to discuss them at the next step. Otherwise, you will never see one idea through.

• Keep the flow: Watch out for talking in the groups, as the method can quickly trigger deep discussions. Encourage the group to simulate their talking points instead by doing different versions.

• Avoid teleporting: Watch out for teleporting. How did that person get here? How did that object get here? Where did they go afterwards?

• Handling too many bugs: If the group are stuck with too many bugs, ask them to step back and do a brief brainstorming session to generate potential solutions. Then go back to simulating these solutions using the desktop walkthrough.

• Introduce a director: If you have trouble in your group making decisions or juggling too many wildly different ideas, introduce the role of a director. Only the director can stop the walkthrough to discuss questions or make changes to the other actors. The changes or ideas are then played through. The learnings are documented. After a set number of iterations (e.g., 3–5), another member of the group gets to be director.

1. Simply moving figures around on the map and acting out the dialogue allows the design team to quickly simulate a service experience, test, and explore alternatives.

   

2. The base of a walkthrough is an overview map that contains all the relevant locations of the service experience. If necessary, create a detailed stage plan for each of these locations.

   

3. Overview plans help to keep track of interconnected locations across a wider geography.

   

Step-by-step guide PREPARATION

1. Choose a user: Who should test this cardboard prototype? Choose a persona, a specific user type, or a key stakeholder.

2. Review scope and clarify prototyping questions: What do you want to learn? Do you want to test the whole or just a part of the object or environment? Which part (literally) are you most interested in? What are the tasks that you expect the user to do there? Think about the context: in which step of the customer journey does the object or environment play a role? Make a list of the tasks you want to test for later.

3. Build the necessary parts: Use simple materials to build the objects/environments or the parts thereof you have chosen to focus on. If the object is interactive, build everything you need to act out any activities.

4. Assign roles and prepare: Split your team to take on the roles of users, operators, and observers, and ask them to prepare their parts. Apart from you as the facilitator, all roles can be played by one or more people. If you are not working with actual users, give the person or people who will act as the user(s) a few minutes to familiarize themselves with and empathize with the needs, motivations, and context of the chosen persona or user type. Allow the operators to practice how to organize all the different parts so they can quickly manipulate and simulate the object’s or environment’s interactions. Finally, ask the person who is going to act as a researcher to prepare the observation session.

Step-by-step guide USE/RESEARCH

1. Test the prototype: Now conduct your test. Ask the user to perform a selected task. As the user starts to use the interface or carefully uses the object (i.e., handling it, pressing buttons, typing on keyboards, pulling handles, etc.), the operators react and simulate the reaction of the object or environment by manipulating, replacing, or adding parts. Iterate until the user has completed the task or failed.

2. Keep a list of bugs, insights, and ideas, and review issues: Make sure that during the whole test the observers record their observations, and create a list of the issues that you discover. After each testing session take a few moments to reflect on what worked, what didn’t work, and what you would like to change or try next. Briefly discuss the issues you discovered and prioritize them.

3. Revise your prototype (optional): Are there any changes you can or should make right now? Remember that changes to cardboard prototypes can be made very easily and quickly. Do them now.

4. Decide on the next task and iterate: Check off the task that has just been simulated and quickly decide which you want to try next. Then go again.

5. Document: Document and finalize your work. Use photos or videos of your prototypes as well as key interactions to document the latest version from your prototyping session. Briefly reflect on your documentation and identify critical issues as well as problem or opportunity areas that need to be addressed in the next steps in the design process.

6. Present (optional): Use a storytelling approach to present your last iteration and key learnings to other stakeholders and gather feedback. It is often useful to also capture the presentation and the final feedback rounds on video and add them to your documentation.

Method notes

• Speak out loud: Encourage users to think out loud while they go through the given tasks.

• Silent operators: The operators are usually silent. Ask them to refrain from explaining how the prototype should work. The rule of thumb is: if the device or computer would not say/print/bleep it, the operators should not either.¹⁶

• How to build: Start by building the basic forms (e.g., the body of a vending machine or the body of a convertible). Then add some of the moving parts. Moving parts can either be roughly built or simply be added or replaced during the simulation to cater for a certain functionality (e.g., the robot arm of the vending machine or the convertible top for the car). Finally, add paper prototypes of software/interface elements (e.g., displays, keyboards, control lamps).

• Use what you have: Cardboard prototyping can get you carried away. People start prototyping everything just because it is fun. However, if you have a tablet lying around, avoid creating a cardboard tablet. Use what you have.

1. Early cardboard prototypes are cheap and easy to make. This has one of the lowest entry barriers of all the prototyping methods.

   

2. The prototypes can be small-scale, actual size, or even bigger than life, depending on their scope.

   

3. Contextual full-scale cardboard prototyping for a citizen-centric council office.¹⁷

   

4. Conceptualizing three material delivery units and building 1:5 scale models.

   

Step-by-step guide PREPARATION

1. Decide or reflect on purpose and prototyping or research questions: Before you start, decide or reflect on the purpose and the prototyping or research questions. What do you want to learn? Do you want to test the whole or just a part of the experience? Which part are you most interested in? How detailed do you need or want to get?

2. Create safe space: An investigative rehearsal is an unusual tool, so it needs to take place in a situation of safe space.¹⁸ For a newer team, you will need some time to create that mental and physical setting. Consider doing some warm-up activity and establish the Rules of Rehearsal to agree on how to work (see box).

3. Find a starting point: Choose a starting point – e.g., a raw idea, or some context based on user stories from research – and prepare props and a space. Then, quickly familiarize yourselves with the chosen story.

Step-by-step guide USE/RESEARCH

1. Watch: Run through the story and have a human play the app or web page. Don’t think digital – be a full human being, but one with superhuman access to knowledge and media, like a knowledgeable butler or “genie in a bottle.” Remember: Don’t play a robot – be a full human being.

2. Understand: Now ask the team to start again, and ask people outside the scene to call “stop” when they notice anything interesting. This might be a physical challenge, an odd process step, a particular choice of words, or revealing body language. There might be a “stop” every few seconds. The goal is a deeper understanding of what would happen on a physical, emotional, and motivational level, if it was an inherently human interaction. Encourage participants to be specific. If they say, “I see the concierge being open and honest,” ask them, “How exactly are they being open and honest? What are they doing that makes them seem open and honest?” Note the insights and move on – do not change the scene just yet. If the scene is a long one, you might not need to run through all of it in detail – just keep going as long as is meaningful. End with applause.

3. Change and iterate: Now ask the team to play the scene again, but this time the audience should call “stop” when they have an idea of what could be different on the service side. Ask for alternatives, not improvements. When a “stop” comes, tell them not to describe the idea, but to show it by taking over a role in the scene (Rule 1: “Doing, not talking”). If possible, change only one thing at a time and let the changed scene run for a while, so the group have a chance to see the effect of each change before stopping again. Try to pinpoint what the effect was, and record the idea (and perhaps its effect in this scene) on the flipchart. Then decide if you want to follow it up by continuing the scene from there, look at alternatives, or return to the original version. Iterate, iterate, iterate.

4. Digitize the experience: After a few iterations, consider how you would digitize the experience. Ask the team to pick out key ideas from your documentation flipchart and start to sketch out the interfaces. For example, how can an app appear to be “open and honest”? Do a quick sharing round and capture your feedback.

5. At all times, keep a concise list of bugs, insights, and ideas: It is key to keep track of everything you learn during any part of the rehearsal session. After each step, ask the team to take a few moments to reflect on what worked, what didn’t work, what they would like to change or try next. Document the results on a flipchart with insights, bugs, and new ideas/questions.

6. Decide on a next scene and repeat: After the current scene has been finished, revisit your original starting points and decide on which part to try next. Then go again. Stop either when the set time for your workshop is up or when the group have hit a roadblock that requires them to switch to other core activities next – for example, doing some more research, more intensive ideation, or switching to other prototyping methods.

7. Document: Document and finalize your work. Use paper prototyping, wireframes, interactive click-models, customer journey maps, photo storyboards, or a video to document the latest version of the service experience from your rehearsal. Briefly reflect on your documentation flipcharts and identify key insights, ideas, bugs, and questions. Try to agree on potential next steps to advance the project based on your new learnings.

1. A team “stress testing” the returns procedure of a retail service using investigative rehearsal. Two team members simulate the encounter, while others are ready to step in with alternatives to process, setting, systems, or behavior. The designer behind the laptop represents a human being in the original scene – but she could easily represent (or become) a digital system.

   

2. After each step the team reflect on what worked, what didn’t work, what they would like to change or try next. Keep it brief. Then move on, sticking to “Please don’t tell me, show me!”

   

Method notes

• Don’t play a robot – be a full human being: Especially at the start of a session, it is important to remind actors they’re not trying to be a technical system. It can be helpful to remind them that between 20 and 50 years ago, any of the jobs you might discuss right now as part of an app would have been done by a human being. What would that human have done? How would they have behaved?

• Keep them focused and moving: The facilitator will need to keep the team focused, moving, and honest. At the same time, they must keep the team realistic, making sure they are not creating a perfect world where everyone really needs their service and is enthused about it. Experience shows it’s better to demonstrate a problem or advantage within the scene than to talk about it, so they will often have to say, “Please don’t tell me, show me!”

• Explorative or evaluative, studio or contextual: The rehearsal as described here is a great explorative prototyping activity. In its most basic form it only requires people, an empty room, and an inspiring prototyping question. However, if you decide to run the session in context – perhaps at the actual workplace of your users with real staff taking over the roles, or in a very good simulated environment – investigative rehearsal for digital services can produce real and valid learnings to support your decision making.¹⁹

Don’t call it “role-play”! The term is unpopular because it is misused in many training courses. Technically, investigative rehearsal is not role-play, but it looks very similar. So, call it rehearsal, simulation, bodystorming, a service walkthrough, or don’t call it anything – just say “show me.”

Step-by-step guide PREPARATION

1. Choose a persona or user type: What user are you going to test this paper prototype with? Choose a persona or a specific user type.

2. Review scope and prototyping questions: Review the scope and the prototyping questions for this prototyping activity. What do you want to learn? Do you want to test the whole or just a part of the interface? What are the tasks that you expect the chosen user to do? How detailed do you need or want to get? Make a list of the tasks you want to test for later. Also think about who you want or need to involve. Is it just for within the project team, or are you planning to involve potential users or other stakeholders?

3. Sketch necessary parts: Create hand-sketched versions of everything the user will deal with while using the interface. Make sure this includes not only windows, menus, dialog boxes, pages, pop-up windows, and the like but also actual key content and/or plausible data.

4. Assign roles and prepare: Split your team to take on the roles of user, (computer) operator, and observer. Apart from you as the facilitator, all roles can be played by one or more people. Give them some time to prepare and practice their roles for the test and subsequent steps. Specifically, give the person or people who will act as the user(s) a few minutes to familiarize themselves with and empathize with the needs, motivations, and context of the chosen persona or user type.

1. Creating hand-sketched versions of the interface: windows, menus, dialog boxes, pages, pop-ups, and so on.

   

2. Conducting the test: a user “clicks” (i.e., touches the buttons with a finger). As the user starts to use the interface, the operators react and simulate the changes in the interface by replacing or adding parts of the interface.

   

Step-by-step guide USE/RESEARCH

1. Test the prototype: Now conduct your test. Introduce the project and the context of your prototype and ask the user to perform a certain task from your list. Briefly explain how they can “click” (i.e., touching a button or a link with a finger) or “type” (i.e., writing data in appropriate fields using a pen). As the user starts to interact with the interface, the operators react and simulate the changes by replacing or adding parts of the interface. Iterate until the user has completed the task or failed horribly.

2. Keep a list of bugs, insights, and ideas, and review issues: During the whole test the observers will record their observations and create a list of the issues that they discover. After each testing session take a few moments to reflect on what worked, what didn’t work, what you would like to change or try next. Briefly discuss the issues you discovered and prioritize them.

3. Revise your prototype (optional): Changes to paper prototypes can be made very easily and quickly. So, are there any changes you should make right now?

4. Decide on the next task and iterate: Check off the task that has just been simulated and quickly decide which you want to try next. Then go again.

Method notes

• Speak out loud: Encourage users to think out loud while they go through these tasks.

• Silent operators: The operators are usually silent. Ask them to refrain from explaining how the prototype should work. The rule of thumb is: if the device or computer would not say/print/bleep it, the operators should not either.²²

• Discuss if necessary: You can consciously decide to enable a team discussion if this becomes necessary during the process – for example, over a roadblock that cannot be solved right away.

Step-by-step guide PREPARATION

1. Choose a persona or user type: What user are you going to test this paper prototype with? Choose a persona or a specific user type.

2. Review scope and prototyping questions: Review the scope and the prototyping questions for this prototyping activity. What do you want to learn? Do you want to test the whole or just a part of the interface? What are the tasks that you expect the chosen user to do? How detailed do you need or want to get? Make a list of the tasks you want to test for later. Also think about who you want or need to involve. Is it just for within the project team, or are you planning to involve potential users or other stakeholders?

3. Sketch necessary parts: Create hand-sketched versions of everything the user will deal with while using the interface. Make sure this includes not only windows, menus, dialog boxes, pages, pop-up windows, and the like but also actual key content and/or plausible data.

4. Import into prototyping app: Set up the prototyping app. Take photos of your hand-sketched interfaces and import them into the prototyping app. In the app you can now define click areas that link between sketches – effectively creating a working interface.

5. Assign roles and prepare: Split your team to take on the roles of users and observers. Give them some time to prepare and practice their roles for the test and subsequent steps.

Step-by-step guide USE/RESEARCH

1. Test the prototype: Now conduct your test. Introduce the project and the context of your prototype and ask the user to perform a certain task from your list. Briefly explain how they can interact with the click-model and observe how they react to the interface. Iterate until the user has completed the task or failed horribly.

2. Keep a list of bugs, insights, and ideas, and review issues: During the whole test the observers will record their observations and create a list of the issues that they discover. After each testing session take a few moments to reflect on what worked, what didn’t work, what you would like to change or try next. Briefly discuss the issues you discovered and prioritize them.

3. Revise your prototype (optional): Changes to your prototypes can still be made very easily and quickly. So, are there any changes you should make right now?

4. Decide on the next task and iterate: Check off the task that has just been simulated and quickly decide which you want to try next. Then go again.

1. Special prototyping apps allow anyone (even without prior knowledge) to create interactive click-models of an interface by taking photos of hand-sketched screens, and then defining buttons and linking them to other screens. They can be shown to potential users for testing or storytelling to gather valuable feedback.

   

Method notes

• Speak out loud: Encourage users to think out loud while they go through these tasks.

• Discuss if necessary: You can consciously decide to enable a team discussion if this becomes necessary during the process – for example, over a roadblock that cannot be solved right away.

• Show and tell: Instead of letting the users operate the click-model themselves, an operator might show them how the app works. This can be useful to elicit feedback without having to create all the otherwise necessary variants.

• Film it: Filming the use of the click-model while speaking out loud what you are doing with the app is a great way to communicate the intent of your design.

Step-by-step guide PREPARATION

1. Choose the user: What user are you going to test the wireframes with? Choose a persona or a specific user type.

2. Review scope and clarify prototyping questions: Briefly reflect. What is your scope? What do you want to learn from this prototyping activity? Do you want to test the whole experience or just a part? Which parts are you most interested in? Do you want to address one target group or more? Is the high-level structure clear? Do you need to separate landing pages? Do you only want to identify the right structure or do you also want to test the storyline? And so on. Also think about who you want or need to involve. Is it just for within the project team, or are you planning to involve potential users or other stakeholders?

3. Prepare wireframes: Sketch rough versions of the different screens of the interface on paper, on whiteboards, or in a special wireframing app. Don’t use color or specific fonts. Leave out aesthetics as much as possible. Use placeholder content.

Step-by-step guide USE/RESEARCH

1. Present the wireframes to your audience: Establish the context in which the presented wireframes will be used in the future application. Then introduce the wireframes, explain visual conventions, and present key elements.

2. Solicit feedback: Discuss with the team or a selected audience.

3. Document as you go along: Add annotations to capture changes and new ideas about the behaviors of interface elements. You might also add details about the content or the context in which the system might be used.

1. Wireframes help the design team to understand and explore how the different parts of software work together. They connect the conceptual structure, functions, or information architecture to the visual design.

   

Step-by-step guide PREPARATION

In this example, we will assume the service ad is to be a poster. Other media can be developed in a similar way.

1. Choose an audience: Who is the target audience for this advertisement? Choose a persona, a specific user type, or a key stakeholder and familiarize yourself with the audience.

2. Briefly review scope and clarify prototyping questions: Briefly reflect. What is your scope? What do you want to learn? Do you want to test the concept or just a part? Which part are you most interested in? Also think about the context: in which step of the customer journey will the advertisement play a role?

3. Brainstorm potential content: Do a brief brainstorming on ideas for emotional (“sizzle”) and factual (“steak”) content as input for the poster. What do you want to communicate in the advertisement? What could be suitable emotional hooks or narratives? What are the facts?

4. Sketch out the advertisement: On flipchart paper, individually create multiple quick sketches to advertise your service. Remember, ads must be quick and easy to understand, so use images and very few words, and choose them carefully. Most people will look at advertisement posters for no more than a few seconds. It is therefore key to focus on the core messages. Select the ones you want to take forward and test with an audience.

Step-by-step guide USE/RESEARCH

1. Test the advertisement: Show your advertisements to people who do not yet know your project and collect their feedback: What do they think the advertisement is for? What are the hard facts they have learned about the product? What are the emotional aspects? Would they want to learn more? Would they want to buy?

2. Keep a list of bugs, insights, and ideas, and review issues: Make sure to record your observations over the whole test and create a list of the issues that you discover. After each testing session, discuss what worked, what didn’t work, what you would like to change or try next. Prioritize.

3. Revise your advertisements (optional): Are there any changes you can or should make right now? Remember that changes to an advertisement poster can be made very easily and quickly. Do them now.

4. Decide on the next steps and iterate: Check off what you just tested and quickly decide what to do next. Then go again.

5. Document: Document and finalize your work. Use photos or videos of your advertisement and its variations as well as key interactions to document the latest version(s). Briefly reflect on your documentation and identify the critical issues, problems, or opportunity areas that need to be addressed in the next steps in the design process.

6. Present (optional): Using a storytelling approach, present your last iteration and key learnings to other stakeholders and gather feedback. It is often useful to also capture the presentation and the final feedback rounds on video and add them to your documentation.

Method notes

• Use advertisement-specific ideation cards: If there are no ad specialists in the team, consider using specific ideation cards like Mario Pricken’s Creative Sessions cards.²⁸ Those card sets are based on a surprisingly manageable number of creativity patterns that emerged through an in-depth analysis of a broad range of successful advertisements. These patterns can be used in your ideation and significantly enhance the quality of the resulting advertisements.²⁹

• Act out the advertisement: Play with the format. Also use theatrical techniques like investigative rehearsal to improvise and quickly act out a TV ad. Simulate a quick sales pitch in the shop.

• Consider your brand: When discussing the scope of the prototyping session, be aware that advertisements always are very much interlinked with your brand. If you have to work with an existing brand, you can choose to follow the given corporate identity, or you can explicitly go beyond or even ignore it altogether. This allows you to explore the mutual influence of your brand on your service or product and helps you assess a potentially necessary brand stretch. “Will people buy this?” is quite different to “Will people buy this from (insert your startup/multinational/nonprofit organization/public sector organization/…)?”

1. Service advertisement posters are a fast and engaging way to quickly explore, clarify, and test your value proposition.

   

Step-by-step guide PREPARATION

1. Review scope and prototyping questions: Review the scope and the prototyping questions for this activity. What do you want to learn? Do you want to test the whole system or just a part? How detailed do you need or want to get?

2. Split into groups: Split the participants into teams of 2–3 people. Each team chooses a new service concept to explore using Business Origami.

3. Set up workspace and materials: Each team gets its own set of Business Origami materials and a whiteboard. For convenience, the whiteboard can also be replaced by laminated plotter paper or static-cling dry erase sheets.

4. Briefing: Brief the participants on what service system or which part of a given service system they need to model.

5. Create the key elements: Ask the teams to create, cut out, fold, and label the key elements of their service system using the paper. Who are the important people or groups of people? Which channels or communication tools/devices do they use? What locations are important?

Step-by-step guide USE/RESEARCH

1. Create a first draft of the service system: Ask participants to place key elements onto the map. Add the prepared elements for important people or organizations, channels or communication tools, and important locations.

   Then, connect them. Reflect on relationships, value exchanges, (inter)actions, or basic material/money/information flows. Add those connections as arrows between the respective elements. Make sure to label the arrows as you draw them.

   If necessary, group elements using boxes or circles. Again, do not forget to label each group.

2. Improve: Is the model complete? Ask the teams to add missing elements and update the relationships and/or groupings if necessary.

3. Keep a bug list/idea sheet: Remind the teams to keep a bug list and an idea sheet to note their insights and ideas as they explore the service system.

4. Feedback: Do a short presentation round. The groups get 2 minutes each to present their work in progress. After each presentation, they receive feedback from the other groups. Use red/green feedback.³² Make sure the teams capture the feedback on their bug lists/idea sheets. Give the groups some time after the presentations to consolidate their models.

5. Simulate the service system over time: Service systems are dynamic. Ask the teams to choose a meaningful time frame and walk the system through this system journey. Who or what has to move at each step in the journey? How stable are the relationships? Do they have to change over time? What are the critical moments in this service system? Does everything fit together?

6. Document: Ask the teams to finalize and document their models. Ask them to use annotated photo storyboards, stop motion video, or video “fly-throughs” to document.

7. Present: Let the teams present their models. Remind them that it is not about the static system, but how the different elements play out over time – the journey of the service system. Ask them to use a storytelling approach to talk the group through their models. Optionally, you can also capture the presentations and the final feedback rounds on video.

8. Reflect: In the plenary, give some more time to reflect. Let the whole group identify elements or relationships within any of the models that should be worked on in the next steps. Ask the participants to add potential next steps on sticky notes (e.g., doing further research, prototyping, testing of specific elements, etc.).

Method notes

• Doing, not talking: Watch out for talking in the groups – the method can quickly trigger deep discussions. Instead of just talking, encourage the teams to simulate their talking points using the models on the table.

1. Business Origami first looks at the whole system, taking a holistic approach. Like with many other service design tools, the critical deliverable is not the model itself but the experience of modeling the service system in the team.

   

2. The setup of the workspace is not predefined and follows the structure of the service system. The clear set of preprepared elements is helpful if participants are new to the method.

   

3. Paper cutouts are the playing figures in Business Origami. There are prepared elements for stakeholders, things, channels, places, and more.

   

Step-by-step guide PREPARATION

The Business Model Canvas is a very flexible tool, and there is not one prescriptive way to use it. However, as a start, following these simple steps might help:

1. Review scope and clarify prototyping questions: Briefly reflect. What is your scope? What do you want to learn from this prototyping activity? Do you want to test the whole experience or just a part? Which parts are you most interested in?

2. Who to invite: Invite the right people to work beside your core team for the exercise (this might include people who know the background, people with no preconceptions, experts, representatives of the implementation team, people who will deliver the service, users, controllers, management, etc.).

3. Prepare the Business Model Canvas template (and other service design tools you already have): If you can’t print a large one on paper, simply sketch the template on a large sheet of paper. It helps if you have personas, stakeholder maps, customer journeys, and prototypes at hand as well.

Step-by-step guide USE/RESEARCH

1. Fill in the upper seven boxes: If available, use information from other service design tools to fill in the blocks about the value proposition, customers (customer segments, channels, customer relationships), and infrastructure (key processes, key resources, key partners). See the image on the previous page for a basic mapping of key service design tools onto those blocks.³⁴

   1. Using the Business Model Canvas, you can quickly sketch out the business model of existing services or products, whether physical or digital, or prototype the business model of new concepts.

      

   2. Using information from other service design tools helps fill in many of the blocks in the Business Model Canvas – or an existing Business Model Canvas can kick-start many service design tools. The discussion of the cost and revenue streams that follows is an important milestone and can change the direction of a concept considerably.

      

2. Fill in the lower two boxes: Go through the infrastructure blocks to identify cost drivers and go through the customer blocks to find potential revenue streams. Once you have both cost and revenue structures, put numbers to them and estimate costs and revenues.

3. Create alternatives, iterate, and refine: Search for missing information and try to fill these gaps. Prototype and test if your business model is sustainable. Then start creating alternative business models and test potential options you have for the infrastructure blocks (change partners, processes, or resources) as well as for revenue streams (other customer segments, channels, customer relationships). Compare different models, iterate, and combine and refine them.

Method notes

• Use of sticky notes: We recommend using a large paper template, sticky notes, and thick felt tip pens. Using sticky notes helps you to focus on the most important aspects and minimizes the risk of getting lost in detail. Rule of thumb: if you cannot fit any more sticky notes into one of the boxes, your discussion is already too detailed.

• Working with multiple customer segments: If you are delivering different value propositions to different customer segments within one canvas (e.g., a hotel booking platform has at least two core customer segments, the hotel guests and the hotels themselves), try to use one color of sticky notes for each customer segment and their respective value propositions and a different color for the other customer segment.

• Compare to competition, market, and trends: The business model also needs to be analyzed and challenged with respect to competition, market forces, industry forces, and future trends. For example, it can be very useful to also fill in a couple of canvases for your main competitors and compare your strengths and weaknesses.

Step-by-step guide PREPARATION

1. Review scope and clarify prototyping questions: What do you want to learn or explore? Look at your starting point and consider if and how you will bring previous knowledge into the room (for example, as a research wall, via artifacts for inspiration, or as key insights).

2. Decide who to invite: Invite the right people to work beside your core team for the exercise (this might include people who know the background, people with no preconceptions, experts, representatives of the implementation team, people who will deliver the service, users, management, etc.).

   If you chose to do sketching with specific materials, code, or hardware, make sure you have the required skillsets in the team. Balance your teams so everybody can contribute during the sketching process. For example, when sketching in code, not everybody needs to be a coder; some can contribute by creating graphical elements, writing copy, or working out scenarios and information structures.

3. Decide on quantity or deeper investigation: Decide if you will be aiming for quantity, or for a more considered investigation or “deep dive” into particular themes or ideas. This decision will depend on where you are in your development process and will affect, for example, how much time you allow for the task.

4. Prepare sketching tools: Set up and prepare your sketching tools and your working environment. When working with pen and paper, just put them on a table. When working with code or hardware, it can be highly beneficial to take a bit of time to carefully select and prepare only a limited set of tools and platforms, optimizing for speed of sketching.

5. Create sketches: After you have given the group a design challenge (e.g., a “How might we …?” question), ask them to sketch varied concepts that address the challenge. If you are aiming for quantity, you might ask participants to resist the urge to discuss the ideas, but instead to concentrate on producing many sketches. (If it fits the sketching method, they might even work in silence, placing finished sketches in a visible place for others to see and build upon.) If you are looking for more depth, you might promote discussion and co-creation of the sketches as they are developed.

1. Sketches using pen and paper provide a quick and low-fidelity visualization of an initial idea or concept.

   

2. Open source prototyping platforms like Arduino allow you to sketch in hardware, creating first working prototypes of interactive devices.

   

3. Early exploratory sketches often are for yourself only, and if not you will be able to explain them anyway. Therefore, go for inspiration, not perfection. Learn from children, who are experts in doing just that.

   

Step-by-step guide USE/RESEARCH

1. Present and elicit feedback: Present sketches either to each other within the design team or to an external audience to receive feedback and ignite discussions. During these sessions, you can directly work on existing sketches (e.g., by adding annotations or changing them on the spot) or easily add new ones with the new ideas already included. One alternative method is for the sketchers to present their work without explanation, and ask the people viewing the sketch to describe what they see and what it might be useful for.

2. Keep a list of bugs, insights, and ideas: After each session take a few moments to reflect on what you have learned, and what you would like to change or try next. Briefly discuss the issues you discovered and prioritize them.

3. Revise your sketches and iterate (optional): Are there any changes you can or should make right now? Do them quickly, then iterate from step 1.

4. Document: Document and finalize your work. Use photos or videos of your sketches as well as key interactions to document the latest version from your sketching session. Briefly reflect on your documentation and identify critical issues as well as problem or opportunity areas that need to be addressed in the next steps in the design process.

1. With the right prototyping platform, sketching in code lets you explore working prototypes early.

   

2. Bodystorming is a very efficient lo-fi way to sketch (inter)actions using re-enactment – or “sketching with our bodies.”

   

Step-by-step guide PREPARATION

1. Review scope and clarify prototyping questions: Briefly reflect. What is your scope? What do you want to learn from this prototyping activity? Also think about who you want or need to involve. Is it just for within the project team, or are you planning to involve potential users or other stakeholders?

2. Collect inspiration: Start to collect inspiration and raw material from all the sources you have available. This might include physically going through relevant newspapers or magazines, digging through online repositories like stock photo libraries or photo or video sharing sites, selecting materials from your own media library, or – last but not least – quickly creating new material yourself by going out and taking photo and video footage.

3. Organize and refine: Organize that material and set up a first collage. Then, fill in gaps and reshuffle the deck until you are happy with the mood board. Your mood board can be a physical one where you print out everything and glue it on, or it can be a digital mood board, which is a more practical solution if you are working with video or interactive media.

Step-by-step guide USE/RESEARCH

1. Present and collect feedback: Present your mood boards either to each other within the design team or to an external audience to receive feedback and ignite discussions.

2. Annotate and revise: During these presentation sessions, you can work on existing boards by adding annotations or adding, reshuffling, or removing media, or even create completely new boards from a pool of data. Then iterate.

1. Mood boards are collages of existing media to communicate an intended design direction.

   

Step-by-step guide PREPARATION

1. Review scope and clarify prototyping questions: What do you want to learn or explore? Look at your starting point and consider if and how you will bring previous knowledge into the room (for example, as a research wall or as key insights). Do you want to test the whole or just a part of the interface? What are the tasks that you expect the chosen user to do? How detailed do you need or want to get? Make a list of the tasks you want to test for later.

2. Identify participants: Based on your research question, define criteria for selecting suitable test subjects. Use sampling techniques to select your test users and consider including internal experts or external agencies for recruitment.

3. Prepare scenarios and create interface elements: Use digital service or investigative rehearsal sessions to generate a set of key scenarios. Then use suitable techniques to prepare the key elements the users will interact with (e.g., leveraging cardboard prototyping, paper prototyping, wireframing, or sketching in code).

4. Rig ’em, assign roles, and practice: Rig all the relevant parts of the service or system to allow the “wizards” to control the interaction and appropriately react to the actions of the user. Then split your team to take on the roles of operators (“wizards”) and observers. Allow the wizards to practice until you achieve the intended experience.

5. Set up the test space: Set up your test space. You might want to establish a video link or a mirror wall so the wizard is hidden from the user while still being able to observe the user.

Step-by-step guide USE/RESEARCH

1. Test the prototype: Conduct your test. Introduce the project and the context of your prototype and ask the user to perform a certain task from a selected scenario. As the user starts to use the prototype, the operator simulates the operation of backstage processes, devices, or the environment by manipulating the objects and environment behind the scenes.

2. Keep a list of bugs, insights, and ideas, and review issues: During the test the observers will record their observations and create a list of the issues that they discover. After each testing session take a few moments to reflect on what worked, what didn’t work, what you would like to change or try next. Briefly discuss the issues you discovered and prioritize them.

3. Revise and iterate: Check off the task or scenario that has just been simulated and quickly decide which one you want to try next. Revise the reactions of the “wizard” and consider changes to the respective elements if necessary. Then go again.

   At the end of your testing session, reveal the wizards and do a final debrief with the users.

1. In Wizard of Oz techniques, the responses from people, devices, apps, or the context/environment are manually created by invisible operators (“wizards”) behind the scenes. Think of the operator as an invisible puppeteer controlling those objects and service elements.