Design the lifecycle, not only the answer

Review an AI feature across eight useful states: ready, collecting input, processing, producing output, awaiting review, completed, limited or uncertain, and failed or interrupted. This is a practical checklist, not a universal standard; combine or extend states when the actual workflow requires it.

Eight states to review

  1. Ready. Explain what the feature can help with and what the user needs to provide. Use an example that reflects a supported task rather than an exaggerated capability.
  2. Collecting input. Show which files, permissions, or context are included. Let the user correct the scope before consequential processing starts.
  3. Processing. Communicate that work is underway. Show trustworthy progress information where available, and offer cancellation when the workflow can support it.
  4. Producing output. If output appears incrementally, distinguish unfinished content from a completed result. Keep focus stable and avoid overwhelming assistive technology with repeated announcements.
  5. Awaiting review. Before a consequential action, summarize what will change, the target, and the available alternatives. Confirmation should describe the actual action.
  6. Completed. Show the result and what actually happened. Distinguish a draft from a sent message or an executed change, and provide a reference or history where useful.
  7. Limited or uncertain. Explain missing information or relevant limitations in terms the user can act on. Do not display an unvalidated confidence percentage as if it guarantees correctness.
  8. Failed or interrupted. Explain the affected work, preserve recoverable progress, and offer a specific retry, correction, or handoff. An unknown execution result needs investigation before a potentially duplicative retry.

Transitions matter as much as the screens

Draw the transitions between states and identify which are reversible. An assistant drafting text can allow rapid iteration; an agent changing external records may need a preview, explicit boundaries, and reliable recovery. Make the interface match the actual system capability.

Consider what happens when a user edits the prompt during processing, revokes a permission, navigates away, or reconnects after a timeout. These are product decisions that design and engineering need to make together.

Review checklist

  • Can the user tell whether the system is preparing, working, waiting, or finished?
  • Are proposed changes clearly different from changes already executed?
  • Does cancellation communicate whether any partial action occurred?
  • Can an uncertain result be checked without blindly repeating an external action?
  • Are errors, progress, and results accessible without relying on color or animation alone?
  • Does the next action match the user's actual level of control?

Further reading