Skip to content

Specific Proof

"This tool changed how our team works," says Sarah K. Under the quote, a row of grey logos. Readers have seen that block on so many pages that they skip it. Nothing in it can be checked, so it adds nothing to the page.

On a page that persuades, put proof right next to the claim it backs, and make it specific enough to check: a named person with their role and company, or a number with its baseline and timeframe, because praise nobody can check reads as filler.

Haulwise

Plan loads so trucks don't run empty.

Dispatch for regional fleets of 10 to 200 trucks.

“Haulwise made a real difference to our empty miles.”

A happy customer

What a doubtful reader can do with this quote: 0 of 4

  • Look the person up (not yet)
  • Tell if they're like me (not yet)
  • Size the result (not yet)
  • Know when to expect it (not yet)

Turn the details on one at a time. A name alone does little, since anyone can type a name. A number alone raises a question: 18% of what, down from where? The number starts to mean something once the baseline is there, and the role and company tell readers whether the result could apply to them.

Specific means checkable

People expect a company to quote only its happiest customers. In Nielsen Norman Group's research on trustworthy design, participants treated a site's own testimonials with "a healthy dose of skepticism" and trusted reviews on outside sites more. Buyers go and look: in Wynter's survey of 100 B2B SaaS marketing leaders, 81% check third-party reviews before they buy software. That is a survey of one kind of buyer, not a test, but it agrees with what NN/g saw.

So proof on your own page works when it survives that check. A full name, a role and a company can be looked up. A number with a baseline can be compared with the reader's own. Linking to where the proof lives, such as a review site profile, a case study or a public changelog, shows you expect to be checked. It's Harry Dry's second test for copy: can you prove it false? Vague praise can't be proved false, so it proves nothing.

Don't count on specific words simply sounding truer. A 2010 lab study found that concretely worded statements were judged more likely to be true, and a preregistered replication found the effect much smaller than first reported. Details help because a reader can test them and can tell whether the result fits their situation. Specific wording on its own doesn't fool anyone.

A number needs its baseline

"Saved 40%" leaves out of what, compared with what, over how long, and for whom. Give the number its baseline (from 31% to 18%), its unit, its timeframe (in the first quarter) and its source (one fleet of 42 trucks). A modest number with all four tells the reader more than a large round one with none. If the figure is one customer's result, say so. If it's an average, say across how many.

Pick proof from customers who look like the reader. A dispatcher at a 42-truck fleet is better proof for the next 40-truck fleet than a famous logo that used one feature once.

Put it next to the claim

A reader doubts a claim at the moment they read it. A quote about speed belongs beside the speed claim, and a quote about setup belongs beside the setup steps. A testimonials section at the bottom makes the reader remember which claim each quote was answering. This is reasoning about how people read, not a measured result, but it follows from the same idea as sections that follow questions: each section answers one question, and its proof answers "does it work for people like me?"

The same goes for logos. A logo says a company uses the product, not for what or how much. A logo with one line under it, such as "Ridgeline Freight, 600 loads a week", does the work the bare logo can't.

Never make it up

A page built before there are customers has no testimonials, and an agent building one is tempted to invent them. Don't. Invented quotes are the generic content readers have learned to skip, and in the US the FTC's 2024 rule bans testimonials from people who don't exist, AI-generated ones included. Use what is real: a benchmark with its method, the number of teams in the beta, the founder's own results, the product itself running on the page (see show the product). Where the real proof isn't in yet, mark the spot in the code and tell the owner what's missing, as you would for any real content you don't have. Readers should never see a to-do note where the proof will go.

Resources

Search concepts

Search for a command to run...