Quiz — Chapter 32: Visual Storytelling
Target: 70%+ before moving on. Answers are hidden—commit to a choice before opening them.
Section 1 — Multiple Choice (10)
1. A diagram most clearly earns its place over prose when the reader needs to grasp:
- a) An exact throughput number
- b) An argument for adopting a design
- c) A shape—how parts connect, how a process branches, or how interactions are ordered
- d) A single linear instruction
Answer
**c.** Diagrams are for *shape*—connection, branching, temporal order, data relationships. Exact numbers belong in a table (a), arguments belong in prose (b), and a single linear step is faster as a sentence (d). This is [Chapter 9](../../part-02-building-blocks/chapter-09-visuals-and-data/index.md)'s channel-fit logic applied to diagrams. (§32.1)2. The single most damaging mistake in an architecture diagram is:
- a) Using too few colors
- b) Mixing levels of abstraction (infra + app + code in one picture)
- c) Drawing it in Mermaid instead of Lucidchart
- d) Including a legend
Answer
**b.** When a box could be a load balancer, a class, or a process, the reader can't tell what *kind* of thing anything is. The C4 discipline—pick one level, draw a set—exists precisely to prevent this. (§32.2)3. In Simon Brown's C4 model, the diagram that shows the major runnable/deployable pieces inside your system and how they communicate is the:
- a) Context diagram
- b) Container diagram
- c) Component diagram
- d) Code diagram
Answer
**b.** Container = the big moving parts inside your system (web app, API, database, worker). Context (a) is the whole system as one box plus external actors; Component (c) is inside one container; Code (d) is classes/functions. (§32.2)4. A flowchart is the right tool specifically when:
- a) You're showing how data entities relate
- b) The process has decisions and branches ("if X do this, else that")
- c) You need to show where services are deployed
- d) The steps are linear with no decisions
Answer
**b.** The branches are the whole point of a flowchart. A linear no-decision process (d) is better as a numbered list; data relationships (a) want an ER diagram; deployment (c) wants a network diagram. (§32.3)5. In a sequence diagram, the vertical axis represents:
- a) Importance
- b) Time (top to bottom)
- c) Network distance
- d) Level of abstraction
Answer
**b.** Top-to-bottom is time; that's why sequence diagrams are the best tool for ordered interactions and protocols. If order doesn't matter to your message, you probably don't need a sequence diagram. (§32.4)6. The single most valuable thing an ER diagram conveys—the thing prose states clumsily—is:
- a) The color of each table
- b) Cardinality (one-to-many, many-to-many)
- c) The physical disk layout
- d) The query performance
Answer
**b.** Cardinality is the payload: does one customer have many orders or one? An ER diagram with plain lines and no cardinality omits the very thing the reader needs. (§32.5)7. A teammate sends a clean three-box diagram, Client → API → Database, but the real system has a cache that serves stale data, a queue that backs up, and a third-party call that times out. The diagram is:
- a) Fine—simpler is always better
- b) Wrong in every box
- c) Potentially misleading: it implies "nothing surprising can fail," which is false
- d) Only a problem if it's drawn in Mermaid
Answer
**c.** Every box can be accurate while the *omission* misleads—a clean diagram looks authoritative. The fix is honesty about scope: caption the omission, or show failure modes in a second view. (§32.8)8. The chapter's main argument for Mermaid (diagrams-as-code) over a visual tool is that:
- a) It produces prettier diagrams
- b) The diagram lives in version control, diffs in a pull request, and can't silently drift out of sync
- c) It supports more diagram types than anything else
- d) It requires no learning
Answer
**b.** The decisive advantage is co-location with code and review-ability, which fights diagram rot. The trade-off is giving up pixel-perfect layout control—where draw.io or Lucidchart win. (§32.9)9. Three rules transfer across all the diagram types in this chapter. They are:
- a) Add color, add a logo, add a border
- b) One level of abstraction, label every arrow, name every box by role
- c) Use UML, be complete, match the spec exactly
- d) Make it big, make it detailed, make it symmetrical
Answer
**b.** All five types are graphs the reader must decode under time pressure; these three rules each reduce decoding cost. The type changes what nodes and edges *mean*; the craft is constant. (§32.6 "Why Does This Work?")10. A diagram's caption should ideally state:
- a) The diagram's file format
- b) Just the word "Architecture" or "Diagram"
- c) The one idea the reader should take away (Level 3 interpretation)
- d) Every box's name in a list
Answer
**c.** Like a chart caption ([Chapter 9](../../part-02-building-blocks/chapter-09-visuals-and-data/index.md)) and an assertion–evidence slide title ([Chapter 30](../chapter-30-slide-design/index.md)), the caption states the *one idea* and the diagram is the evidence. A bare "Architecture" label is as under-captioned as a chart titled "Data." (§32.7)Section 2 — True / False with Justification (5)
State true or false and explain in one sentence.
11. A more complete architecture diagram is always a better one.
Answer
**False.** Completeness often *reduces* communication—a thirty-box picture says "complicated," not "here's how it works." Completeness lives in the *set* of diagrams (context → container → component), each at one honest level. (§32.2)12. An unlabeled arrow between two boxes is acceptable because the reader can infer the relationship from context.
Answer
**False.** "A → B" could mean calls, depends on, sends data to, or inherits from—four different things. The unlabeled arrow is the single most common diagram bug; labeling it is the highest-leverage habit. (§32.7, Common Mistakes)13. You should always draw fully UML-compliant diagrams, down to the correct arrowhead style.
Answer
**False.** The chapter's guidance is "borrow UML's vocabulary, skip its ceremony." An 80%-correct diagram that's instantly clear beats a 100%-compliant one nobody reads; the goal is communication, not conformance. (§32.6)14. A diagram made to reassure executives can safely be reused as the team's working mental model.
Answer
**False.** A diagram simplified for a pitch carries blind spots; if new engineers learn from it, they inherit those gaps. Different audiences need different diagrams (audience is everything, [Chapter 2](../../part-01-writing-is-thinking/chapter-02-audience/index.md)); label the simplified one and keep an honest working version. (§32.8 Warning)15. The diagram you sketch on a whiteboard to figure out a design is the diagram you should publish.
Answer
**False.** Like the exploratory chart in [Chapter 9](../../part-02-building-blocks/chapter-09-visuals-and-data/index.md), the thinking sketch is for you; you rebuild the explanatory version for the reader who wasn't in the room. Sketch to think, then ship the keeper. (§32.9)Section 3 — Short Answer (4)
16. A reader needs to understand the order of calls in a token-refresh flow. Which diagram type, and why that one over an architecture diagram?
Model answer
A **sequence diagram**, because the message is *temporal order*—who calls whom and what returns, top to bottom—and an architecture diagram shows only static structure, losing the order entirely. *(Rubric: names sequence diagram + cites time/order as the reason.)*17. Give the chapter's three-step fix for an overcrowded "all-arrows" diagram, in order.
Model answer
(1) Decide the one idea and the level (this deletes off-topic arrows); (2) rename boxes to what they are; (3) label the surviving arrows and set one consistent direction. Meaning first, cleanup second—the editing hierarchy applied to a picture. *(Rubric: correct three steps in the meaning-before-appearance order.)*18. What's the difference between a diagram that is simplified and one that is misleading?
Model answer
A simplified diagram omits detail but doesn't make a false implicit claim, and it's honest about its scope (captioned, or paired with a deeper view). A misleading diagram's omission causes the reader to believe something untrue—e.g., "nothing here can fail." The line is whether the omission deceives. *(Rubric: identifies "honest scope / false implication" as the distinguishing factor.)*19. Why does the chapter recommend keeping a diagram's source (Mermaid text, .drawio file) next to the doc rather than just the rendered image?
Model answer
Because an un-editable diagram is one nobody updates—when the system changes, the orphaned PNG goes stale and silently lies to readers. Co-located, editable source (ideally diagrams-as-code that diffs in review) lets the diagram be revised alongside the content. *(Rubric: connects "editable + co-located" to fighting diagram rot.)*Section 4 — Applied Scenario (1)
20. You're documenting this for a new engineer: "A user submits an order. The order service reserves inventory, then charges the card through a payment provider. If the charge succeeds, it confirms the order and publishes an event that a worker uses to email a receipt. If the charge fails, it releases the inventory and returns an error to the user."
Produce: (a) the best diagram type and a one-sentence justification, (b) a small Mermaid diagram, and (c) a Level-3 caption. Then (d) name one thing your diagram does not show and whether that omission is honest.
Model answer + rubric
(a) A **flowchart** (or a sequence diagram with an `alt`/`else` branch) fits, because the message is a *process with a success/failure branch*—the fork is the point. (b) For example:flowchart TD
Start([Order submitted]) --> Reserve[Reserve inventory]
Reserve --> Charge[Charge card via provider]
Charge --> Q{Charge succeeded?}
Q -- Yes --> Confirm[Confirm order] --> Event[Publish event]
Event --> Email[Worker emails receipt]
Q -- No --> Release[Release inventory] --> Err[Return error to user]
Email --> End([Done])
Err --> End
Scoring & Next Steps
| Score | What it means | Do this |
|---|---|---|
| < 50% | Core ideas not yet solid | Re-read §32.1–32.2 and §32.7; redo Part A of the exercises |
| 50–70% | Partial grasp | Redo Exercises Part B and Part C (choose the right type) |
| 70–85% | Solid—proceed | Move to Chapter 33; do one Project Checkpoint diagram |
| > 85% | Strong command | Try Exercises Part E (build the C4 set; the honest second view) |