How to find missing states in AI-generated forms

1. Define the task and the data boundary

Choose a form someone actually needs to complete, such as inviting a teammate or creating a project. Identify which fields are required, what a valid result looks like, and whether the prototype is simulating a request or calling a real service.

Use fictional data during review. Confirm the expected validation rules with the product owner rather than accepting whatever the generated screen happens to do. A convincing email field can still submit an empty value, discard useful input, or report success without completing the intended operation.

2. Walk the form through meaningful states

Begin with an untouched form, then try an empty submission and a value that violates a known rule. Correct the input and submit again. Observe what happens while the request is pending and when the action succeeds or fails.

Use a controlled fixture or the project’s testing setup to exercise a slow request and a recoverable failure. Do not manufacture a production outage to test an error message. Record the setup so another reviewer can reach the same state without guessing.

Form review matrix
Untouched: instructions and required fields are understandable
Invalid: the affected field and correction are clear
Pending: progress is visible and duplicate submission is handled
Failure: entered values survive when safe; recovery is available
Success: the confirmation matches the operation actually completed
Return visit: saved results appear where expected
Narrow layout: errors and actions remain reachable

3. Check recovery and keyboard use

Read the error as someone who does not know the implementation. It should help identify the problem and the next useful action. A generic failure message can be appropriate when details are unavailable, but it should not pretend that a specific field is wrong without evidence.

Navigate the form by keyboard and confirm that labels, visible focus, and submission remain usable. Review whether important status changes are communicated to assistive technology. W3C’s form tutorials explain labeling and validation; a short state matrix does not cover every accessibility requirement.

• Keep labels available after values are entered.
• Confirm that validation does not erase correct input unnecessarily.
• Check whether focus moves or remains in a useful place.
• Avoid communicating an error through color alone.

4. Request a bounded correction and retest

Capture the exact state and describe the intended behavior. For example: “After an invalid invitation, keep the entered email and show the correction next to that field. Preserve the existing validation rule.” That gives an agent a narrower task than a request to improve the entire form.

After the change, repeat the invalid submission, correction, and success path. Check the narrow layout again because new error text can change the structure. If the prototype still simulates the request, state that limit when sharing the review; a polished success state does not establish that the real service works.

Common questions