Forms and feedback

Use when designing or reviewing anything a person types into, chooses from, confirms, or gets a result back from: sign-up and checkout forms, settings, dialogs, toasts, inline messages. Pair it with component-states and accessibility-basics.

Ground rules

• Use the app's existing form components and design tokens; do not hardcode colours or one-off styles.
• Check light and dark, and phone width (about 375 px).
• Copy is short and plain. One action per button.
• Anything that leaves the system on the user's behalf (an email to a customer, a payment, a public post) is a draft until the user presses the button that sends it. The form must make that visible, not hide it.

Checklist: forms

1. Ask for the minimum. Remove every field the system can know or default. If a field is optional, say so; do not mark required fields with colour alone.
2. Label above the input, always visible. A placeholder is an example, never the label. Add a short hint under the field only when the format is not obvious.
3. Right control for the data: toggle for on/off, radio buttons for a few exclusive choices, a select or searchable picker for many, a textarea for free text. On the phone use the matching keyboard type (email, number, tel).
4. Defaults. Pre-fill the safest, most common value. Dangerous or paid options are never the default.
5. Validate at the right moment: when the field is left or on submit, not on every keystroke. Never clear what the user typed after an error.
6. The error sits next to the field and says what is wrong and how to fix it ("Enter a number from 1 to 10"), not who is at fault. If several fields fail, add a short summary at the top and move focus to the first one.
7. One primary button per form, named for the result ("Create account", "Save changes"), not "OK" or "Submit". Cancel looks quieter. While sending, the button shows progress and cannot be pressed twice.
8. Unsaved work. Warn before leaving a form with typed text, or keep a draft. Long text must survive a reload or an expired session.
9. Dangerous actions (delete, reset, anything irreversible) need a confirm step that names the object and the consequence, with the verb on the button ("Delete project 'Website'"). Prefer Undo over a confirm where possible.
10. Secrets. Fields for keys or passwords are masked and never echoed back in messages, logs or screenshots.

Checklist: feedback

1. Every action answers within about a second: pressed state, progress, then result. Silence is a defect.
2. Pick the lightest fitting channel: inline text for field problems, a toast for small confirmations that vanish by themselves, a banner for a state of the whole screen, a dialog only when a decision is required.
3. Success says what changed ("Order #1042 refunded"), not just "Success". Offer the next step or Undo.
4. Errors say what happened, what is safe ("nothing was charged"), and what to do next, with a Retry button when retrying can help. No raw codes or stack traces as the only message; put details behind "Show details".
5. Toasts stay long enough to read, can be dismissed, never hold the only way to continue, and are announced (role="status", or role="alert" for failures).
6. Long work shows progress or a clear working state saying what is happening, and survives leaving the screen. An expired session or lost connection gets its own message and a way back in.
7. Empty results explain why and offer the first action ("No orders match 'blue'. Clear the filter").
8. Plan, billing or permission refusals are plain: what was blocked, why, and who can change it.

How to test

Walk each form: empty submit, wrong value, valid value, slow network, offline, double click, reload mid-typing. Capture light and dark at desktop and phone width on a local or staging build. Use test data only; keep real customer data, emails and keys out of screenshots.

How to report

One finding per problem, ranked by cost to the user. Each has where (screen, element, file), what (with a screenshot or the exact copy), why it matters, and the smallest fix naming the existing component or token. End with what you checked and what you could not check. Agreed fixes become tasks with acceptance criteria that cover both themes and phone width.