Show What the Product Actually Does—and Label the Rest

Three screens share a slide. Same typeface, same palette, same sheen. Underneath, they are three different things: one runs, one runs because somebody set it up that way, and one is a picture of software that does not exist. The deck calls all three "product demo," and the narration says the product takes a purchase request from start to finish.

The images haven't lied. The label has. A product image establishes only the behavior and the conditions it actually represents, and polish does not promote a proposal into a live capability. So the fix is not to photograph the product more humbly. It is to say, screen by screen, what is running, what is staged, what is recorded, and what is only drawn — and then to write a claim those facts can carry.

The claim and the picture are two separate things

Write the assertion before you look at the screenshot. Under "we do this," at least three different sentences hide:

• A person can complete this task now.
• A configuration can support this.
• The team proposes to build this.

Those are not the same sentence, and they don't deserve the same slide treatment. Decide which one you're actually making, then ask what the image in front of you establishes. A plain screenshot can carry a strong claim perfectly well. A polished one can carry almost nothing.

The reverse also holds. If someone clicked the request form once during a rehearsal and it saved, you have one observed run in one environment. That is a real thing, and it is not general reliability. It doesn't tell you the form holds up under a heavy day, behaves the same for every customer, or survives without the demo instance behind it. "We watched it work" and "it works" are neighbors, not synonyms.

Ask every image four questions

Whether a representation is honest usually comes down to four questions, and they don't agree with each other by default.

Is the behavior working or simulated? Does the software actually do the thing, or does the image show the thing happening? A form that saves is working. A screen where the "confirm" state is a picture of a state the software cannot reach is simulated, no matter how it was produced.

Are the inputs real or staged? Real customer data, or sample vendors, test names, invented amounts? Staged data is fine — it is often the responsible choice — but the reader is entitled to know that the numbers came from a spreadsheet of examples.

Is the view live or recorded? Is someone clicking through it in the room, or is this a video or a still from one? Recorded material can be more honest than a live demo on hotel wifi. It just isn't the same thing.

Does it depend on configuration or manual work? Two-step approval might be a rule an administrator switched on in this particular account. Supplier confirmation might be an email a person sends. Both can be legitimate; neither is the default behavior of the product.

These overlap, and that is the point. A recording can show a genuinely working feature. A live click-through can produce a simulated result on screen. A configured demonstration is live and configured at once. So resist the urge to sort your product into a single ladder of stages where each rung replaces the last. Sort each representation on four axes that are allowed to disagree.

The UK government's Service Manual, in its guidance on making prototypes, makes a narrower version of this point. Its sections on types of prototypes and on using code prototypes describe a realistic, interactive prototype that is deliberately not the live service: it can differ from production in security and performance, and its purpose is to help a team learn rather than to run the thing for real. That guidance was published in October 2016, it is written for UK public services, and it is not a commercial certification rule or a checklist for your product. Take one useful idea from it — realism isn't readiness — and leave the rest where it belongs.

Put the label where the inference changes

A disclaimer slide at the back cannot do this work, because readers infer as they scroll. The label has to arrive at the moment the inference would otherwise go wrong, which usually means three places:

• On the image or in its caption. If a screenshot will travel — pulled into a one-pager, a sales email, a conference slide — the qualification has to travel with it.
• In the narration at the moment the frame changes. "This next screen is a design" is a sentence someone says out loud, not a footnote somebody reads later.
• In the sentence that makes the claim. If the claim is "you can file a request," the label belongs in that sentence's neighborhood, not three paragraphs away.

Meaningful setup belongs in the surrounding narration or caption. "The two-step approval is switched on for this account" is one clear sentence. Buried in an asterisk, the same fact reads as an admission instead of an explanation.

And some gaps can't be labeled away. If the main visual still implies a capability the product doesn't have, a footnote doesn't fix the contradiction — it just documents it. Change the image, or change the claim.

An invented deck, and what each frame establishes

The example below is an editorial construction, not an inspection of anyone's product, and not a tested labeling system. It exists to show the decisions, not to report a result.

Picture a purchase-request tool. We'll call it Grayline Requests. The deck has three frames:

1. A request form. It works — the request really saves. The vendor names, dollar amounts, and approvers on screen are sample data. It runs in a demo environment, not a customer's account. It's clickable during the meeting.
2. A two-step approval. It works, in this account, because an administrator configured the approval rule here. The steps you see are the ones someone set up; they are not the default. Sample data throughout.
3. Automatic supplier confirmation. An email to the supplier, an updated order on the supplier's portal. Proposed. A static design. Not built.

Now the version assembled without any of that, which is the version most decks actually ship:

Grayline Requests: submit, approve, confirm with your supplier — end to end, in one place. Product demo.

Nothing on the slide is false, exactly. But the headline promises a chain, and the chain has a missing link. "End to end" requires all three frames to run; two of them do. The caption covers all three with one word, which means the reader has to guess which screen is which — and the natural guess, given how the slide looks, is that all three are live.

