Interruption and recovery
If interruption is the normal condition rather than the exception, then task resumption is a first-class design problem, and it is one that very little standard interface guidance addresses directly.
The moment of the pull-away
When someone is drawn away mid-screen, three things are at risk: the data they have entered but not committed, the place they had reached, and the reason they were there. Most systems protect the first reasonably well, protect the second by accident, and make no attempt at the third.
The third is the expensive one. Re-establishing intent takes longer than re-finding a position, and it is the part a person cannot recover from the screen because the screen never held it.
Saving state without pretending to
Automatic saving of in-progress work is now expected, and the design question has moved to how it is communicated. A draft that is saved silently is a draft the person does not know they have; a draft that announces itself constantly becomes noise.
A modest, persistent indication - when it was last saved, and where the draft can be found - is usually enough. What should be avoided is ambiguity about whether something was committed or merely held, since a person who is unsure will re-enter the work, and duplicate entries are worse than lost ones.
Re-entry cues
The screen a person returns to should tell them where they were. Retaining scroll position helps. Retaining and visibly marking the last edited field helps more, because it answers where I was rather than merely restoring what was on screen.
Better still is a short trace of what has been done: which sections are complete, which are untouched, and what remains. A checklist is unfashionable and it happens to be the structure that survives interruption best, because it holds the state that the person would otherwise have to hold themselves.
Where you were and where you are
A subtle failure is the screen that has changed underneath the person while they were away. New data has arrived, a filter has reset, a session has refreshed, and the view is now correct but unfamiliar. The person resumes against an assumption that is quietly no longer true.
Changes that occur during an absence should be marked as changes rather than absorbed silently. Showing that three things arrived since the screen was left is a small amount of text that prevents a whole class of confident errors.
Shared and shift-based screens
Many of these surfaces are not used by one person in one sitting. They are handed over, shared and resumed by someone else, which makes the resumption problem a communication problem as well.
The design implication is that state should be legible to a stranger, not just to the person who created it. If the only way to know what is going on is to have been there, the screen has made the handover harder than the paper it replaced.