Guide · 8 min read
How to Summarize a 20-Page PDF into One Visual Summary Card
Working out how to summarize a PDF visually is mostly an editorial problem wearing a design problem's clothes. The drawing is the easy part now; deciding what survives is not. This is the method I would use for a twenty-page paper, report or chapter — the same three decisions every time, then about a minute of generation.
Published · Updated
First, decide what the visual summary is for
A visual summary made to revise from and a visual summary made to circulate are different artefacts, and trying to make one card do both produces something that does neither. Decide before you start.
A revision card is for you. It can be terse to the point of being cryptic to anyone else, because your memory supplies the context — its job is to be a retrieval cue, not an explanation. A circulating card is for someone who has not read the document and will not read it. It has to carry conclusions, and it has to be legible cold.
This one decision determines almost everything downstream: how much text each element holds, whether you keep the method or drop it, and whether the numbers need their sample sizes attached.
Second, find the load-bearing claim
The instinct when you summarise a long PDF is to start cutting sentences. Resist it: twenty pages almost never contain twenty pages of argument. There is usually one mechanism doing the work, a handful of things that depend on it, and a large volume of example, caveat, citation and restatement around the outside. The whole value of making a summary is that it forces you to separate those.
The fastest way in is to try to finish this sentence about the document: "the point is X, and it matters because Y." If you cannot, you have not found the claim yet, and no layout will hide that. Read the abstract and the conclusion first — in most reports and papers the argument is stated twice at the ends and developed in the middle.
Then list what hangs off the claim. Four or five dependent points is the sweet spot for a single card. If you have eleven, you have either found several claims (make several cards) or you are still listing content rather than structure.
If a document resists this treatment entirely, that is information. Documents with no load-bearing claim are usually status updates or literature surveys, and both summarise better as a list than as a diagram.
Third, pick the structure that matches the claim
This is the step people skip, and it is the one that does most of the work. The structure of a visual is an argument in itself: a timeline asserts sequence, a funnel asserts narrowing, an iceberg asserts hidden mass. Choose one that matches what your document actually claims and the design is largely decided. Choose one that doesn't and you have made a confident visual statement your source never supported.
- One mechanism with several dependent factors → a hub with spokes radiating out
- A process where the last step feeds the first → a closed cycle, not a line
- Two positions in opposition → a two-column contrast
- Visible symptoms over root causes → an iceberg, if the mass is genuinely hidden
- Several parallel findings with no order → a modular grid
- Independent readings and metrics → a dashboard of framed tiles
- Phases with real gates between them → a route with stations
Then generate it
With those three decisions made, the mechanical part is short. The steps below are Flowgraph specifically, but the sequence is the same whatever you use — the decisions above are what determine whether the output is any good.
- 01
Upload the PDF and pick your page
Drop the file in; it is parsed in the browser, so a two-column paper with running headers and footnotes does not need cleaning up first. For a long document, select the single page or section that carries the argument rather than feeding all twenty pages — one card per chapter beats one card per book.
- 02
Choose the structure you decided on
Pick the layout that matches your claim's shape from the list above. If you genuinely are not sure, leave it on auto and let the model read the structure — it is a reasonable default, but your own read of the document is usually better.
- 03
Set the register, not just the colour
A study card and a card going into a board pack want different styles: hand-drawn and pastel for the first, schematic or monochrome for the second. Set a brand hex if the card has to match a house style, and reuse the same combination across a set so the whole collection looks deliberate.
- 04
Generate, then read it cold
It comes back in about a minute. Now do the check that matters: look at it as though you had not read the document, and verify every number against the source. It is a generative summary, so treat it as a draft that needs proofreading rather than a derivation you can trust blind.
The mistakes that cost the most
Almost every bad visual summary I have seen fails in one of four ways, and none of them are design failures.
Scope: the card covers a whole book instead of one argument, and becomes a contents page with illustrations. Density: everything survived the cut, so the card holds twenty items and is unreadable at the size anyone will view it. Decoration: the layout was chosen because it looked good rather than because it matched the claim, so the visual asserts a structure the content does not have. And unverified numbers: a figure was rendered slightly wrong and got circulated, which is the one failure that does real damage.
The first three are fixed by making the three decisions above before generating. The fourth is fixed by reading the output against the source every single time, which takes thirty seconds and should be non-negotiable for anything that leaves your own notes.
Why one card and not a deck
There is a reason to prefer a single card over a five-slide summary, and it is not effort. A single frame forces prioritisation in a way a deck does not: with one canvas, including the fourth-most-important point costs you space that the first three needed, so the ranking has to be real. A deck lets you keep everything by putting it on the next slide, which is exactly how a summary quietly grows back into a document.
The constraint is the feature. If the result feels too tight, that is usually a signal you are summarising two things at once — which means two cards, each with its own load-bearing claim.