Advanced text diagrams
When the basic toolkit (boxes, arrows, trees, tables) starts to feel comfortable, there's a second tier of shapes worth keeping in your back pocket. Below are twenty more diagrams I reach for when prose alone is doing too much work.
The same principle still applies: fit the structure inside one screen. If a diagram needs scrolling, split it. If it needs color, you probably needed a real drawing tool — but you'd be surprised how rarely that's true.
1. Swimlane: parallel responsibilities
Like a sequence diagram, but each actor owns a vertical lane. Use it when an actor does multiple things between messages — sequence diagrams hide that work.
User Frontend Worker DB
─────────────────────────────────────────────────────────
click "save" ─►
validate input
serialize body
POST /api/save ─►
parse + auth
UPDATE posts ──►
commit
◄──── ok
compile MDX
cache to KV
◄──── 200 + json
green check ◄─
2. Gantt: tasks with duration
Where a timeline plots events as dots, Gantt plots them as bars — making duration and overlap the visual focus. Side notes mark blockers.
week 1 week 2 week 3 week 4
──────────────────────────────────────────────────────────
schema design ████░░░░░░
api routes ░░░████████░░░░ ◄── blocks UI
editor UI ░░░░░██████████
qa & polish ░░░░░░░░░░██████░░
launch prep ░░░░░░██░░
↑ ship date
3. DAG: dependencies with multiple parents
A tree gives every node one parent. A DAG allows many — which is what real build graphs, data lineage, and task schedulers actually look like.
┌────────┐ ┌────────┐ ┌────────┐
│ users │ │ orders │ │ items │
└───┬────┘ └───┬────┘ └───┬────┘
│ │ │
└─────┬──────┘ │
▼ │
┌────────────┐ │
│ user_orders│ ◄───────────┘
└─────┬──────┘
▼
┌────────────┐
│ ltv_view │
└────────────┘
4. ER diagram: entities with cardinality
Relational schema visualized. Crow's-foot notation translates surprisingly well to plain ASCII.
┌────────────┐ ┌────────────┐ ┌────────────┐
│ users │ 1 N │ posts │ N M │ tags │
├────────────┤─────────├────────────┤─────────├────────────┤
│ id (PK) │ has │ id (PK) │ via │ id (PK) │
│ email │ │ user_id FK │ post_ │ name │
│ created_at │ │ slug │ tags │ slug │
└────────────┘ │ body_md │ └────────────┘
│ status │
└─────┬──────┘
│
▼
┌──────────────────┐
│ post_tags │
├──────────────────┤
│ post_id (FK,PK) │
│ tag_id (FK,PK) │
└──────────────────┘
5. Layered architecture: vertical stack
Top depends on bottom. Drawing it stacked makes the dependency direction inescapable, and any reverse arrow is immediately suspicious.
┌──────────────────────────────────────────────┐
│ Presentation UI components, routes │
├──────────────────────────────────────────────┤
│ Application use cases, orchestrators │
├──────────────────────────────────────────────┤
│ Domain entities, business rules │
├──────────────────────────────────────────────┤
│ Infrastructure D1, R2, GitHub API, KV │
└──────────────────────────────────────────────┘
▲ depends on
│ (top depends on bottom)
6. Memory layout: byte-level structure
Packet formats, struct layouts, ABIs. Every cell is a byte (or word). Annotate the actual bytes underneath when explaining a wire format.
struct Header (16 bytes)
0 4 8 12 16
├───────┬───────┼───────────────┼───────┬───────┼───────────────┤
│ magic │ ver │ length (u32)│ flags │ resv │ checksum │
│ 2 B │ 2 B │ 4 B │ 1 B │ 1 B │ 4 B │
├───────┴───────┴───────────────┴───────┴───────┴───────────────┤
│ 0xCA 0xFE 0x00 0x00 0x10 0x40 0x01 00 0xDE 0xAD..│
└───────────────────────────────────────────────────────────────┘
↑ "0x1040 = 4160 bytes payload"
7. Org chart: top-down hierarchy
People (or services) reporting upward. Always rooted, mostly tree-shaped, but allows dotted-line reports across the structure.
┌──────────┐
│ CEO │
└─────┬────┘
┌───────────┼───────────┐
▼ ▼ ▼
┌────────┐ ┌────────┐ ┌────────┐
│ CTO │ │ CPO │ │ CFO │
└───┬────┘ └────┬───┘ └────────┘
│ │
┌──────┴──┐ ┌────┴────┐
▼ ▼ ▼ ▼
[Backend] [Web] [Design] [PM]
│
└ ┄ ┄ ┄ ┄ dotted line: shared with Web team
8. Mind map: a central idea radiates
For brainstorming or feature decomposition. The center holds the topic; each spoke names a sub-area, with leaves carrying open questions or specifics.
┌───────────────┐
│ Onboarding │
└───────┬───────┘
┌───────────────────┼───────────────────┐
│ │ │
┌────▼─────┐ ┌─────▼─────┐ ┌─────▼─────┐
│ Email │ │ Tutorial │ │ Sample │
│ verify │ │ steps │ │ data │
└────┬─────┘ └─────┬─────┘ └─────┬─────┘
│ │ │
A/B subject skip-button 5 templates
magic link copy 5 step max one-click load
9. Kanban: status columns
Cards moving left to right through workflow stages. Each column is a state. Card limits per column become visual constraints.
TODO IN PROGRESS REVIEW DONE
───────────── ───────────── ───────────── ─────────────
dark mode RSS feed shiki theme admin auth
image upload D1 schema
backup cron tiptap editor
i18n layout css
prose styles
(4 cards) (2 cards) (1 card) (15 cards)
10. Petri net: tokens through places
For concurrent state. Tokens (●) accumulate in places (boxes). A transition fires when its input places have enough tokens, consuming them and producing tokens in output places.
[ready] ● ● ● [done]
│ ▲
│ pickup │ complete
▼ (-1 from ready) │ (+1 to done)
┌──────────┐ ┌──────────┐
│ active │ ● ● ─────────────► │ finished │
└──────────┘ ~100ms work └──────────┘
▲ │
│ release │ reward
└───────────────────────────────────┘
(+1 back to ready)
11. Markov chain: probabilistic transitions
Like a state machine, but transitions carry probabilities. Outgoing probabilities from each state must sum to 1.
0.7
┌───────────────┐
▼ │
┌───────┐ ┌───────┐
│ idle │ ──0.3──► │ busy │
└───────┘ └───┬───┘
▲ │ 0.6
│ ▼
│ ┌───────┐
└───── 0.4 ─── │ done │
└───────┘
(returns to idle)
12. Calendar grid: a month at a glance
Days laid out in a 7-column grid. Single-character marks per cell stay scannable; legend explains what each mark means.
April 2026
Mon Tue Wed Thu Fri Sat Sun
1 2 3 4
· · · ·
5 6 7 8 9 10 11
· ●● · ● · · ·
12 13 14 15 16 17 18
● · ● · ★ · ·
19 20 21 22 23 24 25
· ● · ● ★★ · ·
26 27 28 29 30
★ · · · ·
· light ● focus session ★ ship / milestone
13. Latency budget: proportional bars
Total response time decomposed by stage. Bar widths scale to actual percentage — instantly shows where the time is spent.
total: 218 ms 0 ms 218 ms
├──────────────────────────────────────┤
DNS 4 ms █
TLS handshake 18 ms ░██
TTFB 12 ms ░█
HTML download 8 ms █
parse + script 31 ms ░░██
DB query (D1) 102 ms ░░░░░░░░░░░░██████░░░░
JSON serialize 22 ms ░░██
network out 21 ms ░░██
├──────────────────────────────────────┤
14. Funnel: narrowing stages
Conversion through a multi-step flow. Each row is shorter than the one above; the sharpest drop tells you where to focus.
Step 1: Visit homepage ████████████████████████ 10,000
Step 2: View pricing ██████████████░░░░░░░░░░ 5,820 (-42%)
Step 3: Start signup ████████░░░░░░░░░░░░░░░░ 3,210 (-45%)
Step 4: Complete signup █████░░░░░░░░░░░░░░░░░░░ 2,140 (-33%)
Step 5: Active in week 1 ███░░░░░░░░░░░░░░░░░░░░░ 1,180 (-45%)
Overall conversion: 11.8% | Biggest drop: pricing → signup
15. Heatmap: 2D intensity grid
Two dimensions on the axes, intensity in the cell. Four shading characters (░ ▒ ▓ █) cover most cases; add a legend.
mon tue wed thu fri sat sun
00:00 ░ ░ ░ ░ ░ ░ ░
06:00 ▒ ▒ ▒ ▒ ▒ ░ ░
09:00 █ █ █ █ █ ▒ ▒
12:00 ▓ ▓ ▓ ▓ ▓ ▒ ▒
15:00 █ █ ▓ █ ▓ ▒ ▒
18:00 ▓ ▓ ▓ ▓ ▒ ▒ ▒
21:00 ▒ ▒ ▒ ▒ ░ ▒ ▒
░ low ▒ med ▓ high █ peak
16. Histogram: distribution
Where a sparkline shows trend over time, a histogram shows distribution across buckets. Vertical bars are easier to read for many buckets than horizontal.
request latency distribution (last 1h)
▆
█
█
█ ▆
█ █
█ █ ▄
█ █ █ ▂
█ █ █ █ ▁ ▁
─────────────────────►
<50 100 200 500 1s 2s+
p50: 87 ms p95: 412 ms p99: 1.8 s
17. Sparkline: inline mini trend
A tiny chart that fits inside a sentence. The 8 block characters (▁▂▃▄▅▆▇█) form a complete vertical resolution.
deploys / day ▂▄▃▅▄▆█▇▅▄▃▂▃▄▅ (last 15 days, max 14)
active users ▁▁▂▃▄▅▆▇▇█████▇ (last 30d, +38% MoM)
error rate ▆▇▅▃▁▂▁▁▁▁▁▁▁▂ (last 24h, post-fix dip)
p99 latency ▄▅▄▅▆▆▇█▇▆▅▄▄▃▃ (last 30d, slowly down)
18. Sankey-lite: flow that splits and merges
How traffic, money, or attention moves through a system. Bars stay roughly proportional; arrows indicate where flows merge or diverge.
total: 10,000 visits / day
organic ──┐
3,200 │
├─► landing ──┐
direct ───┘ 8,400 ├─► signup ────► converted
5,200 │ 2,820 420
│
referral ──► blog ──────┤
1,600 1,600 ├─► docs ─────► (read & leave)
│ 1,180 2,400
└─► (bounced)
4,400
19. Annotated code: callouts in source
Line-numbered code with margin arrows pointing to specific lines. Lighter than embedding code in a paragraph, heavier than an inline reference.
1 function parseEnv(raw: string): Env { ◄── ① always pass a string
2 const map = Object.fromEntries(
3 raw.split('\n') ◄── ② '\n' is fine on all OS
4 .filter(l => l && !l.startsWith('#'))
5 .map(l => l.split('=', 2))
6 );
7 return EnvSchema.parse(map); ◄── ③ throws here if missing
8 }
① callers feed fs.readFileSync result directly
② Windows CRLF gets normalized by Node 21+
③ ZodError surfaces at boot — never deep at runtime
20. Git branch graph: commit topology
How branches diverged and merged over time. Mirrors git log --graph --oneline output. Useful for explaining how a feature landed.
* d2a8f1c (HEAD -> main) Add admin auth middleware
* 4ec03b2 Wire up TipTap to D1 (#42)
* 8f0bca7 Merge pull request #38 from feature/r2-uploads
|\
| * 9b1c8e4 (origin/feature/r2-uploads) Multipart parser
| * 7e2d11f Sketch upload form + presigned URL flow
| * 1a4b6c2 Add R2 binding to wrangler.toml
|/
* a8c904d Switch shiki theme to github-light
* 32f7820 Initial blog scaffold
Why so many
Each shape exists because some structure is awkward in any other shape. A sequence diagram is wrong for a Gantt chart, a tree is wrong for a DAG, a histogram is wrong for a sparkline. The right diagram makes a structural fact obvious; the wrong one makes you squint.
You don't need to remember all twenty. You need to remember that they exist — and reach for one when prose is doing too much work alone.