Information hierarchy skill

Load for large human-facing outputs: reports, docs, multi-section explanations, artifacts.

by haowjy·Apache-2.0 license·★ 506 Stars on the repo·GitHub ↗

Use now

Files of Information hierarchy

haowjy/main1 file shown
SKILL.md
Show the full text73 lines

Information Hierarchy

The reader should get the answer in the first thing they see, and find depth only when they reach for it. Everything else here follows from that: each beat of the piece takes the form that carries it best, what matters most comes first, and the medium stays as simple as the content allows.

Lead with the answer/conclusion

Readers scan. Open with the finding itself, and the piece works in thirty seconds. The same logic repeats at every scale: a section's first sentence is its answer, a slide's title is its takeaway ("Cache misses double p99" rather than "Performance"), a UI label carries its whole meaning alone.

Behind the answer sits depth (reasoning, evidence, edge cases), and behind that, sources. Keep depth that most readers will skip, and move it: a later section, a linked page, a footnote. Sources belong at the end.

Pick the form that fits the idea

Prose is the default; break from it when another form genuinely carries the idea better. An example grounds an abstract claim faster than more explanation. A table holds enumerable facts that prose would bury. A chart shows a trend that a sentence can only assert. A mockup shows a layout the reader would otherwise have to imagine.

Diagram-first for pipelines and relationships. When the content is a pipeline, a dependency graph, a state machine, or any structure where the relationship between parts is the hard idea, put the diagram early — a one-sentence takeaway, then the diagram, then detailed prose. The diagram leads, the prose still explains; prose alone buries the shape. Keep diagrams to a handful of nodes and validate them (see /md-validation).

Ask what the beat is trying to do, then give it the form that does that: an explanation gets a paragraph, a comparison gets a table. Each form teaches best inside its own job: a diagram standing in for an explanation teaches less than the paragraph would.

Match hierarchy to the medium

For any medium, ask one question: can it hide content until the reader asks for it? Chat, email, and plain documents show everything at once, so hierarchy there means density and order: every early sentence pays for itself, and depth lives behind a link. Media that can hide (HTML, apps, anything with expand or navigate) may fold depth into collapsed sections, popovers, or child pages. Reserve each interaction for depth a reader will actually reach for.

Structure helps the scanner in every medium: headers that carry the argument on their own, asides for context off the main thread, a table of contents when the piece is long enough to need a map. These organize the surface; putting the answer first remains the job of the writing itself.

Choose the simplest medium that presents every beat well: a tight reply beats an HTML site whenever both would teach the same thing. When HTML is earned, build it phone-first and default to light mode (/structured-artifact has the mechanics).

Sources

1---
2name: information-hierarchy
3description: |
4 Load for large human-facing outputs: reports, docs, multi-section
5 explanations, artifacts. Choose the right form for each beat (prose, diagram,
6 table, mockup) and put the answer first, depth behind it. If the medium allows, use progressive disclosure.
7---
8 
9# Information Hierarchy
10 
11The reader should get the answer in the first thing they see, and find depth
12only when they reach for it. Everything else here follows from that: each beat
13of the piece takes the form that carries it best, what matters most comes
14first, and the medium stays as simple as the content allows.
15 
16## Lead with the answer/conclusion
17 
18Readers scan. Open with the finding itself, and the piece works in thirty
19seconds. The same logic repeats at every scale: a section's first sentence is
20its answer, a slide's title is its takeaway ("Cache misses double p99" rather
21than "Performance"), a UI label carries its whole meaning alone.
22 
23Behind the answer sits depth (reasoning, evidence, edge cases), and behind
24that, sources. Keep depth that most readers will skip, and *move* it: a later
25section, a linked page, a footnote. Sources belong at the end.
26 
27## Pick the form that fits the idea
28 
29Prose is the default; break from it when another form genuinely carries the
30idea better. An example grounds an abstract claim faster than more
31explanation. A table holds enumerable facts that prose would bury. A chart
32shows a trend that a sentence can only assert. A mockup shows a layout the
33reader would otherwise have to imagine.
34 
35**Diagram-first for pipelines and relationships.** When the content is a
36pipeline, a dependency graph, a state machine, or any structure where the
37*relationship between parts* is the hard idea, put the diagram early — a
38one-sentence takeaway, then the diagram, then detailed prose. The diagram
39leads, the prose still explains; prose alone buries the shape. Keep
40diagrams to a handful of nodes and validate them (see `/md-validation`).
41 
42Ask what the beat is trying to do, then give it the form that does that: an
43explanation gets a paragraph, a comparison gets a table. Each form teaches
44best inside its own job: a diagram standing in for an explanation teaches
45less than the paragraph would.
46 
47## Match hierarchy to the medium
48 
49For any medium, ask one question: can it hide content until the reader asks
50for it? Chat, email, and plain documents show everything at once, so
51hierarchy there means density and order: every early sentence pays for
52itself, and depth lives behind a link. Media that can hide (HTML, apps,
53anything with expand or navigate) may fold depth into collapsed sections,
54popovers, or child pages. Reserve each interaction for depth a reader will
55actually reach for.
56 
57Structure helps the scanner in every medium: headers that carry the argument
58on their own, asides for context off the main thread, a table of contents
59when the piece is long enough to need a map. These organize the surface;
60putting the answer first remains the job of the writing itself.
61 
62Choose the simplest medium that presents every beat well: a tight reply
63beats an HTML site whenever both would teach the same thing. When HTML is
64earned, build it phone-first and default to light mode
65(`/structured-artifact` has the mechanics).
66 
67## Sources
68 
69- [How Users Read on the Web (NN/g)](https://www.nngroup.com/articles/how-users-read-on-the-web/):
70 scanning, why the lede must come first.
71- [Progressive Disclosure (NN/g)](https://www.nngroup.com/articles/progressive-disclosure/):
72 defer secondary content to secondary screens.
73 

Discussion