Remember the work, not just the user

Most products know who someone is. They remember their account, plan, settings, and enough profile detail to welcome them back by name.

Then those same people start doing actual work.

They get five steps into an application or approval flow. Each step has multiple things to fill in, upload, choose, check, or confirm and then they need to stop because a document is needed, a decision from someone else is required, or just they wanted more time.

So the tab closes, the session expires, the device changes, the page refreshes, or life gets in the way.

And when they come back, it cheerfully says:

Welcome back, Adam.

But that thing that they were working on? Gone...

That's the gap here. Remembering identity has got pretty good, but intent is often much harder. What were they trying to finish?

Remembering identity is not the same as remembering intent.

And at the moment someone comes back to finish something, the intent is usually the more important part of whatever they were doing.

Remembers you, starts over

You are halfway through something. You leave to find a document, ask someone a question, or just come back the next day. It calmly says:

No saved progress found

😑 sigh... It knows enough to greet you, but not enough to help you keep going. It remembers identity, then throws away the work.

Remembers the work, lets you resume

A better version is the return you were hoping for. It shows what is already done, what still needs attention, and where to continue, so you don't have to rebuild the whole job in your head.

Know what work looks like

The bigger question is: what has the user invested that should be protected?

Autosave protects one obvious kind of lost work. That might be text they have written, a setup they nearly finished, a report they narrowed, or a search that failed but still shows what they were trying to find.

Some of that work is obvious because it looks like a document: a draft email or a support reply.

But a lot of that work does not look like a document. It looks like little choices the user made while narrowing, configuring, comparing, or trying to get unstuck.

It looks like narrowing a report to failed payments, mapping one CSV column, choosing a comparison shortlist, or searching for something specific and getting no useful result.

Those choices are work. They might not deserve a giant saved state, but they deserve an explicit decision.

Most teams do not make that decision directly enough. You usually end up with a default: everything gets forgotten because nobody chose what should survive, or a random pile of state gets saved because the browser, framework, or previous team left it there.

Neither is much of a decision. Forgetting wastes effort. Saving the wrong thing can feel confusing, stale, risky, or creepy.

So the job is not "remember more", it's to work out what kind of work the user has done, and what they should get when they come back.

It's not to make the product feel clever. It's that the user does not have to rebuild the whole mental model from memory. If the connection drops, the page crashes, the device changes, or they simply run out of time, they can trust that the point they reached still exists.

But this isn't just a storage problem. Most teams can store a draft, keep a query string, preserve some local state, or throw the last screen back at the user.

That is not the hard part.

The real decision is what that saved work means when the user returns:

• Is it still valid?
• Is it private?
• Should it follow them across devices?
• Should the team know it exists?
• Should it expire?
• Should the user be able to clear it and start again?

Autosave can preserve the contents, but it does not, by itself, design the return.

The goal isn't to feel psychic. It's to be useful when the user comes back.

The same problem shows up in smaller flows

You can see the same mechanics in a normal integration setup.

Someone chooses a provider -> connects the account -> picks which events should sync -> runs a test, then stops because they need a production credential or someone else has to approve the next step.

None of that is finished, but it is still work.

If they come back tomorrow and it says:

Connect integration

that's technically a start point, but it's a bad memory.

The better version is closer to:

Continue integration setup

with just enough detail to make the work recognisable:

• provider selected
• account connected
• test sync failed
• production credential still needed

That copy matters because it changes the return. The user doesn't have to rebuild the mental model, remember which parts already counted, or wonder whether the previous attempt disappeared.

Useful memory is the unfinished job around the saved state: where the user got to, what is blocked, and what should happen when they return.

That distinction matters because "state" can mean anything.

A checkbox, a query string, a cookie, a stale filter, an old modal, a bad default.

Some of that is useful memory. Some of it is leftovers.

That's the work: knowing the difference.

Some memory is a trap

Obviously, not all memory is helpful.

Sometimes remembering the last thing makes things much worse. For example:

• A dashboard opens with a narrow filter from last week and everyone thinks the numbers are broken.
• A checkout remembers an old delivery address.
• A search page keeps a query that made sense yesterday but now hides the useful results.

You see the same thing in softer ways too. For example:

• An onboarding flow pushes someone back into a path they deliberately left.
• A shared device remembers private work in a way that feels grim.

Memory needs rules: scope, expiry, visibility, and control. Some work should follow the user across devices. Some should stay on one device. Some should be cleared because it would be stale or unsafe. Some should ask the user.

That is the bit product teams need to own. Not only whether the data can be stored, but whether remembering it will help the next version of the user's work.

Four questions for work memory

So what I'd do is pick one important flow and ask four questions about the work inside it.

Not account data but the work.

If something meaningful is remembered, the return screen should change to show it.

These questions are useful because they stop the team having the wrong argument.

The argument is not whether we can store this. It's whether this work should survive, and what should happen when the user comes back.

That's a decision before it's an engineering detail. You might decide the answer is no. Good. There are plenty of things worth forgetting. But forgetting should be a decision too.

What to do next

Pick one flow where a user does meaningful work before the final submit/save/done moment.

Run the four questions before deciding what should survive.

The point is not to save everything but to stop treating the login as the only thing worth remembering.

Your product can know exactly who someone is and still feel stupid when they come back.

Because the useful question is not only, who are you? but what were you trying to finish?