Interactive demo use case
Interactive Product Demos from Journeys
Build interactive product demos from approved Journey checkpoints with declared audience state, truthful presentation, Review, and refresh consequences.
Interactive Product Demos from Journeys use approved product evidence as the source for a guided, branched, or exploratory audience experience. Scenes remain connected to the Journey Version, State Capsule, source Observation, presentation transformation, Review Decision, and Publication receipt that support them.
The demo can simplify and persuade. It cannot invent product behavior or turn a simulated outcome into verified product truth.
Define the audience job
A prospect exploring value, a customer learning setup, a partner evaluating integration, and a support user recovering from failure need different demos. Choose one audience, trigger, question, and next action. Avoid a universal tour that becomes long, generic, and hard to maintain.
State what is live, sandboxed, cloned, prerecorded, simulated, or edited. Safe exploration can be useful without pretending it occurred in a real customer account.
Select the source Journey
Use a current immutable Journey Version with an observable outcome. Declare actor, role, plan, data, flags, locale, theme, viewport, clock, dependencies, and side-effect policy. Execute representative contexts and retain functional, visual, and accessibility evidence at meaningful checkpoints.
Complete Review before building a public demo from those Observations.
Design scenes as Renditions
A scene can crop, annotate, narrate, caption, add hotspots, or present a safe branch. Record these transformations without changing the source evidence. Keep product behavior and presentation ownership separate.
Each scene should preserve:
- source checkpoint and Observation;
- intended audience and context;
- screenshot, HTML, or video source type;
- transformation and editor version;
- narration, caption, transcript, and alternative text;
- hotspot and branch purpose;
- privacy and redaction policy;
- approving Decisions.
Branch from real differences
Branch when role, plan, objective, or product state changes the useful story. Do not personalize unsupported capabilities into existence. If an administrator and member see different permission boundaries, use distinct approved contexts. If only the company name changes, keep it a safe presentation variable.
Track every branch that depends on a different Journey context so future changes reach it.
Preserve accessibility
Support keyboard navigation, visible focus, meaningful names and order, captions, transcripts, alternative text, sufficient contrast, reduced motion, and clear outcome confirmation. Do not hide essential explanation inside screenshots or require precise pointer movement.
Test the actual embedded or hosted viewer, not only the source product Observation.
Review product and presentation separately
Product owners verify that scenes remain truthful. Marketing or education owners verify audience, narrative, pacing, and conversion. Design owners verify visual presentation. Accessibility and privacy owners verify their subjects. Channel owners verify delivery.
An automated demo builder cannot approve its own product claims. Record Decisions over exact versions.
Deliver and verify
Publish through the chosen demo platform, website embed, help center, in-app hub, or offline package. Retain the demo version, payload hash where possible, stable URL, access policy, delivery status, and receipt.
Request the audience-facing destination and verify scenes, branches, captions, links, privacy, and next action. An editor save is not delivery proof.
Keep the demo current
When the Journey changes, resolve affected scenes by checkpoint and context. Choose keep, refresh, reframe, merge, redirect, block, or retire. Update only affected scenes and their dependent captions, transcripts, hotspots, branches, thumbnails, and exports.
Treat copied or downloaded outputs as independent Publications unless the delivery remains live-linked.
Measure without inventing impact
Track scene ownership, version alignment, current approved evidence, and current delivery receipts. Use viewer completion, drop-off, lead, adoption, or conversion data only from legitimately connected first-party demo and analytics systems.
Do not claim an engagement improvement because the asset was generated faster.
Preserve exports
Offline packages, videos, PDFs, copied HTML, and slide exports are separate Publications. The live demo may refresh while an exported copy remains stale. Record the owner, destination, version, receipt, and retirement path for every durable copy. Verify final audience bytes and exclude private evidence or reusable session state.
First pilot
Choose one release-critical Journey and one audience. Select four or fewer checkpoints. Produce a linear demo and one meaningful branch. Complete product, presentation, accessibility, privacy, and channel Review. Publish and verify the audience-facing version.
Then introduce one controlled product change. Confirm the correct scenes become refresh-due and unaffected scenes receive keep Decisions. Expand only when that consequence persists reliably.
Continue with Product Demo vs Product Journey, Keep Interactive Product Demos Current, and Reshot vs Supademo.
Start with one release-critical Journey.
Define the outcome, declare its state, run it, inspect the evidence, and record the Decision before expanding coverage.