Auto-save isn't a feature. It's a safety net.

Design · 5 min read

During testing of an NDIS life management app, we found a problem that had nothing to do with layout, colour, or navigation. People were losing their data. Not because of a bug. Because they got interrupted.

A phone call comes in. The app goes to the background. They come back and the form is blank. Or they leave the screen to check something in another app and when they return, everything they'd entered is gone. For most users, that's annoying. For users with cognitive impairment or attention difficulties, it's a full stop. They can't remember what they'd entered. They don't know how far through they were. They give up.

The fix was obvious. Auto-save everything. Every field, as they type. No save button. No "are you sure you want to leave?" dialog. Just persistence. Whatever you enter stays, no matter what happens next.

Why most apps still rely on manual save

The save button has been a standard pattern since the dawn of software. It made sense when storage was expensive and operations were slow. But on modern mobile devices with fast local storage and reliable cloud sync, there's no technical reason to make users manually save their work.

Google Docs figured this out years ago. You type, it saves. There's no button. There's no "remember to save." It just works. The mental model shifted from "I need to save" to "my work is always saved." That shift reduces cognitive load for everyone, but it's especially critical for users who can't be relied on to remember an extra step.

Research from Nielsen Norman Group on user expectations shows that interruptions break task flow in ways that compound with each additional step required to resume. If the user has to re-enter data after an interruption, the cognitive cost isn't just the time. It's the frustration. And for users who already find forms challenging, frustration leads directly to abandonment.

What auto-save actually looks like

In the app, every form field saves as the user interacts with it. Select a day? Saved. Type a medication name? Saved with each keystroke. Pick a time? Saved. If they leave the app and come back an hour later, everything's exactly where they left it. They can pick up mid-form without any loss.

There's a subtle design element to this. The user needs to know their data is being saved without having to think about it. A small, quiet confirmation — a brief checkmark, a gentle fade — signals that the system has their back. No big "SAVED!" banner. Just a quiet reassurance that nothing's been lost.

The development cost is minimal. Most modern frameworks support this natively. The user experience gain is enormous. It's one of those decisions where the effort-to-impact ratio is completely lopsided in favour of doing it.

This isn't just an accessibility decision

I designed this for users with cognitive challenges. But think about your own experience. How many times have you lost a long email because you accidentally swiped away? How many times have you had to re-fill a form because the browser refreshed? Every user benefits from auto-save. It's just that some users can't function without it.

If your app has forms, input fields, or any kind of multi-step data entry, ask yourself: what happens if the user walks away mid-flow? If the answer is "they lose everything," that's a problem. Not just for accessibility. For everyone.

Designing for people who forget things almost always results in a better experience for people who don't. Auto-save is a perfect example. Build it for the person who gets interrupted. Everyone else benefits for free.

Sources
Response Times: The 3 Important Limits (Nielsen Norman Group) - Research on interruptions and task resumption.
WCAG 2.1 Timing Adjustable (W3C) - Users should not lose data due to time limits.

Related blog posts:

Don't hide things from people who forget things →

Designing for the person who can't read your app →

Case study: NDIS life management app →