A useful public demo of a delete confirmation dialog should show which item will be affected, what deletion means, and how someone leaves without deleting anything. Record the safe exit as well as the final action. A screenshot of a red button cannot show whether backing out preserves the work or whether the interface tells the truth about recovery.
For a developer building a SaaS in public, this gives founder peers a concrete interaction to review. It also exposes questions that belong in implementation checks rather than a discussion about button color. Use prepared data and a suitable test environment for the demonstration.
The project-deletion flow below is fictional. It is a review method, not a report of testing an actual product. No action in a demo should affect real customer work, and a simulated result should be labelled as simulated.
Define exactly what the delete action affects
Imagine a small planning app with projects and tasks. Its current design allows the owner to delete a project. Before asking anyone to review the dialog, the developer needs to know whether this also removes tasks, attachments, shared access, or references elsewhere in the app.
Write that behavior in ordinary language. If the implementation archives a project and permits restoration, describe that behavior. If it permanently removes the project, do not borrow reassuring language from an archive flow.
The interface and the underlying behavior must agree. A dialog that says “Remove from this view” creates a different expectation from one that says “Delete this project and its tasks.” Changing the label alone cannot resolve an uncertain backend operation.
Keep the review scoped to one action. Deleting a task, leaving a shared project, and deleting a whole workspace can have different consequences. A public demo becomes hard to assess when it switches between those operations without explaining the difference.
Start the recording before the dialog opens
Show the project in its normal context and the control that opens the confirmation. A viewer should be able to tell which project the action concerns before reading the dialog.
In the fictional app, use a prepared project with a neutral name and sample tasks. Say that the data is prepared for the demo. Don't include real project names or customer material merely to make the recording look realistic.
Open the dialog and pause long enough for someone to read it. Avoid editing out the transition if that hides where focus goes or makes it unclear whether the dialog has already performed the action.
Ask a reviewer what they think has happened so far. They may interpret opening the dialog as the deletion itself, especially if the background item disappears early. That is a specific point to investigate rather than a general verdict on whether the design looks modern.
Make the target and consequence visible together
A generic “Are you sure?” prompt asks the person to remember the action and its scope. In the example, the dialog can name the prepared project and explain the actual consequence beside the final button.
Use only information the application can support. If the dialog displays a task count, check that the count refers to the affected tasks under the current conditions. A convincing number that is stale or calculated from another scope can make the prompt less trustworthy.
Don't add a list of alarming consequences simply to make the interaction feel serious. Name the consequences that actually apply. The point is to help someone decide, not to create a dramatic warning around every small action.
A peer review question can be direct: “Which item do you think will be removed, and what else do you expect to happen?” The answer reveals the viewer's interpretation before you explain the intended one.
Record the path that keeps the project intact
First demonstrate backing out. Use the non-destructive control, then show the original project and its tasks still present. If the interface offers more than one way to dismiss the dialog, inspect those paths separately.
The label for leaving should fit the operation. A dialog about cancelling a scheduled job can make “Cancel” ambiguous. In your own flow, check whether a reader can distinguish cancelling the dialog from performing the action described in it.
A visible return to the project is stronger evidence for this one path than simply closing the modal. It still does not prove that every dismissal path is safe. Keyboard input, clicking outside, navigation, or a connection problem may exercise different behavior.
Keep those unresolved paths in the review notes. Public feedback can help identify the questions; implementation checks establish what the actual system does. Do not describe an untested path as safe because the main recording ended well.
Review keyboard and assistive-technology behavior separately
The W3C alert-dialog pattern describes an interrupting modal message that obtains a response. It explains the role, label and description relationships, and warns that marking a dialog modal must match how it actually behaves.
This guidance is useful when reviewing a confirmation, but a video of the screen cannot establish that its semantics work. Inspect the dialog's accessible name and description, focus behavior, available controls, and the return from dismissal in the actual implementation.
Use the appropriate dialog pattern for the interaction rather than adding an alert role for emphasis. A semantic label is not decoration. It communicates behavior to software and people using assistive technology.
Report the checks you performed and the ones you did not. A short public clip may show a keyboard path while leaving screen-reader behavior for a separate check. That is a useful bounded artifact without claiming that the whole application meets an accessibility standard.
Show completion without implying an undo that does not exist
Only after reviewing the safe exit should the prepared demo show the final deletion path. Reopen the dialog for the same prepared project, confirm the action, and show the resulting state.
If the system supports restoration, demonstrate the actual supported restoration route in another bounded sequence. If it does not, say that clearly. Do not put an “Undo” control into a mockup and present it as proof that recovery works.
Check what a person sees if completion is uncertain. A slow response, repeated click, or stale list can leave the interface out of step with the operation. Those questions may need a separate test rather than a longer public recording of the happy path.
The completion message should describe the operation you can verify. A disappearing card alone does not tell you whether related data was removed, access changed, or the backend accepted the action exactly once.
Ask peers one question about the decision
Share the demo with a specific uncertainty: the target, the scope, the non-destructive exit, or the meaning of the result. Asking “Any thoughts?” invites people to review a different problem from the one you need to resolve.
Buildside is the community context here. Uriel Bitton builds and runs Buildside, which is this article's publisher relationship. Wherever you request feedback, give peers enough task context to judge the interaction without assuming they know the implementation.
A peer may understand the dialog perfectly and still lack the customer's workflow. Another may point out a risk you had not considered. Treat each response as a scoped observation or suggestion, then decide which question needs further evidence.
Don't turn agreement about the wording into proof that accidental deletion will never occur. Clear communication and reliable behavior are both part of the interaction, and each needs appropriate checks.
Keep a review record that survives the next redesign
Save the version reviewed, the prepared data conditions, the question asked, and what changed. Attach the relevant recording or screenshots to your own development notes so a later visual redesign does not lose the reasoning.
For the fictional project flow, the record might say that the dialog now names the project and that the recorded safe exit returns to the intact task list. It should separately list any unresolved recovery or keyboard question.
A follow-up build-in-public update can show the specific revision and the behavior verified. Avoid claiming a drop in user mistakes unless you have measured that outcome under a suitable method.
The useful public artifact shows a real choice with an understandable consequence and exit. That gives other founders a precise way to help and gives the developer a concrete interaction to revisit as the product changes.
Hey I'm Uriel Bitton. I write about building in public strategies and growing startups.
Subscribe for more stories on growing your audience by building in public.
Join us on Buildside: the social network for founders building in public.
Top comments (0)