Field App User Experience: Keeping Field Records Understandable

We recommend treating field app user experience as a question of what the worker can establish about a record. What job does it belong to? Has it been saved on this device? Has the shared system accepted it? Who needs to act next? Design the screen and the acceptance tests around those questions, rather than treating a completed form as the end of the task.

For this purpose, we use data continuity to mean keeping a record understandable through capture, correction and handover. That is a design goal, not a promise that a clearer interface can prevent data loss. The recommendations below concern the visible workflow and its acceptance criteria, rather than a particular database or synchronisation architecture.

Make the record clear before asking for input

Start each capture screen with the job, location or asset being recorded. Give the worker a way to check that context before entering observations. Where a previous selection carries forward, show it explicitly and make correction possible before submission.

Use labels that describe the information required, including units where relevant. Explain whether a time means the observation time or the entry time. If a photograph needs a particular view, put that instruction beside the capture control. These are proposed design choices to review with the people doing the work.

For web interfaces, WCAG 2.2 requires labels or instructions when content needs user input. That requirement supports providing guidance, but it does not prescribe the business meaning of a field. Agree that meaning with operations and use the same wording in the record view, export and handover screen.

Make validation explain the next action

We recommend keeping valid entries in place when another field needs correction. Identify the affected field, explain what is wrong and offer a useful correction where one is known. Treat a missing observation differently from an unavailable attachment upload, rather than presenting both as an unspecified failure.

For example, a proposed measurement error could say that a positive value in millimetres is required. A proposed upload message should instead explain whether the photograph remains on the device and whether the worker needs to retry. Neither message should claim retention unless the implementation can demonstrate it.

WCAG 2.2 requires automatically detected input errors to identify the affected item and describe the error in text. Its error suggestion criterion also requires known correction suggestions, subject to exceptions for security or the purpose of the content. Use those requirements when reviewing web forms, without presenting a few selected checks as proof of full accessibility conformance.

Distinguish local saving from shared acceptance

Specify what each visible status means before choosing its wording. We suggest separating a local draft, a record waiting to send, a record accepted by the shared system and a record needing attention. These are candidate states for the team to refine, not a universal implementation model.

Reserve a shared completion message for evidence that the agreed acceptance step has happened. If only local saving is confirmed, say so. Show when the status was last checked if that helps the worker judge whether the information is current. An attachment may need its own status if the record and its supporting files can progress separately.

For web content implemented using markup languages, WCAG 2.2 addresses making status messages available to assistive technologies without moving focus. Apply that requirement to the messages in scope. Our additional recommendation is to test the wording against actual save and submission results, including an interrupted response.

Give recovery and handover an owner

Write down what the worker should do when a submission cannot be confirmed. Decide whether retrying is appropriate, what information remains available and how support can identify the record. Do not make a worker choose between deleting uncertain work and creating a second record without guidance.

Ask a supervisor to review the handover view as well as the capture screen. We suggest showing outstanding actions, their owner and the reason a record cannot progress. If a correction is requested, make clear who must supply it and how the worker can see that the request has been resolved.

This is a requirements discussion as much as a screen design exercise. In Software Requirements Essentials, chapter 3, practice 9, Karl Wiegers and Candase Hokanson recommend asking specific availability questions, including whether users should be notified when functionality is unavailable. Use that approach to agree which field tasks may continue and which must wait.

Turn the workflow into acceptance tests

Chapter 6, practice 18 of the same book recommends creating acceptance tests from requirements. We recommend doing that before approving the save and handover wording. Ask a field worker and a tester to walk through the expected record state together.

Include a validation failure with other fields already completed. Interrupt a submission before the result reaches the screen. Close and reopen the application after a confirmed local save. Attempt a handover with an outstanding attachment. For each scenario, specify the visible message, the retained information and the next permitted action.

Keep the expected result explicit. A proposed recovery test might require the reopened record to display the retained observation with a waiting status, rather than a shared completion message. The exact expectation must follow the agreed storage and submission behaviour. Use test evidence to decide whether the wording is justified, rather than using wording to imply behaviour that has not been built.

Begin with one capture and handover journey. Agree the terms, review the failure messages and demonstrate the recovery path before applying the pattern elsewhere. To discuss the requirements and acceptance checks for that journey, let's have a chat.

Update, October 2026

Our engineering article Closing the Loop to Full Autonomy, published on 17 July 2026, describes independent review during a build and a further review of the pull request. For this field workflow, our recommendation is to give a separate reviewer the agreed acceptance scenarios and the observed results, rather than asking them to approve the interface from screenshots alone.

Sources

• W3C, "Web Content Accessibility Guidelines (WCAG) 2.2", 5 October 2023.
• Karl Wiegers and Candase Hokanson, "Software Requirements Essentials", first edition, chapters 3 and 6, Addison-Wesley Professional, 9 March 2023.
• Dendro Logic, "Closing the Loop to Full Autonomy", 17 July 2026. Linked and cited only in the October 2026 update.