Part 2 mapped where role play fits. Part 3 is the craft manual: how to design a scenario that teaches. This chapter covers the skeleton — the path from a line in your syllabus to a runnable scenario — and the three chapters after it cover the mechanics that make it hard (resistance), fair (rubrics), and durable (debrief).
The starting principle is the one every teaching guide states and most scenario authors skip: tie the role play to a learning objective. NIU’s guide says it flatly — role plays should match learning objectives so students see relevance. In practice, this means designing backwards, the same way you would design any assessment.
The four-step chain
Step 1: Objective. Start with the sentence from your course outcomes. “Students will be able to conduct a client intake interview.” “Students will be able to defend a design decision under questioning.”
Step 2: Observable behavior. Objectives are abstractions; conversations are behaviors. Translate: what would you see and hear a competent student do? “Opens with an open-ended question and lets the client finish.” “States the trade-off before defending the choice.” “Asks the parent what they’ve observed at home before presenting the school’s view.” If you cannot write the behavior, you cannot score it, and the scenario will drift into vibes. This step is also where the rubric is born — the behaviors you list here become the criteria in Chapter 12, which is why the chain matters more than any individual link.
Step 3: Forcing situation. Now design the situation that makes the behavior necessary, not merely possible. This is the load-bearing design move. A cooperative client lets a student skip the open-ended question and still succeed; a client who answers closed questions with one word and opens up only to open questions forces the skill. A parent who arrives calm never tests de-escalation. The question to ask of every scenario draft: can a student pass this without doing the thing I’m teaching? If yes, redesign until no.
Step 4: Role card. Write the persona specification. The next section is the template.
The complete role card
Duke Kunshan’s guide recommends role descriptions with “motivations and constraints,” plus dossiers carrying different levels of information to stimulate interaction. Expanded into a full working template, a role card for an AI counterpart has six blocks:
- Identity and situation. Who I am, in first person. Two or three sentences of demographic and situational grounding: enough to be specific, not a biography.
- What I want. The persona’s actual goal in this conversation, which is rarely what they say first. The parent wants reassurance their child isn’t being written off; what they say is that the teacher is unfair.
- Constraints. What I cannot do or agree to, and why. The client cannot afford the recommended option. The witness will not volunteer what she wasn’t asked.
- Behavior. Opening emotional state, speech style, what I volunteer versus what I only reveal to good questioning, and my resistance pattern (Chapter 11 supplies the machinery).
- Hidden information. The asymmetry block: things the student doesn’t know and must discover — or will pay for not discovering. This is the secret-dossier mechanic that makes negotiations negotiate.
- What gets through to me. The breakthrough conditions: the specific student behaviors that shift my trust, soften my resistance, or earn my agreement. These mirror step 2’s observable behaviors, on purpose.
A role card with blocks 1–3 alone produces a character. Blocks 4–6 produce a lesson. The difference between the two is the difference between an entertaining session and a teaching one.
Source material: incidents, not inventions
Where does the content come from? The strong version of the answer: from real incidents, never from brainstorms. Sales teams learned this building practice bots from actual call recordings — invented objections have a tell; sampled ones land. The education equivalents are everywhere:
- The office-hours conversation that went sideways last term.
- The practicum recordings and supervision notes your program already collects.
- The parent complaint that reached the dean.
- The three questions every thesis defense committee actually asks.
- The case study you already teach — one conversion pass turns a case about a person into a person (Chapter 6’s exercise).
Real incidents carry the texture invention misses: the non-sequitur, the half-legitimate grievance, the detail that doesn’t resolve neatly. They also solve the blank-page problem: you are not inventing a persona, you are transcribing one you’ve met. Anonymize properly — change names, identifying details, and any element that would let a cohort recognize a classmate or a real family — and keep a growing incident file; every awkward real conversation in your program is future curriculum.
One craft warning as you write: resist complexity. The best first scenarios isolate one moment — the opening two minutes of the intake, the single hard question — not a 40-minute odyssey. Short scenarios get repeated; repetition is the point. You can chain moments later, once each one lands.
On Tough Tongue: the six-block role card maps directly onto a scenario’s configuration — you describe the persona, behavior, and breakthrough conditions in natural language, attach documents for hidden context, and the builder compiles it into a runnable agent. The practical workflow for faculty: draft the role card in a document with colleagues first, then paste; the design thinking is the work, the platform is the compiler.
Exercise
Write one complete role card, all six blocks, from a real incident in your teaching or supervision history. Choose the incident you still think about — the one where a student (or you) got it wrong in an instructive way. Time-box it to 25 minutes. Then apply the step 3 test: could a student get through this conversation without performing the observable behavior you care about? Fix the card until the answer is no. Bring this card to the next chapter, where we make the persona push back.