How to Build a One-Page Reference Sheet from a Technical Demonstration

A technical demonstration can look easy while it is playing. The presenter knows where to click, which starting state to use, and what a successful result looks like. Later, your notes may contain the button names but not the conditions that made those actions work.

A one-page reference sheet preserves the smallest complete path through an ordinary task. It is not a transcript and it is not a claim that every case has been covered. It shows the observed sequence, the expected result, the conditions that matter, and the gaps that still need an answer.

This workflow is for demonstrations you are permitted to review and ordinary, reversible work. The software and example below are fictional. Do not use a short reference sheet as the sole authority for safety-critical, security-sensitive, legal, medical, financial, or destructive operations.

Define the exact job the sheet should support

Begin with one outcome and one starting state. “Learn the dashboard” is too broad. “Create a saved filter for overdue tasks from the team board” is specific enough to test.

Outcome: Save and reopen an overdue-task filter.
Starting state: The user is signed in and viewing the team board.
Out of scope: Permission changes, automations, and bulk edits.

The boundary prevents the sheet from growing into a compressed manual. If the demonstration covers several jobs, create separate sheets instead of shrinking every detail onto one page.

Capture source anchors before rewriting the steps

Give each important moment a location you can reopen. Use a timestamp, slide, chapter, screenshot number, or note heading. Then record what was visible before you interpret it.

• 02:14: presenter opens the Filters panel;
• 02:31: Status is set to Open;
• 02:46: Due date is set to Before today;
• 03:05: the result count changes from 48 to 7;
• 03:22: the filter is saved as Overdue — Team.

A source anchor does not prove that the step works for every user or account. It simply makes the sheet traceable to the demonstration you reviewed.

Separate four evidence states

Technical demonstrations often mix actions, explanations, assumptions, and omissions. Label them before writing instructions.

• Observed: the action and result were visible in the demonstration.
• Explained: the presenter described a condition that was not directly shown.
• Inferred: you concluded something from context, but it was not demonstrated or stated.
• Unresolved: the reviewed material did not answer the question.

Only observed actions belong in the core path without qualification. Explained conditions should be attributed. Inferences and unresolved cases belong in a separate “Check before use” box.

Use five blocks, not a miniature transcript

A practical one-page sheet usually needs five blocks:

1. Outcome: what the user will finish.
2. Before you start: the required screen, file, access, or input.
3. Core path: numbered actions written in the order shown.
4. Verify: the visible cue that confirms success.
5. Conditions and gaps: exceptions, assumptions, and missing cases.

Research on worked examples is often conducted in learning and problem-solving settings rather than workplace software documentation. Still, it provides a useful design principle: beginners can benefit from seeing a complete path rather than being asked to reconstruct it from scattered information. A 2021 study comparing example-based and example-free instruction reported advantages for worked examples in parts of the learning task, while earlier research also examined how example variability and prompted self-explanation affect transferable knowledge. Those findings support using a clear worked path, but they do not prove that any particular reference-sheet format will improve every workflow.

A one-page example from a fictional software demonstration

Imagine a fictional tool called Meridian Board. A permitted demonstration shows how to create and reopen a filter for overdue team tasks. The reference sheet might read as follows.

The result count is evidence from the fictional example, not a rule. Another board can return a different number. The verification step checks that the filter was saved and restored, not that it always returns seven tasks.

Write each step as action, object, and result

Use verbs that identify what the reader does. Name the object using the label visible in the demonstration. Add a result only when it helps the reader know whether to continue.

Action: Set
Object: Due date
Value: Before today
Result: The visible task list updates

Avoid “configure the filter correctly.” It hides both the action and the evidence. Also avoid adding a shortcut merely because it seems likely. If the presenter did not show or verify the shortcut, place it in the check list rather than the core path.

Keep screenshots selective

A screenshot earns space when it resolves ambiguity that words cannot resolve efficiently: two similar buttons, a hidden menu, a required field, or a success state. Crop to the relevant interface area while preserving enough context to locate it.

Do not use a screenshot as decoration. Remove account names, personal data, private workspaces, and unrelated browser content before sharing. Confirm that you have the right to reproduce the interface or demonstration material.

Turn missing cases into a visible queue

A useful reference sheet does not pretend that the demonstration covered every branch. Add a small queue with the missing condition and the next check.

If the main goal is to distinguish demonstrated evidence from product claims, use the separate guide on what you actually observed in product-demo notes. That article evaluates evidence; this one turns an already bounded demonstration into a job aid.

Test the sheet without replaying the demonstration

Give the sheet to an authorized reviewer who did not write it, or return to it after a delay. Start from the stated screen and attempt the core path without replaying the source. Record the first point where the sheet fails.

• Findability: Can the reader locate the named control?
• Order: Does each step become available when expected?
• Verification: Can the reader identify success?
• Boundary: Does the sheet warn about a case it does not cover?

Cornell University’s Learning Strategies Center describes retrieval practice as actively recalling information rather than only rereading it. A reference sheet serves a different purpose—it remains available during the task—but a short no-source attempt can reveal which step names or conditions the reader cannot yet reconstruct. Label this as a usability check, not a score of the person.

Add maintenance fields

Interfaces and processes change. Put a small maintenance line at the bottom:

Source reviewed: 2026-09-24
Sheet version: 1.0
Last task test: 2026-09-24
Owner: Training Operations
Open checks: empty result, duplicate name, read-only access

When the demonstrated process changes, compare the new source with the old sheet rather than silently replacing it. If you need a fuller procedure with decision points and exceptions, use the guide for turning a spoken walkthrough into written instructions.

Copy this one-page reference-sheet template

Task outcome:
Starting state:
Out of scope:

Core path
1.
2.
3.
4.
5.

Success cue:
Observed conditions:
Explained conditions:
Inferences to verify:
Unresolved cases:
Source anchors:
Version / owner / last test:

Choose one permitted demonstration and build a sheet for one ordinary task. Keep only the complete core path, attach a source anchor, add a visible success cue, and list at least one case the demonstration did not cover. Then test the sheet without replaying the source.

Sources

• The effects of example-free instruction and worked examples on problem-solving
• Learning from worked-out examples: example variability and elicited self-explanations
• Cornell University Learning Strategies Center: Effective Study Strategies