Review forms and recovery from errors

Check whether a person can correct a form, keep valid work and tell whether a retry saved a single result.

A task kit for design, usability and accessibility review. Read and adapt it without an account.

Use an approved staging site and synthetic data. A human or an agent can use this brief; an AI attempt supplies evidence to inspect and hypotheses to investigate. It does not stand in for research with people.

A task brief to adapt

Replace the starting URL, synthetic values and permitted actions with your own approved boundaries. Keep the outcome; leave the click sequence open.

Starting state: Signed in on the staging contact form with synthetic name and address values supplied. No contact has been saved. A separate fixture can simulate a failed response after submission.

Goal: Save a staging delivery contact after correcting an invalid postal code.

Observable success: The corrected contact appears once after reload. The error identifies the field and a valid format; other valid input remains. A retry does not leave the person uncertain whether another record was created.

Conditions: Run the invalid-input and interrupted-response cases separately on desktop and at 390px mobile width, with keyboard-only input and 200% zoom. Use a person with their screen reader to check error announcements. Record locale, browser, build and fixture behavior.

Permitted actions: Use only the staging form and supplied synthetic contact. Save one disposable contact per fixture. Use only the approved failed-response fixture; do not disrupt a live network, submit orders, make payments or send real messages. Stop if the form triggers an unexpected external action.

7 checks to make

Explain input before an error. Check visible labels, required fields and format guidance. Examples should match the active locale and stay available when the field is filled.
Locate the failed field. Submit the supplied invalid postal code. Check that the message names the problem in text, is associated with the field and can be reached by keyboard.
Keep valid work. Record the form before and after validation. Check that other values and selections remain, including when the form rerenders or the virtual keyboard closes.
Make correction possible. Enter the valid supplied code. Check the error clears when resolved and the next action is available without an unexplained disabled state.
Communicate a failed response. Use the separate interrupted fixture. Check whether the UI distinguishes a rejected save from an unknown result and offers a concrete recovery route.
Recognize the retry outcome. After an authorized retry, inspect and reload the contact list. Record whether one result is visible; duplicate prevention needs server evidence beyond the screen.
Keep recovery accessible. At mobile width and zoom, check that errors and the retry action remain visible around focused fields. A person confirms screen-reader announcement and focus order.

Worked illustrative evidence

Fictional example. These records were written to explain the review. They are not captured screens, customer results or a run of Variantly.

01 · Invalid input

Fictional specimen · static illustration

Save a delivery contact

Name: Empty after validation
Postal code: 12 · invalid
Error message: Something went wrong

1 · Valid input was cleared.
2 · The message does not name a field or correction.

Fictional screen annotation: Postal code is outlined in red; the only message at the top is Something went wrong. The name field is now empty.

Observation: the illustration loses valid input and does not identify a correction. Color alone does not explain the failure.

02 · Interrupted save

Fictional trace: Save contact → response unavailable → Try again. The contact list already contains the new contact after reload.

Observation: the result was uncertain at the retry prompt. A browser trace alone cannot establish whether retrying is safe or whether a duplicate could be created.

03 · Interpretation

AI hypothesis: a field-level correction and a recoverable saved-state check would help people resume the task with less repeated entry.

This needs validation with people. It does not measure frustration, successful recovery rates or the reliability of the underlying save service.

For a real review, retain the starting state, build, condition, action and outcome beside each screen. Include the accessible names, focus trace and rule output where available; mark missing evidence as unchecked. A person's screen-reader check is separate evidence.

A product change to consider

Proposed change: Preserve valid values and place a specific correction beside the postal code. For an unknown save result, offer a way to inspect saved contacts before suggesting another submission.

Recovery should continue the person's work. The product must distinguish invalid input from uncertainty about a write. A safe retry design also needs engineering review of duplicate prevention; wording cannot solve that boundary by itself.

A person decides

A reviewer opens the form and trace, then chooses Fix it for lost input or missing correction. The product and engineering owners decide the unknown-result recovery policy. Keep any claim about easier recovery Not sure yet until participants use both cases.

What to recheck

Repeat both reset fixtures on the changed build. Verify valid values remain, the postal-code correction is available by keyboard and announced in a native reader, and the final contact appears once after reload. If the interrupted fixture cannot establish the saved state, record couldn't tell and investigate the write separately.

A recheck records whether the condition was seen again, not seen, not checked or couldn't tell. A person decides whether the issue is resolved.

What this task leaves open

A visible single contact does not prove server idempotency, data integrity or reliability under real network failures. These synthetic cases cover one form and locale. They do not establish accessibility conformance or human error-recovery rates.

Keep task-review findings separate from accessibility report rows. These kits make no claim of human fidelity, conversion uplift or conformance certification.

Go deeper

Choose another task kit or ask for review of a task on your product. The request starts a conversation about coverage; it does not start an automated run.