A convincing product demo and a useful record of that demo are different things. Your notes should make it clear what the presenter said, what you actually saw, and what you still need to check.
Use a product demo notes template with six fields: the task you care about, the presenter's claim, the observed result, the conditions, a source reference, and the next question. Keep untested points visibly open. You can use this method with a notebook or an ordinary document; no particular app is required.
Start with one task, not a feature list
Before the session, finish this sentence: “I want to see whether I can complete ___, starting with ___, and ending with ___.” Choose a real task you expect to perform. A long list of impressive features is less useful if you cannot connect them to that task.
For example, your task might be to find a past project note using a phrase you remember. That gives you something specific to ask the presenter to show. It does not assume that any particular product supports the workflow.
Write down any conditions that matter to you, such as the device used, the starting file, or who performs the task. Leave unknown details blank rather than filling them from memory later.
Use three labels while you listen
- Said: a statement made by the presenter. Use quotation marks only when you have the exact wording; otherwise label it as a paraphrase.
- Seen: an action or result you directly observed during this session.
- Still open: something the session did not establish, or a question that needs a separate check.
These are evidence labels, not ratings. A “said” note is not automatically wrong, and a “seen” note is not a guarantee that the result will be the same in every setting. The labels describe what your record can support.
There is a useful parallel in the GOV.UK Service Manual's guidance on analysing a research session: keep what was observed separate from the interpretation. We apply that general distinction here to product-demo notes. The template below is our editorial workflow, not a government product-evaluation standard.
Copy this six-field product demo notes template
Create one entry for each important task. A short stack of entries is easier to review than one paragraph that mixes several claims.
- Task: What am I trying to do, and what result would answer my question?
- Presenter's claim: What was said? Is this an exact quote or my paraphrase?
- Observed result: What steps and outcome did I actually see?
- Conditions: Which device, sample, setup, version, or assistance was involved? What was not shown?
- Source reference: Where can I check this again: my session notes, a slide number, a documentation link, or a timestamp in a recording I am permitted to use?
- Open question and next check: What remains uncertain, who will clarify it, and what evidence would resolve it?
At the top of the document, add the session date, product name, and version if known. Keep each observation brief and specific. The Service Manual's note-taking guidance similarly recommends clear notes focused on a single observation. You do not need to reproduce the entire conversation.
A worked example: an impressive search result
The following example is fictional. It is not a Recolx feature demonstration, customer account, or performance test.
Imagine a presenter demonstrating a generic document-search tool. They find a note about a project handover. Your first draft says: “Finds everything instantly. This will work for our whole archive.”
That sentence combines an observation with two conclusions the demonstration has not established. Here is a more useful entry:
- Task: Find the handover note using a phrase from the project discussion.
- Presenter's claim: Presenter said the tool can search project notes. Paraphrase, not an exact quote.
- Observed result: Presenter entered “handover checklist” and opened one matching note.
- Conditions: A prepared sample folder was used. I did not see how it was set up, and I did not try my own files.
- Source reference: My notes from the search demonstration, under “handover example.”
- Open question and next check: Ask whether we can repeat the task with an agreed, non-sensitive sample and try a phrase that has no match.
The revised note preserves the useful result without turning one example into a universal claim. If the presenter later provides another demonstration or documentation, add that evidence with its date. Do not silently rewrite the original entry as though you had seen it during the first session.
Ask questions that produce checkable answers
Instead of “Is it easy?”, ask “Can you show the steps from the starting screen to the finished result?” Instead of “Does it always work?”, ask “What conditions were used here, and what limitations should I check?”
Three follow-up prompts work well as starting points:
- “Which part did we see live, and which part was described or prepared earlier?”
- “What happens when there is no matching result or an input is missing?”
- “Where can I verify that point after this session?”
A presenter may not be able to answer every question immediately. Record the unanswered point as open. “Not demonstrated today” is different from “not possible.” Likewise, a promise to send information later is not the information itself.
Finish with a bounded recap
After the session, write three short sections: demonstrated in this session, described but not checked, and next checks. Keep your own judgment separate, and explain which observations support it.
If a follow-up is agreed, turn it into a specific task with an owner and timing. Our guide to turning meeting records into action items covers that next step. It is a different job from documenting what the demo established.
A recording, when permitted, may help you revisit the spoken explanation. It does not automatically preserve an on-screen action or prove that a product will work in your setting. Do not infer a visual result from an audio-only record.
Common questions
Do I need to record the demo?
No. Written notes can be enough for this template. If you use a recording or shared materials, follow the session's permissions. A timestamp is useful only when it points to a record you can actually access and use.
Should I record a pass or fail?
First record the evidence. If you add a judgment, define what task and conditions it applies to. Leave untested requirements open instead of forcing them into a pass or fail.
What if the live demo and later documentation differ?
Keep both references, including their dates and any version information. Ask which conditions explain the difference. Until that is clarified, preserve the discrepancy in your notes.
Try it in your next demo
Copy the six fields above and choose one task before the session starts. Your goal is a record that another person can inspect, not a page of confident-sounding conclusions.
Exploring Recolx? Start with the current Recolx Tap product page, then use the same template to organize your questions. This guide describes a note-taking method; it does not certify any product's capabilities.
