Every form in your app is a place where users can lose work or give up. Run this list on each form (sign-up, profile, checkout, feedback). Use a real device and the real keyboard.
The checklist
- Empty submit. - Why: it is the most common mistake. - How to check: tap submit with every field empty. Each required field gets a clear message; nothing crashes.
- Required vs optional is marked. - Why: users should not discover it by failing. - How to check: read the form before typing. Is it clear which fields are required?
- Very long input. - Why: long text can break layouts, hit server limits or be silently cut off. - How to check: paste several thousand characters into each text field. The app shows a limit or handles it, and the layout holds.
- Whitespace only and leading/trailing spaces. - Why: " " passes "not empty" checks, and a trailing space breaks email or username matching. - How to check: enter only spaces, then a valid value with spaces around it. It is rejected or trimmed.
- Special characters and unicode. - Why: names with accents, apostrophes, non-Latin scripts and emoji are normal input. - How to check: try names like O'Brien, Zoë, 李雷, a mixed-direction string and an emoji. They are accepted, stored and shown unchanged.
- Pasted input. - Why: pasted text often carries hidden spaces, line breaks or a different format. - How to check: paste an email with a trailing newline, a phone number with spaces or dashes, a password from a manager. The form copes or says exactly what is wrong.
- Format rules match real data. - Why: over-strict email, phone or postcode rules reject valid users. - How to check: try a plus-address (name+tag@example.com), a long TLD, an international phone number, a postcode of another country if you support one.
- Numbers and dates. - Why: decimal comma vs point, negative values and impossible dates cause wrong data. - How to check: type 1,5 and 1.5, 0, -1, a very large number, and 31 February. Switch the device region and repeat.
- Errors appear next to the field. - Why: a single error at the top makes people hunt. - How to check: submit invalid data; each message sits at its field, the first error is scrolled into view, the keyboard does not hide it.
- Messages say how to fix it.
- Why: "Invalid input" gives nothing to act on.
- How to check: read each message. It names the problem and the expected format.
- Input is kept after an error.
- Why: clearing a long form on error makes users quit.
- How to check: fail validation or the network once. All valid entries are still there, except sensitive ones like passwords if you clear those on purpose.
- Validation timing is sensible.
- Why: errors while the user is still typing are annoying.
- How to check: type a valid email slowly. No error shows before you leave the field or submit.
- Double submit is blocked.
- Why: two taps can create two records or two charges.
- How to check: tap submit quickly several times, also on a slow connection. Only one request goes through.
- Keyboard and autofill fit the field.
- Why: the wrong keyboard type makes input harder and autofill saves time.
- How to check: email field shows an email keyboard, number field a number pad, next/done buttons move focus, password manager fills.
- Server-side rejection is handled.
- Why: the server may reject what the app accepted.
- How to check: if you can, make the backend return a validation error. The app shows it at the right field.
- Screen reader reads the errors.
- Why: otherwise blind users do not learn what failed.
- How to check: turn on the screen reader and submit invalid data; the error is announced. See screen reader test in 10 minutes.
Related
Back to all checklists · Error states checklist · Empty states checklist
Fresh eyes find the form that rejects a perfectly valid name. Start free: private, structured feedback, 1 feedback = 1 credit.