A useful session timeout UX demo shows the work before expiry, the sign-in transition, and the exact state afterward. Make it clear which values were saved and which were still drafts. Returning to the same screen does not prove that unsaved work survived, and seeing text in a field does not prove it was stored successfully.
For a developer building a SaaS in public, that sequence gives peers a concrete continuity problem to review. It is more informative than a screenshot of a “Session expired” message or an unqualified claim that the app keeps everything safe.
The project-note editor below is fictional. All example values and states are prepared for explanation. This is a review workflow, not a report of testing a real app, and it does not recommend changing a production authentication policy for the sake of a recording.
Define the activity that should continue
Imagine a planning app with a project title and a longer meeting note. The user has saved the project title, then started editing the note without submitting the latest changes. Their authenticated session expires while that note is open.
There are several different things to inspect: the saved title, the unsaved note, the user's location in the task, and their permission to continue. Give each one an explicit expected state in your own review notes.
Do not use “restore the session” as a catch-all phrase. A new authenticated session, a restored page, and recovered draft data are separate results. A product can achieve one and fail another.
Keep the public demonstration scoped to the activity. You do not need to expose authentication tokens, internal account information, or a customer's workspace to show whether a prepared note remains available after sign-in.
Prepare a before-expiry record
Use distinctive, harmless sample values that a viewer can recognise later. The note might contain a short prepared agenda with an unfinished final line. A generic paragraph of filler makes an accidental reset harder to spot.
State whether the displayed note is already saved. If the interface has a save indicator, include it in the recording and check what that indicator actually means in the implementation. Do not call a value server-saved merely because a spinner stopped.
Record the expected outcome before triggering expiry. That prevents a successful-looking return from becoming the standard after the fact. The demonstration should answer a question you deliberately chose to inspect.
Keep a copy of the prepared values in your private review record. After sign-in, compare against that record rather than relying on memory or assuming that similar-looking text is identical.
Trigger expiry under known test conditions
Use a suitable test environment and a supported way to exercise the expired-session path. Describe the relevant conditions without publishing credentials or turning a temporary test configuration into advice for production.
Distinguish a real expiry from a mockup that displays the message. A simulated screen can help review wording, but it cannot establish that the application handles an expired credential, redirects correctly, or preserves a draft.
If you shorten a test session for the demonstration, say that the timing is a test condition. A recording with an edited pause should also say that the waiting period was compressed.
Do not claim that every expiry path behaves identically. Inactivity, an explicitly ended session, and an account change may have different consequences. Choose the path you intend to show and keep other cases in a separate check list.
Show what the person can do at the interruption
When the app asks the person to sign in again, record the available action and the explanation beside it. A viewer should be able to understand whether their work is still present, temporarily unavailable, or known to be lost.
Do not promise draft preservation in the message before the behavior supports it. If the system cannot recover a draft, the explanation needs to reflect that limit while the product team investigates the design.
Avoid replacing the whole flow with a still image of a warning. The transition matters: does the interruption cover the editor, replace it, or take the person to another page? Those choices affect what someone thinks has happened to the note.
Ask a peer to describe their next action from the visible state. Their answer can reveal unclear wording. It cannot verify the authentication or storage behavior behind the interface.
Compare the state after sign-in
Complete sign-in using a prepared test account through the normal supported flow. Return to the project and compare the saved title, unsaved note, and task location with the before-expiry record.
Show the full relevant note, including its unfinished final line. A restored first paragraph can hide lost edits farther down. Check whether the interface distinguishes a recovered draft from the last stored version.
If the note reappears, establish what that result means. It might still be an unsaved draft awaiting submission. The demo should not imply that recovery automatically completed the user's original action.
Then perform the intended save under the current authenticated state and check the supported confirmation. Treat that as a further step. Recovery, permission to save, and successful persistence each deserve their own observation.
Use accessibility guidance with its actual scope
The W3C explanation of re-authentication describes a Level AAA criterion: after an authenticated session expires, the person can continue their activity without losing data when they authenticate again. It explains why losing work can especially affect people who need more time.
That gives the review a useful goal. It does not mean a short clip proves that the whole application conforms to WCAG, or that one particular storage design is required in every system.
Review the interaction with the input methods and assistive technology relevant to your actual implementation. A pointer recording does not establish focus behavior, an accessible explanation, or a usable route back for a keyboard user.
State the checks performed and their limits. A public demo can show a specific continuity path while a separate implementation review addresses the rest of the criterion and the broader product requirements.
Keep recovered data tied to the right person
Preserving a note is not the only requirement. The application must also handle the identity and access under which that note can be viewed or submitted. Do not treat any successful sign-in as permission to attach previous work to the new account.
For the fictional editor, record an unresolved account-change case separately from the same-account demonstration. It may need a design decision about how to explain available drafts without exposing another person's content.
Do not improvise a storage workaround merely to make the public sequence look smooth. Local retention, shared devices, server storage and deletion have different implications that belong in the actual product's design and security review.
The public artifact should report what was observed under the stated conditions. A preserved sample note is useful evidence for one path, not a certificate that draft recovery is safe across every device, identity and failure condition.
Ask founder peers one continuity question
Buildside is the founder-community context for this review. Uriel Bitton builds and runs Buildside, which is this article's publisher relationship. A prepared demo gives peers a specific interaction to assess without asking them to inspect private customer work.
Choose one question: can they tell what survived, can they identify what still needs saving, or does the return location match their understanding of the task? Keep implementation findings separate from opinions about the message.
If you make a revision, repeat the relevant before-and-after sequence. A clearer sentence is a useful improvement, but it does not repair lost state by itself. Show the state comparison again when behavior changes.
Keep the version, conditions, prepared values and unresolved cases in your development notes. Your next build-in-public update can report one checked improvement and the boundary around it. That gives readers useful progress while preserving an honest account of the work still left to verify.
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)