patrickz.aiLet’s talk ↗

Automate safely / Guide

Test an AI workflow where people actually use it

Create a field-test checklist covering poor connectivity, interruptions and recovery.

About 30 minutesSome experienceRead free · No sign-up

Before you start

A prototype or paper mock-up and three realistic user situations.

Why this lesson exists

The telephone-pole story asks a practical question: does the software still help when someone is distracted, mobile or offline? Evaluate the conditions around the model, not just its answer.

Do the exercise

  1. Describe the setting

    Record the device, available time, network quality and likely interruptions. Use an ordinary example such as checking a delivery address on a phone.

  2. Trace one task

    Write each action from opening the tool to confirming the result. Mark places where a wrong answer or repeated tap could cause a problem.

  3. Test three failures

    Try missing data, a slow connection and an interrupted session. Decide what the user should see and how their previous work is preserved.

  4. Write a recovery rule

    For each failure record the visible message, the safe next action and the information needed to resume. Test with someone who did not design the interface.

A prompt to adapt

Replace the bracketed parts with your own practice details.

Review this workflow in its actual setting. Task: [task]. Device and conditions: [conditions]. List three realistic failures. For each give a visible user message, a fallback, a recovery step and a test I can perform. Do not assume a reliable network or full attention.

What this looks like

If an upload is pending, the screen should say pending. A reassuring checkmark before server confirmation makes the workflow harder to trust.

Check your result

Use evidence from your output. A confident explanation from the AI is not enough.

  • Pending, successful and failed actions are distinguishable.
  • Interruptions do not silently discard work.
  • A new user can recover without reading developer logs.

If it isn’t working

If every test happens on your development laptop, borrow a slower device or throttle the connection. Record simulated conditions honestly rather than claiming a field trial.

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.

KEEP GOING

Your next useful step

Browse all 59 guides ↗