patrickz
Before you start
Your phone with any chat assistant app (or the AI tool you are building) and a notes app. No prototype needed. Use the invented to-do items below, not private information.
Why this lesson exists
This lesson comes from the post “Software Is Judged at the Top of a Telephone Pole.” Its question: does the software still help when someone is distracted, mobile or offline, on a small screen with a weak signal, rather than in a calm demo? Here you run that test on your own phone.
The idea this guide practices: Stop asking which AI is best. Test it on your own work.
Do the exercise
Pick one real task
Type or dictate: “Turn this into a three-item to-do list: call the plumber, buy milk, send Sam the slides.” Do it once with a good connection and full attention. Note what a finished answer looks like.
Break the connection
Turn on airplane mode and send the same request. Write down exactly what the screen shows and whether your text is still there. Reconnect and see whether you can retry without retyping. Then ask for something longer, such as a 300-word packing list, and switch airplane mode on while it is still writing. Is it clear the answer is incomplete?
Interrupt yourself
Start again, switch to another app for a minute, then come back. Repeat the task one-handed while standing. Note anything you had to retype, any double send, and anything that looked finished but was not.
Write recovery rules
For each problem, write what the person should see, the safe next step and what must be kept so they can resume. Paste your notes into the prompt below, then ask someone who did not watch you to repeat the three tests.
A prompt to adapt
Replace the bracketed parts with your own details.
Here are my field-test notes for [task] in [app or tool] on [device]: [what happened offline, when cut off mid-answer, and when interrupted]. For each problem, write one recovery rule: the message the person should see, the safe next step, and what must be kept so they can resume. Then suggest one realistic condition I did not test and how to test it. Do not assume a reliable network or full attention.
What this looks like
If the answer stops when the signal drops, a good app says something like “Not finished, tap to retry” and keeps your request. A half answer that looks complete, or a request you must retype, is exactly what this test should catch. If you are building your own tool, the same rule applies to uploads: pending should look pending, not like a checkmark.
Check your result
Use evidence from your output. A confident explanation from the AI is not enough.
If it isn’t working
If nothing ever goes wrong, repeat the tests where the signal is weak, such as an elevator or parking garage, or ask for a much longer answer so there is time to interrupt it. If you are testing your own tool on a laptop, throttle the connection in the browser developer tools. Record simulated conditions honestly rather than claiming a field trial.
Optional. Progress stays in this browser.
Where this came from
Adapted from the archived LinkedIn theme “Software Is Judged at the Top of a Telephone Pole.” See the post coverage and editorial method.
Prepared September 2026. Tools and interfaces change; use current official setup instructions. Session lengths are estimates.