Prompt Workshop
Why it is written this way
Tap a block to see its paragraph
You are an expert speaker skilled at breaking down complex technology into plain, accessible language. Your philosophy is that if the audience fails to understand, it is the speaker's fault.
I need to explain {{concept to explain}} to a {{target listener}}. They have no technical background in this domain and primarily care about one practical question: "How does this affect my work?"
Please produce an explanation formatted for {{explanation length}}. Provide 3 distinct options, each using a different analogy. Underneath each option, add a single-line note describing the ideal setting or context for using it.
Structure each option in this exact sequence: a one-sentence definition → the analogy → one concrete example of what this concept actually makes possible. After the three options, include 3 follow-up questions the {{target listener}} is likely to ask, along with brief, clear answers.
Do not use tech acronyms or specialized jargon; if a technical term is strictly necessary, mention it only once and immediately explain it in parentheses. Choose everyday, relatable analogies, and append a one-line disclaimer for where each analogy breaks down or differs from technical reality.
- Role Who answers ×1
- Material What the AI needs to know ×1
- Work What to do, and how ×1
- Output What comes back, in what shape ×2
When you simply ask AI to "explain a technical term simply," the output often circles back to more technical jargon—such as "An API is an interface that allows a server and a client to exchange data." Because "simple" has no objective baseline for an AI, human guidance must define precisely who the audience is and how plain the language needs to be.
Read the full explanation · 3 paragraphs
Setting the Role to a speaker who believes "if the audience fails to understand, it is the speaker's fault" radically lowers the barrier of entry for vocabulary. This single constraint noticeably strips out elitist tech phrasing compared to standard explanations.
Defining the listener provides the raw material for context-appropriate analogies. A sales team connects best with contracts and quotes; a middle schooler resonates with gaming or school life. Pre-empting the "How does this affect my work?" angle ensures the output becomes a practical business justification rather than a dry academic definition. Specifying length is equally critical—an elevator pitch requires an entirely different structure than content meant for a slide.
Analogies are rarely one-size-fits-all, so generating three distinct options to select and refine works far better than asking for a single definitive answer. Analogies are subjective; if the first misses the mark, the second often fits, allowing you to iterate in that specific direction. The Constraint requiring a note on "where the analogy breaks down" acts as an essential safeguard. Every metaphor has limitations, and failing to point them out risks sending non-technical stakeholders into subsequent meetings with flawed mental models. Adding three likely follow-up questions prepares you in advance for impromptu Q&A.
Compared with a bad example
Explain what an API is in simple terms so non-developers can understand.
Almost always defaults to the overused restaurant waiter analogy while retaining words like "client," "request," and "response." Because the specific audience is undefined, it skips practical relevance, and the lack of a specified length makes it awkward to use directly in a real meeting.
Variations
Simplifying Further When Still Too Complex
Refines the existing output instead of starting from scratch. Generating a terminology swap list helps you avoid those same buzzwords in future communications.
Show prompt
The second option from your previous response was the closest, but it is still too technical for a {{target listener}}. Please identify the remaining difficult words one by one, replace them with simpler alternatives, and rewrite the explanation keeping the same analogy. Add a reference list at the end formatted as "Original Term → Simplified Term".
Verifying Comprehension
Prevents the common pitfall where people simply nod along without understanding. Especially useful during training, onboarding, or handover sessions.
Show prompt
Please draft 5 questions I can ask to verify whether the {{target listener}} genuinely understood {{concept to explain}}. These should not look like a quiz or exam; frame them as natural conversational check-ins. For each question, add a one-line note explaining what response would indicate they have not grasped the concept yet.
Last updated 2026-09-02 · Found a mistake? Let us know