Drafting and Structure

Example and Analogy Planner

Design accurate examples and useful analogies while documenting the intended teaching point, source facts, audience assumptions, and limits of every comparison.

Free editable Markdown · Writers, educators, and technical communicators · Updated July 30, 2026

Download Markdown

Accessible HTML preview

Blank template

The downloaded file contains the same fields in editable Markdown.

Teaching goal

Concept: [What needs explanation?]
Audience and prior knowledge: [Who is reading?]
Current misconception: [What may they assume incorrectly?]
Desired understanding: [One observable outcome]
Why an example or analogy helps: [Reason]
Risk if misunderstood: [Consequence]

Comparison design

Type: [Concrete example / Analogy / Counterexample]
Source scenario: [Familiar case or fictional setup]
Target concept: [Actual subject]
Accurate mapping: [Element A corresponds to element B because…]
Second mapping: [Another valid relationship]
Where it breaks: [Difference the reader must know]
Irrelevant detail to remove: [Potential distraction]
Factual sources: [Current supporting references]

Draft and review

Draft setup: [Short scenario]
Teaching sentence: [State the principle directly]
Limit statement: [Where the comparison no longer applies]
Transfer question: [New case the reader should solve]

The example is clearly fictional if it is invented.
Names and details cannot be mistaken for a reported case.
The comparison does not substitute for evidence.
A qualified reviewer checked consequential facts.

Test record

Reviewer or participant: [Non-identifying code or role]
Unaided interpretation: [What they believed]
Incorrect inference: [What the example accidentally suggested]
Transfer result: [Could they apply the principle?]
Revision: [Specific change]
Decision: [Use / Revise / Replace / Remove]

How to use this template

Define the reader, prior knowledge, misconception, and one learning outcome the example must support.
Choose a concrete example or familiar analogy and document the factual concept it represents.
Map accurate correspondences, irrelevant details, failure points, and any cultural or accessibility concerns.
Draft the explanation with a clear fictional label or comparison limit and send it for editorial and subject review.
Test whether a reader can explain and transfer the principle, then revise or replace weak comparisons.

Start with the learning obstacle

Write what the reader currently misunderstands and what they should be able to explain or do afterward. An example shows a concept operating in a concrete case; an analogy maps a familiar relationship onto an unfamiliar one. Choose intentionally. A realistic example may be better for rules and edge cases, while an analogy can introduce an invisible process. Do not add a colorful story merely to make a section longer. Every detail creates something the reader may remember, so remove decorative facts that compete with the teaching point or resemble a real person unnecessarily.

Map similarities and limits explicitly

For an analogy, list the source system, target concept, and exact relationship being compared. Then list where the mapping fails. Calling data “oil,” memory “a filing cabinet,” or security “a lock” can imply scarcity, physical location, or protection properties that do not exist. Decide whether the limitation belongs immediately after the analogy or later in the explanation. For examples, check names, numbers, sequence, exceptions, and whether the scenario accidentally implies a guaranteed outcome. Use clearly fictional entities when a real case is unnecessary, and avoid composite stories that readers could mistake for reported evidence.

Test transfer, not entertainment

Ask a reviewer from the intended audience to explain the concept in their own words and apply it to a new case. If they repeat the story but cannot identify the principle, the example is memorable but ineffective. Ask what they think the comparison promises and where it stops. Subject experts should verify technical boundaries; editors should check cognitive load, cultural assumptions, accessibility, and tone. Revise or remove an analogy when its corrections take more space than the concept itself. Preserve the factual explanation beside it so readers are not forced to infer meaning from imagery alone.

See the fields in context

Fictional example: version history as a trail

This invented lesson explains document history without describing a real software product.

Learning goal: Explain that saved revisions allow earlier states to be inspected.
Analogy: A marked walking trail helps a traveler retrace prior points.
Valid mapping: Both preserve an ordered path through earlier positions.
Limit: A software history may record authors and exact changes; a physical trail does not automatically preserve that information.
Transfer test: The reader explains why deleting the revision record is not equivalent to stepping forward on the same trail.

Frequently asked questions

Must every analogy include a limit statement?

Document the limit during planning. Publish it whenever omission could create a meaningful false inference. Even when the limit stays implicit, reviewers should confirm the comparison does not carry a dangerous or central misconception.

Can a fictional example use realistic numbers?

Yes, when the figures are plausible, internally consistent, and clearly illustrative. Do not imply they are measured results, and avoid realistic details that could identify or defame an actual person or organization.

What makes a counterexample useful?

A counterexample shows where a rule does not apply or exposes an overbroad interpretation. It should isolate the boundary cleanly and explain why the case differs instead of surprising the reader without a lesson.

Should an analogy be localized literally?

Not automatically. Familiarity, connotation, and validity may change across languages and regions. A localization reviewer should preserve the teaching relationship, replace unsuitable imagery when necessary, and recheck the comparison’s limits.