Designing for Return

I’ve been thinking about recovery differently.

Usually, when we talk about recovery in technology, we mean restoring a system.

Restart the device. Restore the data. Reconnect the service. Get everything working again.

But what about the person?

I’ve been experimenting with a small system that persists just enough context to help me answer a simple question when I return:

Where was I?

That question has turned out to be more interesting than I expected.

We leave contexts constantly.

A conversation interrupts another task. A meeting ends. We switch devices. Something urgent takes over. We put the work down overnight and encounter it again tomorrow.

Most of our tools are quite good while we’re present.

The tool began by recovering the machine. Working on it made me wonder what it would mean to recover the human context too.

Returning is different.

We reopen tabs. Reread messages. Search through notes. Reconstruct decisions. Try to remember which of the dozen things in front of us actually mattered.

In other words, we rebuild our orientation.

That has me wondering whether continuity has been framed too much as a problem of preserving everything.

Perhaps continuity requires something smaller:

Preserve enough to recover your bearings.

What that “enough” consists of will vary. A decision. A question. A next action. A small amount of context. Something deliberately left unresolved.

The design challenge isn’t simply deciding what a system should remember.

It’s deciding what a person will need in order to return.

I’ve been calling the broader territory orientation architecture: designing conditions that preserve our ability to understand where we are and choose what comes next.

Designing for return feels like one expression of it.

Because resilience isn’t only about whether our systems can recover.

Sometimes it’s about whether we can recover ourselves within them.