A public SaaS demo should start in a known state, give visitors one task to try, and let them return to the same starting point. That makes the feedback easier to interpret. If every visitor inherits a different workspace, you won't know whether they struggled with your change or somebody else's leftovers.
When you build in public, the demo is part of the conversation. A screenshot can explain what changed. A repeatable demo lets another person examine the behavior behind that explanation. It doesn't prove demand, but it can make a technical discussion much more concrete.
Use a task with a visible finish. For a fictional invoice-review tool, the task might be: import the supplied sample file, find the row that needs attention, correct it, and review the final total. This is a worked example, not a description of Buildside's features.
Don't ask visitors to “explore everything” and then compare their reactions as though they attempted the same work. Exploration is useful when that is the research question. It is less useful when you need to understand why a particular step fails.
Write the task in customer language. “Review this sample invoice before export” gives someone an outcome. “Click the orange button, open the second tab, and edit row four” mainly checks whether they can follow your directions.
For the fictional demo, prepare one small sample file with invented businesses and amounts. State how many rows it contains, which condition needs attention, and what the completed result should mean. Keep the fixture small enough that you can check it manually.
Record the demo version and the sample's version together. A person reporting a problem should be able to tell you which release they tried. If you change the sample halfway through collecting feedback, note that change rather than combining every response into one pile.
The demo's first screen should explain what is real and what is simulated. A visitor shouldn't have to wonder whether an action sends an invoice to a customer. Keep external side effects out of the public sample path unless they are necessary, clearly explained, and deliberately authorized.
A shared editable workspace can make a demo hard to interpret. One visitor clears a row, another sees the cleared state, and a third tries to reproduce a problem against different data. Their reports describe different starting conditions.
Choose a separation model that fits the product. A private session, a disposable workspace, or a local sample state may work. Each has different implementation costs and limits. You don't need to expose those details in the invitation, but you do need to know which behavior your demo provides.
Check the boundary with two sessions before sharing the link. Change something in one, then examine the other. If changes appear in both, decide whether the demo should be read-only or whether you need to fix isolation first. Don't label a workspace private unless you have verified that claim.
A reset control should say what it resets. In our example, it restores the sample import and removes the edits made during that demo session. It should not affect a real account, another visitor's work, or a production dataset.
Test reset after a successful run, after an error, and after leaving the task halfway through. Then repeat the task. The second attempt should start with the documented sample and should not inherit a stale success message, an unfinished upload, or a hidden selection from the first attempt.
Also check a page reload. Decide which state should persist and describe it accurately. A reset button that changes the screen while leaving old data underneath can produce misleading feedback even when it appears to work.
A visitor saying “this seems easy” is giving you an opinion. Watching them finish the task without help gives you a different kind of evidence. Neither should be silently substituted for the other.
Nielsen Norman Group distinguishes interviews, which collect reported experiences, from usability tests, which observe interaction with a design. Apply that distinction to public demo feedback. A comment thread can help you find a question to investigate; it isn't automatically an observed usability session.
If you arrange a test, explain the task and observe where the person hesitates. Ask what they expected after the attempt. Don't coach them through every uncertain step and then record the result as independent completion.
Ask for the starting state, task attempted, steps taken, expected result, and actual result. Include the demo version and relevant browser information when those details could affect behavior. Make screenshots optional and tell people to omit private data.