Mobile App UX Checklist: Forms, Errors, and Empty States

Mobile app UX is rarely damaged by one dramatic mistake. More often, a product loses usefulness through small gaps: navigation that hides the next task, a form that forgets a user's progress, an unexplained permission request, a loading state that looks broken, or an empty dashboard that gives no clue what to do first. A practical checklist gives teams a way to inspect those moments before users have to report them.

Use a mobile UX checklist to decide whether a primary task is understandable and recoverable on a real device. The checklist should cover the roles using the app, the task they need to finish, the information and actions needed at each step, and the states that appear when data is missing, a connection is poor, an error occurs, or the user returns later. It should not be treated as a list of visual preferences.

Start with two or three high-value journeys and test them on representative screen sizes. Review navigation labels, back behaviour, focus order, tappable targets, orientation changes, forms, field guidance, validation, loading, empty states, errors, support routes, and return paths. Use realistic data rather than a perfect demo account. Record the issue in terms of the interrupted task and the responsible owner, not merely a screen comment.

Mobile use is interrupted. People move between applications, receive calls, lose connectivity, change devices, or return after a long gap. A field user may work with gloves or a slow connection. A customer may have only one hand free. An internal approver may open the app only when a decision is waiting. The interface and its supporting systems need to handle these conditions gracefully rather than relying on a linear, uninterrupted happy path.

1. Define the primary task and role before reviewing screens.
2. Test navigation, back behaviour, loading, form validation, errors, and empty states on real devices.
3. Use realistic content, account states, and connection conditions.
4. Make support, cancellation, and return paths visible where the journey needs them.
5. Assign owners and retest the completed task after implementation.

A focused review should produce task-based issues, annotated screen states, content and behaviour decisions, an implementation owner, and a retest plan. It should distinguish design changes from dependencies in the API, notifications, CRM, calendar, or support operation.

• Mobile UX task checklist and issue log
• Annotated navigation, form, error, and empty-state requirements
• Accessibility and responsive QA notes
• Prioritised implementation and retest plan

Common risks include reviewing only ideal data, treating an empty state as a temporary placeholder, ignoring platform back behaviour, using colour alone for status, showing errors with no recovery, and testing on only one premium device. Check the actual journey with the conditions and roles that matter to the business.