Field work, offline-first.

Field teams inspect, repair, and record work in basements, rural sites, and plant rooms. Connectivity is the exception, so tools that assume it push people back to paper.

This study designs a mobile app where the device is the primary workspace. Jobs, forms, and photos live locally, and synchronization is a background concern with clear status.

How can technicians complete and record a full job with no connection, while the office still gets accurate, timely information?

Offline support cannot be a cache bolted onto an online app. Data ownership, conflict handling, and media uploads have to be part of the core design.

• Long offline periods

  A technician may work a full day without a usable connection.

• Shared records

  Dispatchers can change a job while the technician is working on it offline.

• Large media

  Photos and attachments must upload reliably over weak connections, without blocking other work.

• Mixed devices

  Company and personal devices across iOS and Android, with varying storage.

WHAT DISCOVERY WOULD ESTABLISH

1. 01

   Ride-alongs

   Observe real jobs to understand connectivity, gloves, glare, and time pressure.

2. 02

   Data ownership map

   Decide which fields the technician owns, which the office owns, and which both can change.

3. 03

   Form inventory

   Catalog current paper forms and checklists, and the rules behind them.

4. 04

   Backend integration review

   Understand the scheduling and records systems the app must sync with.

The app stores assigned jobs, forms, and reference data locally. Every change is written to a local outbox and synced in order when a connection is available.

Field-level ownership rules resolve most conflicts automatically. When both sides change the same field, the app shows the conflict to a person rather than choosing silently.

CAPABILITIES

• Full offline job completion
• Local outbox with ordered sync
• Field-level conflict rules
• Resumable photo uploads
• Clear sync status on every record
• Dispatch view for the office

1. DECISION 01

   Sync status is always visible

   WHY

   Technicians need to know whether the office has their work before leaving a site.

   TRADE-OFF

   Adds interface states that must be designed and tested.

2. DECISION 02

   Large touch targets, few typed fields

   WHY

   Gloves, glare, and time pressure make typing slow and error-prone.

   TRADE-OFF

   Forms need more design effort to keep structured data without free text.

3. DECISION 03

   Conflicts go to a person

   WHY

   Silent overwrites destroy trust in field records.

   TRADE-OFF

   Some conflicts need dispatcher time to resolve.

The device is the source of truth for in-progress work. A delta sync API exchanges changes in both directions, with ownership rules deciding conflicts and media handled on a separate, resumable path.

1. L1

   Device

   Where the technician completes work, entirely offline if needed.

   • Job list
   • Forms & checklists
   • Photo capture
2. L2

   Local data

   Durable local storage and an ordered record of pending changes.

   • SQLite store
   • Outbox queue
   • Media cache
3. L3

   Sync

   Exchanges deltas both ways and applies ownership rules.

   • Delta sync API
   • Conflict rules
   • Resumable uploads
4. L4

   Backend

   Holds the shared record and integrates with existing systems.

   • Jobs service
   • Scheduling integration
   • Media storage
5. L5

   Back office

   Where dispatchers assign work and review conflicts.

   • Dispatch view
   • Conflict review

DESIGN PRINCIPLES

1. Outbox, not requests

   Changes are recorded locally and replayed in order, so nothing depends on being online at the moment of action.

2. Ownership per field

   Most conflicts are resolved by who owns the field, without user involvement.

3. Media on its own path

   Uploads resume after interruption and never block form data from syncing.

PROPOSED DELIVERY SEQUENCE

1. PHASE 01

   Sync protocol first

   Define record versions, ownership, and the outbox before building screens.

2. PHASE 02

   One job type

   Deliver the most common job end to end, including offline completion and sync.

3. PHASE 03

   Field pilot

   A small group uses the app on real jobs, with paper as a fallback.

4. PHASE 04

   Remaining forms

   Migrate further forms once the core flow is proven in the field.

1. Network condition tests

   Automated runs with no network, high latency, and connections that drop mid-sync.

2. Conflict scenarios

   Concurrent office and field edits for each ownership rule.

3. Device matrix

   Supported OS versions and low-storage devices, on real hardware.

4. Upgrade paths

   App updates with pending, unsynced changes must never lose data.

1. Release channels

   Staged rollout through app store tracks, with the ability to pause a release.

2. Remote configuration

   Feature flags to enable new forms without a full app release.

3. Sync monitoring

   Track sync failures, outbox age, and upload retries per app version.

1. CHALLENGE 01

   Changes made on both sides while offline.

   RESPONSE

   Field-level ownership resolves most cases; the rest are shown for review with both versions.

2. CHALLENGE 02

   App updates during pending sync.

   RESPONSE

   Local schema migrations are tested against outboxes containing every change type.

3. CHALLENGE 03

   Photos over weak connections.

   RESPONSE

   Chunked, resumable uploads with a separate queue and clear per-photo status.

This is a concept, so there are no measured results. The outcomes below are what the design is intended to achieve; the measures after them are how a pilot would verify it against an agreed baseline.

INTENDED RESULTS · QUALITATIVE

• Technicians can finish and record a job without waiting for a signal.
• The office sees work as soon as a connection allows, without re-keying.
• Conflicting edits are surfaced and resolved deliberately, not lost.

HOW RESULTS WOULD BE VERIFIED

• Time from job completion to an accurate office record, against the current baseline.
• Re-entry and correction effort before and after the pilot.
• Sync failure and conflict rates by app version.

1. 01

   Offline is an architecture

   It shapes the data model, sync protocol, and interface, so it has to be decided first.

2. 02

   Observe in the field

   Gloves, glare, and pressure change interface decisions more than any workshop.

3. 03

   Make sync visible

   A clear status removes the anxiety that drives people back to paper.