01 / UNDERSTAND
What is role play in service design?
Role play is a service prototyping method in which people enact a bounded encounter using roles, simple props and a scenario. It makes a proposed interaction tangible enough to examine how information, decisions and responsibilities pass between people. Acting out a service reveals questions to investigate; a team's performance does not establish how customers will behave.
Why use Role Play?
A process diagram can hide the moment someone must explain a delay or ask for missing information. Enacting that moment makes the wording, sequence and available choices concrete. It can reveal where a proposal relies on knowledge that one actor would not have, or on permission they cannot grant. The useful output is a revised interaction and a list of operating assumptions to check.
When to use it
USE IT WHEN
A service idea depends on a conversation, handoff or physical encounter.
You want to compare alternative responses to one service situation.
A blueprint leaves an important interaction too abstract to discuss.
When to choose another method
Use User Interviews when you need evidence about people's actual experiences before proposing an encounter.
Use Paper Prototyping for a question mainly about an interface flow.
Use Service Blueprint to examine the wider delivery dependencies before or after the scene.
What you’ll need
Choose one encounter with a clear start and end. Bring relevant research, proposed service rules and simple props such as a booking message or queue sign. Agree who acts, who observes and what each role knows. Explain that anyone can pause or decline a role. Avoid invented accents, stereotypes or asking people to imitate distress. A verbal walkthrough is an alternative when acting would be uncomfortable.
What a role play needs
Keep the elements that help answer your question and support a decision.
The situation, goal, starting condition and stopping point.
Each actor's knowledge, authority and constraints.
Objects or messages required for the interaction.
The commitments and limits the actors must respect.
Actions, handoffs, missing information and improvised decisions.
A specific change and the evidence still needed.
02 / PUT IT INTO PRACTICE
How to run a service role play
Keep evidence and assumptions distinct. Revisit your work when new information changes your understanding.
01
Bound the encounter
Choose the uncertainty and the beginning and ending of the scene.
A learner arrives for a class, but reception cannot find the booking. Stop when there is an agreed next step.
02
Brief the roles separately
Give each actor the information and authority they would actually have.
The learner has a confirmation message. Reception can check bookings but cannot create extra capacity.
03
Prepare only necessary props
Use enough detail to support the question without building the whole setting.
Provide a booking message, class list and a simple escalation rule.
04
Enact and observe
Let the encounter unfold. Record actions and any invented information or permissions.
Notice whether reception promises a place before checking availability.
05
Debrief the sequence
Ask what each person knew, needed and assumed at the difficult moment.
Separate an unclear reassurance from the missing rule for handling an unlisted booking.
06
Revise one condition
Repeat with a specific change and record what the exercise still cannot establish.
Try a pending check with a named staff owner, then verify whether the promised response time is feasible.
Example: an unlisted course booking
Illustrative scenario, not research findings. A learner arrives with a confirmation email, but the reception list has no matching booking. In the proposed scene, reception tells the learner to wait while someone checks. No person owns the check, and the learner does not know whether they will be able to join.
The team tries a revised encounter: reception explains the uncertainty, names the colleague checking it and agrees where the learner will receive an update. The revised conversation is more explicit, but a smooth performance cannot confirm that staff have enough time or authority to deliver it. The next action is to check the escalation arrangement with the people operating the service.
03 / BELOW THE SURFACE
Below the surface: a smooth scene can hide a weak service
A cooperative actor can quietly repair a weak service. They may forgive a vague promise, share information without being asked or assume that another team is available.
01 / COMMITMENT
What was promised?
Record the wording and who made the commitment.
02 / AUTHORITY
What made that promise possible?
Check information, capacity and permission.
03 / REALITY
What still needs verification?
Assign a check with people operating or using the service.
Track where the scene borrows permission. At each commitment, ask what gave the actor the authority and information to make it. If those conditions were invented during the performance, record an unresolved dependency.
Repeat the scene with one plausible constraint, such as the escalation colleague being unavailable. Compare what changes in the interaction rather than rating which performance feels better. This is an editorial way to interrogate the example, not a validated measure of service quality. Follow the rehearsal with appropriate research involving people with relevant experience.
Role Play working canvas
Use page one to define the scenario, brief the roles separately and record service rules. Use page two to trace the encounter, identify improvised commitments and choose a revision. The two page PDF contains 12 editable fields. Save a working copy in a PDF reader that supports forms.
Practical tips
Keep role information separate when the service depends on an information gap.
Record the exact commitment an actor makes.
Preserve the first scenario so revisions can be compared.
Common mistakes
Writing a script that guarantees the desired ending.
Treating an actor's emotions as evidence about customers.
Improvising authority or capacity that the real service does not have.
What you’ll get
A revised encounter, explicit commitments and a record of the delivery conditions that need checking. Carry the dependencies into the service blueprint and assign the next investigation to an owner.