Feedback states

Every action that takes time has the same few states, and most apps only design the happy one. Your job is to take one feature, find every state it can be in, and make each one clear: what the user sees, how it moves, what they feel, and what it says. The 60fps library supplies real references.

Work on one feature or screen at a time: a save, a send, a purchase, a search, or how one screen loads its data. If the user did not name one, ask which. Do not change code until step 5.

1. Map the triggers and the states from the code

Read the feature's view and the code that does the work (the view model, the async function, the network call), plus any shared loading, error or freshness views and modifiers the app already has.

First list what starts the work, and every place it can start from (a button and a cell can both add the same thing, and two entry points are how races happen). A user action (a tap on Save) is one trigger. A screen load often has several: opening the screen, coming back to the app, a timer, changing a filter, pull to refresh, a Refresh or Try again button. Feedback differs by trigger, so keep them apart.