How to Design APP User Flows: Normal, Error, and Interruption-Recovery Paths

Real users do not move from the first screen to success exactly as a prototype does. They lose connectivity, switch to the background, deny permissions, let sessions expire, or enter directly from a notification. Flow design must handle every branch, not only the easiest path.

Real users do not move from the first screen to success exactly as a prototype does. They lose connectivity, switch to the background, deny permissions, let sessions expire, or enter directly from a notification. Flow design must handle every branch, not only the easiest path.

01 Users Do Not Follow a Straight Line Through the Design

Prototypes usually show the smoothest path: open the APP, log in, select, submit, succeed. Real use is full of branches: the network drops, a verification code expires, permission is denied, the user switches to WeChat to check information, the operating system kills the process, or payment returns an uncertain result. Designing only normal completion leaves the most failure-prone decisions to developers in the moment.

An APP user flow should be modeled as states and events, not arrows between screens. A screen explains what users see; the flow must also explain what the system knows, what changes, and where users resume after failure.

02 Draw Four Lanes, Not Only Screens

Four lanes reveal problems such as the interface showing feedback without saved system state or users returning without a destination. They also let product, design, and development teams confirm boundaries in one diagram.

03 Check at Least Eight States for Every Critical Step

Not every screen needs eight high-fidelity designs, but critical flows need state specifications. Record simple states in component notes; draw separate recovery paths for funds, identity, health, or data submission.

04 Design Interruption Before Designing "Back"

Mobile interruptions are normal. Users answer calls, switch APPs, lock the screen, or copy information, and the system may reclaim the process. Sending users to Home after every recovery loses both their input and trust.

• Short forms can preserve unsubmitted content locally; assess encryption, expiration, and shared-device risk for sensitive information.
• For multistep tasks, record confirmed steps and draft versions, then clearly say "Saved through Step 3" on recovery.
• After reauthentication for an expired session, return users to the original task instead of always sending them Home.
• On return from third-party payment, maps, or identity verification, query the actual state before choosing success, pending, or retry.
• If a deep link opens a child page without prerequisites, complete them and return to the target instead of invalidating the link.
• System Back and in-page Back need consistent rules; confirm only when leaving would lose data.

05 Request Login and Permissions When They Become Necessary

Asking for phone number, location, photos, camera, and notifications immediately after launch drives away users who have not experienced value. Distinguish permissions needed to browse, permissions required for a task, and optional permissions.

Permission copy should not say only "to provide better service." State the specific purpose, whether use is continuous, and how users can complete the task without permission.

06 An Order Flow Needs More Than "Submission Successful"

• The user confirms products and address while the system checks inventory, price, and delivery coverage.
• After creation, the order has a unique state; even without completed payment, users can find it in the order list.
• Prevent repeated taps before opening payment and save the return destination.
• On return from the payment channel, show "Confirming" first; server results determine success or failure.
• If the state is temporarily unknown, users may leave and continue checking on the order page instead of paying again.
• Give separate recovery actions for inventory changes, expired discounts, unsupported addresses, and other failures.
• After success, state the order number, downstream steps, and notification method rather than showing only a celebration illustration.

07 Give Developers Flow Specifications, Not Only a Prototype Link

08 Run at Least These Interruption Tests Before Launch

• Disconnect during submission, then reconnect; confirm no duplicate creation.
• Kill the process halfway through entry, then reopen; confirm draft and step position.
• Send a verification code, background the APP until expiry, then confirm the error and resend path.
• Deny a device permission, enable it in system settings, and confirm the page detects the change.
• Complete payment without returning to the APP, reopen from the home screen, and confirm the order state.
• Open an expired object from an old notification or shared link and confirm the explanation and alternate entry.
• Disable the account or change its role on another device and confirm the open screen revokes capabilities promptly.

Frequently Asked Questions

Should Product or Design Own the Flowchart?

Product usually owns business rules and success criteria; design owns user actions, interface feedback, and recovery; development contributes system states and technical constraints. Complex flows should share one maintained artifact instead of separate diagrams.

Does Every Error State Need a Separate High-Fidelity Design?

No. High-risk states, major business differences, and new components need complete designs. Reusable loading, empty, and network errors can cite component guidelines, but copy, triggers, and actions still need definition.

Is a Shorter Flow Always Better?

Not necessarily. Remove meaningless steps, but deleting confirmations, explanations, and risk warnings increases error cost. Evaluate task completion, comprehension, recovery, and trust—not just screen count.

09 Let Users Return to the Task from Any Branch

A complete APP flow is not one attractive success path; it is a recoverable state network. Users may pause, make mistakes, deny access, or go offline, while the system can still explain what happened, whether data was saved, and what to do next.