Five-lens review of a client deliverable

One review pass catches whatever that reviewer happens to notice. A wrong number, a proof panel that contradicts its own caption, illegible mobile figures, a duplicated claim, and a document with no closing ask are five different kinds of defect, and no single read-through is tuned to catch all five at once. Running five narrow passes, each with one job, catches what one broad pass misses.

1. Treat this as a full pre-ship pass, not a fix-one-thing check. Running only the lens that seems relevant to today’s worry misses exactly the defects the other four exist to catch — that’s the whole reason there are five instead of one.
2. [manual] Presenter lens. Read it as the person about to pitch it live: section-by-section momentum, whether the 90-second open actually lands, objection coverage against the talk track, whether the document lands an ask anywhere, and any single slide or section that would derail the room.
3. [manual] Client-eye lens. Read it as a skeptical owner would, twice: the 3-minute skim path and the 30-minute full read. Where does trust get built, and where does it wobble; is it comprehensible without jargon; what does its tone say about whoever it’s implicitly being compared against.
4. [manual] Story lens. Check the narrative spine on its own terms: one headline system carried through start to finish, no claim repeated verbatim across two sections in a way that reads as padding, and a real close — a document that asks for something rather than one that just stops.
5. UX/data-viz lens, run against the rendered document. Capture it at three widths and every figure individually, grade contrast against WCAG, and check table layout at each width plus the print stylesheet. A proof panel that’s illegible on a phone, or unreadable once printed, is a defect regardless of whether the content behind it is correct.
6. Data-QA lens, run against the claims register. Recompute every registered number from raw sources — never from the document — and diff the document’s claim wordings against the register; make-the-numbers-defensible is how that register gets built in the first place. A proof panel whose visible rows contradict the sentence it’s attached to is this lens’s finding, not the story lens’s.
7. Collect every finding under one contract, and keep the five verdicts separate. CRITICAL / MAJOR / MINOR, its location, and the fix — reported per lens, not blended into one score. A document that fails only the data-QA lens and a document that fails only the UX lens need different people to fix them, and averaging the two into “REVIEW” loses that information.
8. [manual] Apply every CRITICAL and MAJOR finding. Route anything that changes the actual pitch — dropping a section, changing the ask, reordering the narrative — to whoever owns the deliverable; that is a strategic call this review surfaces but cannot make on its own.
9. Re-run the lenses a fix touched, not just a read-through. A contrast fix that turns out to fail on a different element, or a narrative edit that reintroduces a claim already used elsewhere, only shows up by checking again — not by trusting that the intended fix landed clean.

Five verdicts, not one

The value of running this as five lenses instead of one broad review is that a deliverable can be completely correct on four axes and fail hard on the fifth — every number right, contrast broken sitewide; or the narrative landing perfectly, one figure quietly contradicting its own caption. Blending that into a single pass/fail hides which axis actually needs the fix; keeping five verdicts tells whoever picks up the findings exactly where to start.