Further Reading — Chapter 32: Visual Storytelling

Annotated, Tier 1 (verified landmark works and official documentation) and Tier 2 (real, widely-attributed ideas) only. No invented sources. Read these in the order that matches what you're trying to draw.

Tier 1 — Start here

Simon Brown, The C4 Model for Visualising Software Architecture (c4model.com). The reference for the one discipline that fixes most architecture diagrams: don't draw "the architecture," draw a set of diagrams at increasing zoom—Context, Container, Component, Code. The site is free, concise, and notation-light (it's a way of thinking, not a strict notation). If you read one thing from this list before your next design doc, read this. Directly underpins §32.2.

Mermaid official documentation (mermaid.js.org). The reference for the diagrams-as-code format this book uses. The "Syntax" section covers flowcharts, sequence diagrams, ER diagrams, class diagrams, and state diagrams, each with copy-pasteable examples. The "Live Editor" lets you draft a diagram in the browser and see it render instantly—the fastest way to learn the syntax for §32.3–32.6. Bookmark the flowchart and sequence-diagram pages especially.

Edward Tufte, The Visual Display of Quantitative Information (2nd ed., Graphics Press, 2001). Already cited in Chapter 9, and just as relevant here. Tufte's principles—maximize data-ink, delete chartjunk, never let decoration obscure the message—apply to diagrams as much as charts. His critique of graphics that fail to consider what the viewer is supposed to learn is the spirit of this whole chapter. Read the chapters on data-ink and on "chartjunk" with diagrams in mind.

diagrams.net (draw.io) documentation and editor (drawio.com / app.diagrams.net). The free, full-featured visual editor discussed in §32.9. The docs cover keeping diagrams in version control (the embedded-.drawio-in-PNG/SVG trick that keeps source and image together) and integrations with common doc platforms. Useful when you need precise layout that diagrams-as-code can't give you.

Tier 2 — Going deeper

The UML standard and the practical "just enough UML" tradition. UML is a large, formal notation maintained by the Object Management Group; most practitioners use only a fraction of it informally. The widely-shared practical wisdom—captured in books like Martin Fowler's UML Distilled—is to borrow UML's vocabulary (class, sequence, and state diagrams especially) while skipping its ceremony. Useful background for §32.6 if you want to go past "enough to be useful."

Crow's-foot (entity–relationship) notation. The cardinality notation used in §32.5 (and supported by Mermaid's erDiagram) is a widely-attributed convention dating to early data-modeling work; "one," "zero-or-many," and "one-or-many" markers appear across textbooks and tools. Any reputable database-design text covers it; the point to internalize is simply that cardinality is the payload of an ER diagram.

The "architecture decision record" (ADR) practice. Diagrams rarely travel alone—they accompany a written record of why a design was chosen. The ADR practice (introduced in Chapter 25) is the natural home for an architecture diagram plus its rationale. Worth pairing with this chapter when you write design docs, because a diagram answers "what" and the ADR answers "why."

How these connect to the book

For the caption-that-interprets principle these diagrams depend on, return to Chapter 9 (Visuals and Data).
For accessibility, alt-text, and color-independent meaning, return to Chapter 10 (Design and Layout).
For the assertion–evidence idea—caption as claim, diagram as evidence—see Chapter 30 (Slide Design).
For the ethics of a diagram that hides complexity, look ahead to Chapter 38 (Ethics and Responsibility), where the Challenger case (Chapter 9) returns.

Back to: Chapter 32 · Key Takeaways