Test offline UX by interrupting a real task, inspecting what the interface knows about the attempted change, and checking the resulting record after reconnecting. An offline banner alone cannot tell a reviewer whether a request never left the browser, reached the server without a visible response, or remains unresolved. Make those differences part of the public demo.
For a developer building in public, this gives peers a useful behavior to inspect. A recording that starts after the connection has recovered can hide the moment a user must decide whether to wait, retry or leave. That decision is where the demonstration should spend its time.
The document-sharing product below is fictional. The suggested test cases are a rehearsal plan, not results from a tested application. Use an isolated test account and sample records. Keep any disruptive network change limited to the test setting you control.
Name the task and the expected shared result
Imagine a product where a project lead shares a brief with a teammate. The lead changes the brief and submits it. The teammate should later see the intended version once, with the correct status. This is the task the two observers will inspect.
Write the expected result before changing connectivity. Decide what counts as the submitted version and which screen can confirm it. The lead's editor, a confirmation message and the teammate's view may reveal different things. Do not silently use whichever one looks most reassuring.
Give the sample brief a harmless distinctive phrase so observers can identify the version. Record the starting state in both accounts. A second observer is useful because the person pressing Submit may otherwise judge success entirely from the screen that made the attempt.
Keep the first run small. One brief and one attempted submission are easier to reason about than a busy workspace with several pending edits. You can introduce overlapping actions later, once you can describe what happened in the simpler case.
Treat connectivity indicators as hints
MDN's navigator.onLine documentation explains that browsers use different heuristics for online status and that a network connection may exist without internet access. It cautions against treating that property as reliable proof of connectivity. A visible indicator needs limits just as a public claim does.
In the fictional product, a browser reporting online would not prove that a particular submission succeeded. The relevant service could still be unreachable or the response could be delayed. An indicator can help explain a possible problem while the application handles the actual operation's outcome.
Describe the test condition precisely. A browser's offline simulation, disabling a local connection and making one service unavailable are different interventions. A successful rehearsal under one condition does not establish that every network failure produces the same behavior.
For a public walkthrough, state which condition you used and when you introduced it. Keep internal addresses and private request details out of the recording. Peers need enough context to assess the behavior, rather than an unfiltered log of your environment.
Separate the case where nothing was sent
Begin one rehearsal with the test browser already offline. Attempt the submission and inspect the interface. Does it preserve the text? Does it explain whether any action is waiting? Can the observer tell which parts remain local to this device?
If the product supports a queue, identify what is actually queued and how the user can inspect it. If it does not support offline submission, make the available next step understandable. Do not display a completion message merely because the click was accepted by the interface.
Ask the second observer to check the starting brief independently. The expected finding in this particular rehearsal may be that it has not changed, but inspect it rather than assuming. This creates a clear comparison between the attempted local action and the shared record.
Write down the visible state before reconnecting. Otherwise, a fast recovery can erase the confusing message you wanted feedback on. The useful record includes what the user could reasonably understand while the connection was absent.
Rehearse a submission whose outcome is uncertain
Now consider a different case: the request may have left the browser before the connection is interrupted. The interface has not received a usable confirmation. From the lead's point of view, that is an uncertain outcome, not sufficient evidence that the server did nothing.
Choose a controlled way to rehearse that boundary in your test setup. Record the timing you can observe, and acknowledge anything you cannot establish. If your setup only simulates a failed request before sending, do not describe it as a lost-response test.
Look closely at the recovery choices. A large Retry button can appear helpful while leaving the user uncertain about duplication. Inspect what happens when the offered action is used. Does the shared record contain the intended result, an extra submission, an older version or no change?
Keep the public claim tied to that observation. You can report that a particular retry produced one visible submission in this test. You cannot conclude that every timing condition is safe, or that the behavior holds for other operations you did not attempt.
Give the observer a decision to make during the uncertainty. Ask whether they would press the offered recovery control, keep waiting or leave the page, and what message led them there. Record that explanation before revealing the eventual outcome. A message can become obvious in hindsight while remaining unhelpful at the moment the user must act. This separates the clarity of the recovery choice from whether the particular request eventually completed.
Check reconciliation after the connection returns
Reconnect and watch the transition before refreshing. Does the interface distinguish waiting, retrying, confirmed and failed work in a way that fits its actual behavior? A disappearing banner should not be the only clue that the operation has reached a conclusion.
Then inspect the shared record from the teammate's account. Compare the distinctive phrase, the version and any relevant status with the intended result. This check answers a different question from whether the lead's screen looks complete.
If the product allows continued editing while a submission waits, add that as a separate case. Note which version should be sent and what happens to later changes. Do not let a recording of the first simple case imply support for this more complicated sequence.
Refresh only after you have captured the transition you want to review. Then check whether the confirmed result survives. If a refresh changes the apparent outcome, preserve that difference in the test record rather than choosing one view as the entire story.
Give founder peers a test record they can question
A useful build-in-public post can show the initial state, attempted action, interruption, recovery message and final shared record. Explain which parts are observations and which are your interpretation. The sequence gives another developer somewhere specific to challenge the reasoning.
Ask a focused UX question. For example, could a person tell whether this brief was still waiting on their device? Or did the retry choice explain what would happen to the original attempt? These questions invite feedback on the uncertainty a real user must navigate.
Buildside's founder community is a place to share visible product work and connect with peers. Present the rehearsal as one bounded test, with sample data and known limits. A peer's comment can improve your next test without proving reliability across the product.
Finish with the unresolved case you will inspect next. That could be a longer interruption, leaving the page, or a later edit that conflicts with queued work. Choose it because the current observation leaves a real question, and keep the next promised behavior separate from what you have already verified.
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.
Sources
MDN: navigator.onLine and the limits of connectivity heuristics
Top comments (0)