05 / MULTI-DEVICE CONTINUITY
Pick up the thread.
On another screen.
Plan for the way clients move between a short mobile visit and a more involved desktop task.
Separate orientation from detailed work
A client might notice a request on a phone and respond later from a laptop. Both visits should be useful, even if they support different levels of attention. A small screen needs the reason for the request, its current state, and a clear next step before secondary detail.
Responsive work is not simply shrinking a desktop layout. A long document table may become a labeled list. A side-by-side comparison may become a sequence with persistent revision labels. The relationship between the pieces must remain understandable when they no longer fit together visually.
Explain what is saved
A visible draft can create a strong expectation that progress will survive a closed tab or a change of device. That promise must match the implementation. Browser-only storage, a signed-in server draft, and an unsent input field are different things.
A project should specify the save point and the feedback around it. “Saved to this device” and “Saved to your account” communicate different boundaries. If a connection fails, the interface needs to say what remains available and what must be submitted again.
Make the return state legible
When a client returns, the system can show the last completed step, the remaining request, and changes made by the team in the meantime. It should not quietly replace the client’s working assumptions with new instructions. A clear update notice can prevent a response to an obsolete request.
Resuming may also involve an expired session or a changed document. The recovery path should protect the user’s work where possible and identify any part that requires review. A return journey deserves the same design attention as a first visit.
Check real constraints
A useful test set includes touch input, keyboard operation, zoomed text, narrow screens, slower connections, and interrupted visits. Documents and embedded services may introduce their own constraints; those dependencies need to be assessed rather than assumed to follow the surrounding layout.
Potential outputs include responsive components, a cross-device journey, explicit draft behavior, and a test checklist for the agreed browsers. Universal compatibility is not a credible promise. The scope should name supported environments and a usable fallback for important tasks outside them.