Think in screens and states
Describe what a person sees and what the interface does as the app changes.
By the end, you can map a simple user flow and identify loading, empty, success, and error states.
Step 1: A picture is not a working flow
A screenshot cannot show what happens while saving, with no , or after an error. Think of a form as an order counter: the person needs to know whether their order is waiting, accepted, rejected, or still uncertain.
Step 2: Name the states honestly
Describe normal content, loading, empty results, confirmed success, rejected actions, and unknown outcomes. A dropped does not prove a save failed: the server may have saved it. Disabling the button helps prevent another click in this tab, but does not protect the saved action against every retry.
Step 3: Specify usable controls
Ask for connected visible labels, written errors that explain how to correct input, visible keyboard focus, and a complete keyboard submission path. Reuse the same spacing, type, and controls across screens. Do not communicate errors only through color.
Step 4: Try an error and a recovery
Test an empty account, missing input, keyboard submission, and a rejected save. Keep entered text. For a lost , show that the result is unconfirmed and check saved status before a duplicate-safe retry. Use fictional and make the intended outcome clear.
Plan this form’s normal, loading, empty, confirmed-success, rejected-save, and unknown-result states. Preserve input. Give each field a connected label and written error. Show visible keyboard focus. Do not claim success before confirmation or treat a lost as proof of failure. Illustrative before / after (behavior, not ready-to-run code): - Any click → Saved! + Submit → waiting → confirmed / rejected / outcome unknown
An empty successful is not a connection error. A lost is different from a server explicitly refusing to save.
Picture it, then try it
A lost reply is not a rejected save
A shop may receive your order even if its confirmation call drops. Calling again with a new order can create two orders.
Rejected: request → refused → no saved result Confirmed: request → saved → reply received Unknown: request → may be saved → reply lost Safe next step: check result or reuse same supported ticket
A connection drops after Send. What message is truthful, and what must happen before a new save?
Compare your reasoning with the worked answer
Say We could not confirm the save and preserve the input. Check the existing result or retry the same intent with supported duplicate protection. Only say Save failed when evidence confirms rejection; only say Saved after reliable confirmation. Button disabling helps clicks in one tab, not every network retry.
Sources and further reading
The saved-items succeeded, but this new account has saved nothing. What should the page show?
Choose one answer.