Locate the uncertainty in the working day.

Begin with a recurring activity such as preparing a site note, completing a field form, or sending an attachment. Describe where it starts, which device is used, and what the next person needs to receive. Include interruptions that happen during the task, not only the intended sequence.

A team may describe a location as offline even though short periods of connectivity occur. The assessment needs an operational description of the conditions instead of a single label.

Identify what a user believes after each message or screen change. Do they think an edit is on the device, queued for transfer, accepted by the shared system, or visible to a colleague? These beliefs affect whether the person continues, retries, or leaves the task.

Compare that interpretation with the available evidence. A state diagram is useful when it clarifies a decision, rather than simply drawing more boxes around an ambiguous progress indicator.

An interruption may leave a person unsure whether a submission succeeded. Another person may have changed the shared record while a device was disconnected. A local file may still be waiting even though the form data has arrived. Each situation needs a defined response.

The assessment identifies which decisions belong to software behavior, which require a person’s judgment, and which depend on another system. Those boundaries help prevent a research prototype from being asked to answer unrelated questions.

A useful assessment ends with a specific question and a representative scenario. For example: can a user distinguish a saved local edit from a remotely accepted submission after a connection interruption? The next step might be an interface prototype or a controlled synchronization experiment.

The proposal should name the conditions, expected evidence, and unresolved dependencies. It should also identify who can review the operational meaning of the result. A general list of desired features is not a substitute for that research boundary.