“Read” is a lower bar than it sounds
Reading a long document has been measured more than once, and the numbers are humbling.
An eyetracking study published in 2010, across 21 users, 541 web pages and 57,453 recorded fixations, put viewing time at 80.3% above the fold and 19.7% below it. Screens were 1,024 by 768 pixels, which dates the study without changing its point.
A data scientist ran the same question on one publisher’s traffic in 2013. Of every 161 people who landed on a page, about 61, or 38%, were gone before reading a word. Median scroll depth on that site was around half the article, and 5% of readers never scrolled deeper than the very top pixel.
One publisher, thirteen years ago, measured on web pages rather than PDFs. We’re not offering either as a measurement of your document. Put your own PDF behind a link with analytics on it and you’ll have the figure for your readers inside a month.
We are saying that the first screen carries the argument or nothing does. Everything below it is for the reader who has already decided you’re worth the time.
Four documents, opened and compared
We pulled four published white papers from different industries and read them rather than describing them from memory.
NIST, Hardware-Enabled Security for Server Platforms, a draft cybersecurity white paper from April 2020. The file opens on a withdrawal notice: NIST withdrew the draft on 27 May 2021 and superseded it with NISTIR 8320, and says so on the first page. Past that notice the paper opens with an abstract, then keywords, a disclaimer, and a section headed Audience that names exactly who should read it. A public comment period is printed on the front matter: 28 April to 2 June 2020. It closes with 27 numbered references and an acronym appendix. About 12,000 words of prose, and the version history is public, which is more than most vendor documents can say.
Bank for International Settlements, The drivers of cyber risk, Working Paper 865, May 2020. Its abstract states the evidence in the second sentence: a database of “more than 100,000 cyber events across sectors”. Full academic reference list at the back. It never names an audience anywhere in the paper.
AWS, An Overview of the AWS Cloud Adoption Framework, published 22 November 2021, 38 numbered pages. Structured by perspective: business, people, governance, platform, security, operations. There’s no reference list. In its place sit “Further reading” and “Document revisions”.
Siemens, Supercharging the industry transformation with the comprehensive Digital Twin. 2,888 words, no publication date printed in it, and not one citation or source link in the file. The only URL it contains is its own product page, on the last line. It carries exactly one percentage: “Up to 80% of all product-related environmental impacts are already determined in the design phase.” No source is given for it.
Four documents, the same label, and almost nothing in common. That’s why “we need a white paper” tells a writer so little.
What the useful ones put first
NIST names its audience. BIS names its evidence base in the second sentence of its abstract. Neither vendor document does either one, and neither public document does both.
So the pattern isn’t a template. It’s a habit: tell the reader something verifiable before you start arguing.
AWS spends that space on the value of the framework. Siemens spends it on a quotation from a physicist.
Our own white paper structure puts the buyer’s problem first, in the words the buyer would use. Then why the usual answers fall short, with evidence. Then the approach, what it costs, what it returns, and what to do first.
You approve that as a section list before we write. Disagreements about a white paper are usually disagreements about the outline, and they’re much cheaper there than in a draft.
The reference list is not decoration
A source is a document somebody can check: a standard, a regulator’s text, a filing, a published dataset, a peer-reviewed paper, a vendor’s own documentation. That’s the definition on our service page, in those words.
A listicle citing another listicle is not a source. Neither is a market-size figure that six blogs repeat and none of them attribute.
Buyers ask for this directly. Ask them what would make vendor content more useful and the same 3 answers come back every year: less sales message, more data and research behind the claims, and less about the product and more about the business problem it sits in. A white paper with a reference list answers 2 of the 3 before the reader has finished the first page.
Four ways these documents fall apart
A number with no owner. The Siemens 80% figure is the clean example: a real document, a plausible claim, and no way for a reader to check it. Your specialist reader will try. When they can’t, the rest of the paper inherits the doubt.
The vendor’s own data dressed as market data. We set out the pattern in which content to gate: a platform reporting growth in its own registrations, quoted elsewhere as evidence that buyers like forms more than they used to. Growth in a network measures the network.
An argument that is really a product tour. If the recommendation is your product from section one, the document is a brochure with footnotes. Less sales message is the first thing buyers ask for when they’re asked, and a white paper is where that request gets ignored most often.
Assumptions hidden inside a total. Any cost or return figure has conditions attached. Bury them and the finance reader either finds them or stops believing the total.
Length follows the subject
The range across those four documents is enormous. NIST spends about 12,000 words because hardware attestation needs them. Siemens spends 2,888 and still has space to spare, because there’s no evidence being laid out.
Our own range is 2,500 to 5,000 words, and it moves with the subject rather than with the invoice. If your argument fits in 2,500, you shouldn’t be paying for 5,000.
Ask what would have to be true for your document to need the top of that range. Usually it’s a technical mechanism the reader has to follow step by step, or a cost model with several branches. If neither applies, you’re looking at a shorter paper or a long article, and we took that choice apart in white paper vs blog post.
Page count is the easiest thing to specify and the least useful. Specify the reader, the objection and the evidence, then let the length land where it lands.
What you hand over
Give us the material you already have, before anybody writes a section list. Internal decks, the spec, the objection handling your reps use, last year’s version if one exists.
It doesn’t need to be tidy. It needs to be complete, because the gap between what your specialists know and what’s written down anywhere is where these documents go wrong.
Work where nobody will give us access to the facts, no material, no interview, no sources, is work we turn down. Our about page says so under “What we refuse”, and this is the format where it matters most.
The part almost nobody writes
NIST prints an Audience section. Most commercial white papers don’t. It shows in the writing: the document tries to be legible to a CTO and a procurement lead and a curious generalist, and ends up written for nobody.
Name the reader in the outline. One job title. Everything else follows from it: how much you explain, which evidence you lead with, how long the thing needs to be.
We ask for that in the brief, along with the objection the document has to answer. The same two questions run our articles, and we set them out in how to brief a B2B writer.
What your experts owe the document
A white paper needs time from one or two of your specialists, with the questions sent in advance.
That conversation isn’t decoration. It’s where the claim gets bounded: the conditions under which your approach doesn’t work, the number that’s true for a 200-seat deployment and false for a 20-seat one.
Agreeing the argument with your experts before writing is also what makes publication under their name straightforward. They sign something they already shaped.
Where your figures are confidential, you decide at the outline stage what happens to them: used in aggregate, anonymised, or held back. Not after the draft, when the argument is already built on them.
Before it goes to design
Run these on the draft while changes are still cheap:
- Read only the first screen. Does it name the reader, the question and the evidence?
- Take every number and find its source in the reference list. Anything unattached comes out or gets attributed.
- Find the assumptions behind each cost or return figure. Put them where the reader can see them.
- Count the paragraphs that describe your product. If it’s most of them, you’ve written a brochure.
- Check that the claims your specialists bounded are still bounded after editing.
Step 2 takes an afternoon and saves the document. We run it on every draft, including the posts on this blog.
Sources
- NIST, Hardware-Enabled Security for Server Platforms, draft white paper, April 2020 - structure, audience statement, 27 references. Withdrawn 27 May 2021 and superseded by NISTIR 8320; the file states both.
- Bank for International Settlements, The drivers of cyber risk, Working Paper 865, May 2020 - stated dataset and full reference list.
- AWS, An Overview of the AWS Cloud Adoption Framework, November 2021 - “Further reading” in place of references.
- Siemens, Supercharging the industry transformation with the comprehensive Digital Twin - 2,888 words, no citations, one unsourced percentage.
Send us the argument and the person who has to be convinced by it. You get a scope, a schedule and a price within one working day.