Public Demo Content: Mark Copied Drafts Clearly and Make Going Live a Deliberate Step

In a public demo of a business app, visitors may copy an item to edit it. The copy can easily look identical to the original live item, and a draft can be mistaken for something already published. This article proposes visible statuses and safe transitions. All examples are hypothetical sample content, not observed client results, and use no real data.

The artefact: a status table

Define a small set of states, each with a label, a visual treatment and allowed next steps.

Draft copy: created by copying another item. Label: Draft copy of Sample Menu. Allowed: edit, preview, discard, publish.
Draft: created from scratch. Allowed: edit, preview, discard, publish.
Live: published and visible to the demo audience. Allowed: copy, unpublish.
Unpublished: previously live, now hidden. Allowed: copy, republish.

Your demo may need fewer states; keep only those you can explain in one line each.

Visible cues

Every item shows its status as text, not colour alone. A draft copy shows its source name and a link to it. Live items show a published label and, if you keep one, the time they went live. Lists group or filter by status so drafts never hide among live items.

Safe preview transition

Preview should render the item as visitors would see it, with a persistent banner reading Preview: not published. The banner stays until the user leaves. From preview, offer Back to editing and Publish, with Publish asking a confirmation that names the item and says what changes: This will make Sample Menu v2 visible, replacing the live Sample Menu? Replace and keep both are different choices; present them separately if both exist.

Decision branches on publish

Copy of a live item: ask whether to replace the original or publish as a separate item. Default to separate, since replacing is the more disruptive action.
Required fields missing: block publish and list which fields.
Copy whose source was meanwhile changed: warn that the source differs and offer to view both before publishing.
Demo reset: if the demo periodically restores sample data, say so near the editing area so visitors do not expect persistence.

Stop conditions

Never publish on a single accidental click or on leaving the preview.
Never change a live item while someone edits its copy.
If the transition fails, leave the item as it was and say so plainly.

Naming copies

Give a copy a default name that includes copy, for example Sample Menu (copy), and require it to differ from the original before publish if your list would otherwise show two identical names.

Practical acceptance test

Using sample items only:

Copy the live Sample Menu. Expect a new item labelled Draft copy, naming its source, with the original untouched.
Edit the copy and open preview. Expect the not published banner throughout.
Leave preview without publishing. Expect no change to the live list.
Publish with a required field blank. Expect a block listing the field.
Publish the completed copy as a separate item. Expect two live items with different names.
Repeat and choose replace. Expect a confirmation naming both, and one live item afterwards.
Check that status is understandable with colours ignored, for example in a greyscale screenshot.

Conclusion

Clear status text, a persistent preview banner and a named confirmation make the difference between a copied draft and live content obvious. The scheme asks little of the interface and prevents the most embarrassing demo mistake: publishing by accident.