Keep the labels attached when the pictures travel

Screenshots have a way of escaping. The frame you labeled in the deck turns up in a one-pager without the caption, then in a partner's slide without the frame around it. If the qualification lived only in the presenter's narration, it's gone.

A small claim-to-representation record solves most of this, and it doesn't need to be elaborate — a few lines per claim:

• The claim — the sentence the deck makes.
• The representation — which frame supports it, and where that frame came from.
• The owner and version — who confirmed it, and against which build or configuration.
• The recheck trigger — what would make the sentence wrong again.

That last line is the one people skip. When the approval default changes in a later build, or the demo environment is rebuilt, someone needs to be able to see which sentence in the deck has to change with it. The record is boring, which is roughly the point: it's an index, not a document.

The record also prevents a quieter failure. Without it, a deck can end up combining the strongest parts of incompatible states — the working form from frame one, the configured approval from frame two, the designed automation from frame three — and describing them as one system. That system doesn't exist. It was assembled on the slide deck, and it will come apart in the first technical conversation.

Match the ask to what you have

Once the frames are described accurately, you can see what the room is actually being asked to do.

With a working form and a configured approval step, the honest request is feedback on the form's fields and a judgment about whether two-step approval matches the team's routing. Those are answerable questions. With a designed supplier-confirmation screen, the honest request is whether automatic confirmation is worth building — a design question, not a capability question. Nobody should be asked whether they're ready to buy supplier automation on the strength of a picture, and nobody should be asked to evaluate the ergonomics of a form they can't type in.

The ask usually has to shrink when the evidence is honest. That is a smaller loss than it sounds. A specific question about a specific screen gets a specific answer, and specific answers are what a product team can use.

The corrected passage

Same three frames, same meeting, labels doing their job:

Grayline Requests — what we can show today

Frame 1 — Request form (working). You can file a purchase request and the request saves. The vendor names, amounts, and approvers are sample data. This runs in our demo environment, not a customer's live account.

Frame 2 — Two-step approval (working, configured). In this account, an administrator has switched on a two-step approval rule. That's a setting, not a default, and it's the reason the screen looks the way it does.

Frame 3 — Supplier confirmation (proposed). This is a design, not built software. We're showing it so you can tell us whether automatic confirmation is worth building.

Today we'd like feedback on three things: whether the request form matches how your team files purchases, whether a two-step approval matches how you route them, and whether automatic supplier confirmation is worth building.

And the compact record that travels with it:

Read the middle column of the bottom row. Then read the headline the earlier deck used. That gap is the thing worth catching before the meeting instead of after it — because the labels are small, the screens stay the same size, and what changes is only what you can say the product does.

Frequently asked questions

Why isn't one 'product demo' label enough for a slide with three screens?

Because the three images may be three different things: one runs, one runs because an administrator configured it that way, and one is a design for software that does not exist. The images have not lied; the label has. A single word makes the reader guess which screen is which, and given how the slide looks, the natural guess is that all three are live.

Where should a qualification live?

Where the inference would otherwise go wrong. On the image or in its caption, so that it travels when the screenshot is pulled into a one-pager or a partner's slide. In the narration at the moment the frame changes, as a sentence someone says out loud. And in the sentence that makes the claim. A disclaimer slide at the back cannot do this, because readers infer as they scroll. Some gaps cannot be labeled away at all: if the main visual still implies a capability the product lacks, a footnote only documents the contradiction — change the image or change the claim.

Is it dishonest to show a screen using sample vendor names and invented amounts?

No. Staged data is often the responsible choice; the reader is simply entitled to know the numbers came from a spreadsheet of examples. The same applies to setup. 'The two-step approval is switched on for this account' is one clear sentence, while the same fact buried in an asterisk reads as an admission instead of an explanation.

Does watching the form save once mean the feature is reliable?

No. That is one observed run in one environment. It does not tell you the form holds up under a heavy day, behaves the same for every customer, or survives without the demo instance behind it. 'We watched it work' and 'it works' are neighbors, not synonyms.

What belongs in a claim-to-representation record?

A few lines per claim: the claim itself; the representation, meaning which frame supports it and where that frame came from; the owner and version, meaning who confirmed it and against which build or configuration; and the recheck trigger, meaning what would make the sentence wrong again. The last line is the one people skip, and it is what shows which deck sentence has to change when an approval default changes or a demo environment is rebuilt. The record is boring, which is roughly the point — it is an index, not a document.

Further reading

• Prepare a Demo Fallback That Still Answers the Question — If screens will be shown recorded or clicked live, read this for keeping date, version and staging attached, and for saying plainly what a substitute cannot establish.
• Build a Sales Deck Around the Customer’s Decision, Not Your Company History — Once the frames are labeled, this helps set the closing ask to the uncertainty the deck resolved, not to what a picture merely proposes.