Show interface state changes clearly in a demo

Create a worksheet with four entries: before, trigger, intermediate state and confirmed result. Add the evidence asset for each entry. An intermediate state may be absent in the real product; document that absence instead of inventing a spinner for visual interest.

Distinguish a local selection from a saved change. Highlighting an option may only update a form. The actual confirmation might require Save, a status message or a refreshed object. The storyboard must use the product's observed sequence, including consequential steps.

This illustrative worksheet describes a fictional request tool whose supplied workflow includes a Save action. The sample object is R-021, 'Review sample artwork.' It is a planning example, not evidence that any particular product behaves this way.

• Before: R-021 is open; Owner reads Unassigned. Evidence needed: full detail screenshot with the request identifier and field visible.
• Trigger: open Owner, select Example reviewer, then select Save. Evidence needed: the real option menu and save control. Explain both selection and commitment.
• Intermediate: show the actual pending feedback if it exists. If production timing is shortened, use a clear elapsed-time cut rather than implying a measured instant response.
• Confirmed result: the saved detail screen reads Owner: Example reviewer. Evidence needed: a capture after confirmation, ideally followed by reopening the same object to check persistence.
• Unchanged anchors: R-021, its subject and the surrounding panel stay identifiable throughout. Changing the sample object would break the causal connection.

Begin with a short hold on Unassigned. Place the cursor on the actual control, let the option label be read, then move attention to Save. After confirmation, highlight the owner field rather than zooming immediately to another feature. The viewer needs time to compare the old and new values.

A callout such as 'Choose the owner, then save' can clarify a two-part action. 'Done' is weaker because it leaves completion undefined. Use position, text and an appropriate visual emphasis together; a color change alone may be easy to miss.

If only before-and-after stills exist, describe them as supplied states and use an explanatory cut. Do not animate a convincing but unverified menu sequence between them. Request missing evidence when the interaction itself is essential to the lesson.

Decide whether a failure state belongs in this demo. For a task introduction, a separate troubleshooting link may be sufficient. For training, include the actual recoverable message and the corrective action. In either case, a pending state must never be used as the final proof of completion.