Live and Demo Modes Should Share One Product Surface

A demo should explain the real product without pretending to be a live account. That becomes difficult when demo and live modes evolve as separate interfaces.

The usual split begins innocently: live mode reads authenticated data, while the demo uses convenient fixtures. Soon each path gains its own component, labels and empty states. The demo becomes attractive but inaccurate, or the live product improves while the demonstration quietly falls behind.

Separate the source, share the presenter

Live and demo modes genuinely differ in data authority.

Live mode reads records the current user is allowed to access. It must present real pending, missing, failure and permission outcomes. Demo mode uses clearly identified sample data and must not imply that a mutation affected a real account.

Those differences belong in the source adapter and command policy. Once the data reaches a truthful view model, both modes can use the same product presenter.

Why one surface is stronger

Sharing the presenter means that improvements to layout, accessibility and product language reach both modes. It also makes the demo a useful test of the product contract rather than a second marketing implementation.

The shared surface should include:

• the same information hierarchy;
• the same field and action names;
• the same responsive and accessible behaviour;
• explicit demo labelling;
• commands that are safely simulated or disabled when no real authority exists.

Avoid environment branches everywhere

A product component filled with if demo branches is still two interfaces hidden in one file. Prefer a bounded source decision near the top of the flow, then pass the resulting state through the ordinary presenter.

If demo mode needs a materially different workflow, that difference should be named and justified rather than leaking through every child component.

What we do at FireUX

FireUX treats live and demo as different sources for a shared Console presentation where the product meaning is the same. The live reader retains authorization and operational authority. The demo supplies explicit sample state without becoming another owner of the interface.

This follows the same principle as aligning contracts rather than every interface: preserve genuine differences at the correct boundary and share the behaviour that exists for the same reason.

A faithful demo is not a screenshot of an imagined product. It is the real product surface receiving safe, clearly labelled evidence.