Interface as evidence

Pick the one interface state that answers the main objection, show it at full fidelity, then explain why it holds at scale.

Section sequence

5sections, in the order the visitor meets them. Bar height is the section's weight in the page.

  1. OrientObjection named
  2. DemonstrateMeaningful state
  3. ProveObjection-led callout
  4. ProveScale or control section
  5. ConvertStart or demo fork

How the page argues

  1. 1

    Name the objection in the visitor's language, before showing anything.

  2. 2

    Show the interface state that answers exactly that objection.

  3. 3

    Point at the part of the screen that does the answering.

  4. 4

    Follow with the scale or control section that says it stays true under load.

  5. 5

    Fork the exit by buyer type rather than by curiosity level.

What each section has to be

OrientObjection named
The doubt stated plainly, in the words a sceptical evaluator would use.
DemonstrateMeaningful state
A screen at working volume — a real backlog, a real dataset — not a three-row demo.
ProveObjection-led callout
One or two callouts pointing at the exact pixels that resolve the doubt.
ProveScale or control section
Limits, performance, permissions or governance — whichever the objection implies.
ConvertStart or demo fork
Self-serve for the hands-on evaluator, guided for the one buying for a team.

Is this the right sequence?

Who it is for

Evaluators with a specific doubt — speed, control, depth — who are looking for a screenshot that settles it.

Products it suits

Software where the interface embodies the benefit, so one honest state does more than a paragraph.

Not for

Products whose value is network reach or brand trust, where a screenshot answers nothing.

Evidence strategy

Which proof modes carry the page, in the order they land.

  1. Primary: the interface at working volume, which answers the doubt visually.
  2. Secondary: callouts that make the answer explicit rather than hoping it is noticed.
  3. Tertiary: scale and control facts, which extend a single screen into a general claim.

CTA plan

What the page asks for, what it offers instead, and where.

Primary
Start with your own data
Secondary
Book a walkthrough on your own workflow
Placement
The fork sits after the scale section, once the objection has actually been answered.

Responsive behavior

What the sequence has to do when the viewport stops cooperating.

  • The screenshot crops to the callout region on small screens rather than scaling to illegibility.
  • Callouts become numbered captions beneath the image on touch devices.
  • The scale section reflows from a stat row into a stacked list with units preserved.

Anti-patterns

The failure modes that make this sequence stop working.

  • A pretty screenshot with a nearly empty state, which answers no doubt at all.
  • Answering an objection nobody has while ignoring the one everybody has.
  • Six callouts, which means none of them is the point.
  • A fork where both paths land in the same contact form.

Build spec

Pro

What an agent needs in order to build Interface as evidence: what each section must contain, the copy rule that keeps it honest, the slots to resolve from your product, and the order to build in.

Checking access to the build spec

Agent tags

The vocabulary an agent matches this recipe on.

  • objection-led
  • working-volume-state
  • ui-callout
  • scale-section
  • buyer-fork