The Confirmation Screen Nobody Sees
A confirmation screen that auto-dismisses is designed for the system, not the user. Our MSME users are jewellers and shopkeepers — in the middle of serving a customer when they tap "Reschedule." By the time they look back at the phone, it's gone. Here is what we changed, and why.
01
The problem with confirmations that disappear
Most confirmation screens are designed around the system's perspective: the action succeeded, so show a checkmark and dismiss. Job done. The user is assumed to be watching the screen, waiting for feedback, ready to move on.
Our users are not watching the screen. A jeweller using Collect to reschedule a customer's instalment is also handling a walk-in customer, talking to their staff, or counting cash. They tap the action and look away. The confirmation appears and disappears in three seconds. When they look back, the screen has returned to the list — and they have no idea whether the reschedule happened or not.
The consequence is not minor. A rescheduled instalment that the business owner thinks failed might get rescheduled again — double-action. Or they call the customer to follow up on a payment that was already paused. Or they spend ten minutes cross-checking entries in the app because they are not confident the action went through. All of this is confirmation failure.
02
What the old design did wrong
The original confirmation in Collect was a bottom sheet that appeared, showed a checkmark and the action title — "Reschedule" — and then auto-dismissed after a few seconds. It told the user the action happened. It did not tell them what changed as a result.
This is the most common confirmation design pattern and it fails for the same reason every time: it answers "did the action fire?" but not "what is the new state of the world?" For most actions, the difference doesn't matter much. For a financial action involving a specific customer, a specific amount, and a specific date — it matters a lot.
A business owner who reschedules instalment 3 for Priya Sharma from 6 May to 26 May needs to confirm that specific outcome — not just that something happened. "Reschedule ✓" does not provide that confirmation. It tells the system's story, not the user's.
03
Two changes that fixed it
The redesigned confirmation makes two changes that seem small but address the problem directly.
It waits for the user.The sheet no longer auto-dismisses. It stays on screen until the user taps "Done." This single change means it does not matter if the user is distracted — the confirmation is still there when they look back. The phone holds the state. The user does not have to.
It shows what changed, not just that something changed. Below the success animation, the sheet displays the specific instalment record with its new state — the instalment number, the new date, the amount, the updated status. The user can see exactly what the world looks like now, without going back to the list to verify.
The same pattern applies across every action in Collect — pausing an instalment, rescheduling a payment, marking a collection as received. Each has different data that matters to the user. Each confirmation now surfaces exactly that data.
The "Done" button is not a formality. It is the moment the user acknowledges the new state. It gives them agency over when the confirmation ends — which is the right design when the user's attention is split.
04
The principle behind it
Every confirmation screen answers an implicit question. The question most confirmation screens answer is: "did the system process the action?" The question users actually ask is: "is the thing I wanted to happen, now done?"
These are different questions. The system knows the answer to the first one — it does not need a confirmation screen to tell itself. The user needs the answer to the second one, stated in their terms, showing the specific outcome, persistent until they are ready to move on.
The pattern applies beyond financial apps. Any time an action affects a specific record, a specific person, or a specific amount — the confirmation should reflect that specificity. Generic confirmations ("Success," "Done," "Saved") tell users the system is happy. Specific confirmations tell users what they actually needed to know.
The cost of this change is minimal — a few extra data fields in the confirmation state, a "Done" button instead of an auto-dismiss timer. The payoff is that a user who was serving a customer when they tapped the action can look back at the phone two minutes later and know exactly what happened.