Roleplay Testing

Purpose

Roleplay Testing brings a concept to life by having team members physically act out the experience from different perspectives. It reveals friction, emotional reactions, and logic gaps that static prototypes miss, making it especially valuable for service design and complex multi-stakeholder interactions.

At a glance

• Group size: 3–8
• Duration: 35 minutes
• Difficulty: Moderate
• Facilitation style: Directed improv, facilitator as director
• Setting: Open floor space; minimal props

How to run

1. Set the scenario (5 min): Describe the situation, the roles needed (user, service provider, system/backend), and the task the user is trying to accomplish.
2. Assign roles (2 min): One person plays the user, others play touchpoints, employees, or even abstract concepts like "the app" or "the waiting room."
3. Run the scene (15 min): The user walks through the experience step by step. Other players respond in character. The facilitator can pause, rewind, or ask "What are you feeling right now?"
4. Debrief (13 min): All players share their experience. What felt awkward? Where did the flow break? What was missing? Capture insights on sticky notes.

Materials needed

• Scenario script or storyboard
• Name tags or role cards
• Sticky notes and markers for debrief
• Optional: simple props (phone, clipboard, chair as a counter)

Pitfalls & common mistakes

• Self-consciousness: Participants may feel silly. Warm up with a low-stakes improv exercise first.
• Over-scripting: If every line is scripted, you lose the improvised reactions that reveal real issues.
• Ignoring the "system" role: Someone should play the backend — what happens behind the scenes matters.
• No observer: At least one person should watch and take notes, not act.

Inclusion & accessibility

• Offer non-acting roles (narrator, note-taker) for participants uncomfortable with improv.
• Use seated roleplay for participants with mobility constraints.
• Allow written responses instead of spoken ones if preferred.

Variations

• Reverse roleplay: Designers play the user; actual users play the service provider.
• Dark scenario: Intentionally roleplay the worst-case experience to stress-test the design.
• Forum theatre: Audience members can shout "Stop!" and take over a role to try a different approach.

When NOT to use this

• When the team is too small (fewer than 3 people) to cover essential roles.
• When the concept is too abstract to act out — use storyboarding instead.
• When cultural norms make public acting uncomfortable and no warm-up can bridge the gap.

Source & further reading

• Stickdorn, Hormess, Lawrence & Schneider — *This Is Service Design Doing* (O’Reilly, 2018)
• Boal, Augusto — *Theatre of the Oppressed* (1974) — for forum theatre roots
• d.school, Stanford — "Prototype for Empathy" method card