Forms that preserve progress

User taskpurpose

Name the person, the task they need to finish, and the observable outcome. Keep one primary task.

Primary actionprimaryAction

Specify the action label, when it is available, what it changes, and how success is confirmed.

Loadingloading

Describe what stays visible during a request, how progress is communicated, and how repeated actions are prevented.

Empty stateempty

Distinguish a first visit, no results, and unavailable data where relevant. Give a useful next step.

Error and recoveryerror

State where errors appear, which input is preserved, and how someone retries or recovers without repeating completed work.

Keyboard and focuskeyboard

Define native controls, tab order, focus visibility, focus after updates, and any Escape or arrow-key behavior.

Labels and feedbackaccessibility

Name controls and errors clearly, describe screen-reader announcements, and keep meaning available without relying only on color.

Narrow and wide layoutsresponsive

Describe how content reflows at 320px, what remains visible, and the maximum reading width on wide screens. Do not shrink text to make it fit.

Completionsuccess

Specify the visible result, whether focus moves, and how the user continues or undoes the action when supported.

Fields and defaultsfields

List each field, its visible label, input type, default, required status, autocomplete hint, and any help text.

Validation timingvalidation

Define rules and error text per field, when checks run, and how a submitted error summary links to invalid fields.

Submission behaviorsubmission

Describe duplicate-submit handling, server rejection, retry, preserved values, and any confirmation or undo required for consequential changes.

• Submit with a required field missing: show the specific error and move focus to an error summary or the first invalid field.
• Fail a submission: keep all safe entered values and provide a working retry action.
• Submit twice rapidly: the interface must not create duplicate records.
• Use only the keyboard at a narrow viewport: reach every field, error link, and action in a sensible order.

These are starting requirements, not a certification or a substitute for testing with people. Record a reason when a behavior does not apply.

Connect Amito to your AI assistant, fetch spec:form, and describe the behavior for each decision above. Ask the agent to run validate_design_spec to find missing decisions and placeholders.

{
  "pattern": "form",
  "decisions": {
    "purpose": "",
    "primaryAction": "",
    "loading": "",
    "empty": "",
    "error": "",
    "keyboard": "",
    "accessibility": "",
    "responsive": "",
    "success": "",
    "fields": "",
    "validation": "",
    "submission": ""
  }
}