What an interrupted task should tell you

If a device stops halfway through a task, 'Try again' isn't enough.

Imagine pressing Start and coming back to a device that has gone silent. You can't tell how much it finished, or whether starting again will repeat work it has already done.

For v/h, recovering from an interruption belongs in the design from the start. The owner should be able to tell:

• What finished.
• What still needs attention.
• What will happen if they try again.

The agent inside should check the current state before repeating an action. It needs evidence of the result before the product marks a task complete. When it can't verify what happened, the product should explain the uncertainty and give the owner a clear next step.

A simple control is only part of a simple experience. We also want someone to understand what to do after an interrupted job, without having to diagnose the software inside.

We're treating recovery as a design requirement while developing our first everyday utility.

What's an error message on a device you own that still leaves you unsure what to do next?