Explain Any Complex Topic as a Conversation Between Two Unexpected Characters
Why this prompt matters
Traditional explanations rely on the reader already caring about the topic enough to push through dry technical language. Most people do not -- they skim, nod, and forget within a day. Cognitive research on the testing effect and narrative memory shows that information embedded in a story with tension and character voice is retained significantly longer than the same information in expository form. A five-minute dialogue that someone actually remembers a month later beats a comprehensive slide deck nobody reopens.
What we use it for
You are a corporate trainer who needs new hires to understand a technical concept (e.g., zero-trust security, API rate limiting, why cloud costs scale non-linearly) before their first week ends, but the official documentation puts people to sleep and a straight lecture format gets zero retention in a 15-minute onboarding slot.
Prompt
Act as a skilled scriptwriter and subject-matter educator who specializes in making technical topics memorable through character-driven dialogue. **Context:** Topic to explain: [YOUR TOPIC -- e.g., "how blockchain consensus mechanisms work", "the difference between TCP and UDP", "why compound interest matters for retirement savings"] Audience: [WHO WILL READ/HEAR THIS -- e.g., "high school students", "new hires with no technical background", "my parents"] Two characters having the conversation: [CHARACTER A] and [CHARACTER B] -- pick two personas who would NOT normally discuss this topic and whose contrast creates natural tension or humor (e.g., "a medieval blacksmith and a modern-day barista," "a suspicious grandmother and her tech-obsessed grandson," "a pirate captain and a corporate auditor") Length target: [E.G., "300 words", "a 2-minute read", "5 exchanges each"] **Task:** Write a dialogue where [CHARACTER A] and [CHARACTER B] discuss and ultimately clarify [YOUR TOPIC], using their established personalities, vocabulary, and worldview to explain the concept through analogy and disagreement -- not through one character lecturing the other. **Constraints:** - Do NOT let one character become a passive student who just says "oh I see" -- both characters should push back, misunderstand initially, and arrive at understanding through the conversation, not through exposition - Every technical claim in the dialogue must be accurate -- humor and character voice cannot come at the cost of correctness - Use each character's known vocabulary and worldview as the source of analogies (a blacksmith should explain things through metalworking, not through unrelated tech metaphors) - Include at least one moment where a character's initial assumption is wrong, and the correction becomes the teaching moment - End with a line that shows both characters have genuinely updated their understanding -- not a tidy moral statement **Output Format:** Produce: 1. **The Dialogue** -- formatted as a script with character names in bold followed by their lines 2. **Accuracy Check** -- a short paragraph confirming which technical claims were made and that they are correct, so the reader (or a fact-checker) can verify the science/technical content held up under the entertainment 3. **Adaptation Notes** -- 2-3 suggestions for how to adjust the character pairing or tone if this version doesn't land with the target audience
Result
Topic: Why Cloud Computing Costs Scale Non-Linearly
Characters: Magda, a medieval blacksmith who runs a forge, and Kevin, a cloud infrastructure engineer who just inherited her workshop in a time-travel mishap and is trying to explain his old job while helping her scale up production.
The Dialogue
MAGDA: You keep saying "the cloud" like it's a barn full of hammers you rent. Just buy more hammers. Why does renting cost more the busier we get?
KEVIN: Okay, it's not like hammers. It's more like... you know how you have one forge, and one apprentice pumping the bellows?
MAGDA: Aye. Works fine most days.
KEVIN: Right, but when the whole village needs horseshoes at once -- say, before a big cattle drive -- you can't just add a second apprentice instantly. You need a second forge, a second set of tongs, someone who knows how to use them, and now you're paying two apprentices even on the slow Tuesday after the cattle left.
MAGDA: So I overpay for the quiet days to be ready for the busy ones. That's just... having spare capacity. I already do that.
KEVIN: Sure, but here's the part that gets people: in the cloud, it's not just "one more forge." Some requests need a forge, some need three forges and a master smith flown in from the capital, and some need the master smith AND a specially built anvil that only exists for orders over a hundred horseshoes. The cost doesn't go up in a straight line with orders -- it jumps in steps, and sometimes the step is huge.
MAGDA: Wait -- so it's not that busy costs more than quiet. It's that SOME kinds of busy cost a LOT more than other kinds of busy?
KEVIN: Exactly. A steady stream of regular orders scales fine -- roughly one apprentice per X horseshoes. But a sudden spike, or an order that needs something exotic, breaks the simple math. That's why cloud bills don't creep up smoothly. They spike.
MAGDA: Huh. So when you told the lord's steward "just add more servers," you were basically telling him to hire more smiths without checking if we even had forges free, or if the job needed a specialist we don't have on staff.
KEVIN: ...That is uncomfortably accurate, yes.
MAGDA: Then next time, tell him what KIND of busy we're expecting before he panics about the bill.
Accuracy Check
The dialogue's core technical claim is correct: cloud computing costs are non-linear because resource provisioning happens in discrete steps (instance sizes, specialized hardware tiers, auto-scaling thresholds) rather than smooth continuous scaling. A workload that crosses a scaling threshold -- needing a larger instance type, additional specialized compute (GPUs, high-memory nodes), or cross-region redundancy -- can see costs jump disproportionately relative to the increase in traffic. Steady, predictable load scales roughly linearly with reserved capacity; spiky or specialized load does not.
Adaptation Notes
- For a younger audience, swap the blacksmith for a lemonade stand owner explaining scaling to a friend running a food truck -- same "steps not smooth lines" logic with less period vocabulary to explain.
- If the training audience already knows basic cloud terminology, cut the disguise entirely and use two engineers from different eras (a 1990s sysadmin who bought physical servers vs. a 2026 cloud architect) -- the friction becomes "why don't you just buy the hardware" instead.
- For a written onboarding doc rather than a live training session, keep the dialogue under 400 words and add a one-paragraph technical summary immediately after so readers who want the direct explanation aren't forced to extract it from the story.
Straight explanations bounce off people who have heard the jargon before and tuned out. This prompt turns any dense topic into a dialogue between two characters who would never normally discuss it — and the friction makes the concept stick.
Use Case
You are a corporate trainer who needs new hires to understand a technical concept (e.g., zero-trust security, API rate limiting, why cloud costs scale non-linearly) before their first week ends, but the official documentation puts people to sleep and a straight lecture format gets zero retention in a 15-minute onboarding slot.
Why This Matters
Traditional explanations rely on the reader already caring about the topic enough to push through dry technical language. Most people do not -- they skim, nod, and forget within a day. Cognitive research on the testing effect and narrative memory shows that information embedded in a story with tension and character voice is retained significantly longer than the same information in expository form. A five-minute dialogue that someone actually remembers a month later beats a comprehensive slide deck nobody reopens.
Example Output
Below is a realistic example: explaining why cloud computing costs scale non-linearly, told through a medieval blacksmith and a time-displaced cloud engineer.