Design Message Delivery States Honestly
Systems & Architecture · real-time, status, trust
Updated 2026-08-04
- Understand that pressing send does not deliver anything. The message is queued, stored, and then pushed toward a device that may be offline, so every step deserves its own state rather than one checkmark.
- Separate the states people actually care about:
- Sending, still on this device.
- Sent, accepted by the service.
- Delivered, present on the recipient's device.
- Read, opened by the recipient.
- Failed, and here is the retry.
- Show the message immediately in the thread and mark its progress in place. Blocking the input until the round trip completes makes a fast product feel slow on a slow network.
- Never show delivered when you only know sent. A confirmation the system cannot actually verify is the one that destroys trust in every other indicator.
- Accept that the last acknowledgement can always be lost. The sender can never be certain the recipient received it, which is exactly why the states are approximate and the copy should not overstate them.
- Preserve order when messages are retried. A failed message that silently jumps to the bottom of the thread when it succeeds rewrites a conversation.
- Make failure recoverable without retyping. A failed message must stay in the thread, keep its text, and offer a retry in place.
- Treat read receipts as a privacy setting, not a feature. Both sides need to know whether it is on, and the indicator has to be honest when it is off.
Delivery is a chain of separate systems, and the interface earns trust by showing exactly how far along the chain a message has actually got.
Related guides
UX Handbook