Offline is a set of decisions
An “offline mode” label does not explain what someone can actually do. Start by listing the essential field tasks. Which can read previously downloaded information? Which can create a local draft? Which must wait for a server response? These behaviours need to be specified separately.
Give each record a clear state
For a fictional inspection tool, a record might be a local draft, waiting to sync, synced or in conflict. Use plain status messages near the record. Avoid announcing “saved” without explaining whether the record exists only on that device or is available to the rest of the team.
Plan for two edits
Imagine one worker updates a note offline while a manager edits the same record in the office. Quietly keeping the newest timestamp may lose useful work. The brief should name who resolves the conflict and what evidence they need. The eventual developer must assess the appropriate technical strategy.
Treat photographs differently
A text note and a large photograph have different upload costs. A useful requirement might let someone save the observation first and queue its photograph. The interface should show a pending attachment and offer an explicit retry. Do not imply that an upload succeeded when only the text was saved.
Test a broken connection on purpose
A prototype can explore the messages and choices, but cannot prove production reliability. A development test plan should include losing connectivity mid-task, restarting the device and reconnecting after another person has edited a record. Define what the user should see in each case.
Editorial planning guidance. Examples are fictional; implementation decisions require project-specific assessment.
All field notes