/
AccessTrack

AccessTrack: aid distribution that works when the network doesn’t

Field officers hand out aid payments where there is no signal — so the devices verify each other instead of a server.
Web
Android
Offline-first
Humanitarian
Role

Sole Product Designer

Scope

End-to-end · web & offline Android

Scale

Deployed across 80+ countries

Timeline

2022–2023

Team

1 designer · 1 PM · 3 developers · 1 mobile developer

Methods

Stakeholder Interviews · User Flows · Interaction Design · Form Design

AccessTrack — Field officer app mid-distribution, synced over mesh

The field officer app mid-distribution — synced over mesh, no internet in sight.

Overview

An aid-distribution platform for a humanitarian organisation working in 80+ countries. Field officers hand out payments where there is no signal, and headquarters needs to see what happened.

I led the end-to-end design: the web admin for headquarters and country teams, and the offline-first Android app for field officers. Field officers had to hand out sensitive payments securely in zero-connectivity zones, while headquarters needed to see what was actually happening on the ground.

Problem

Fragile systems in zero-connectivity zones.

A major humanitarian organization relied on a fragmented system. Headquarters had no visibility into stock; field officers in remote areas dealt with data loss and fraud risk, because the tools they had simply failed when the internet dropped. And a failed tool here is not a lost form — it is an aid payment that does not reach the person it was meant for, or reaches the same person twice.

Problem image

Two worlds, one broken pipe: what HQ saw vs what the field had.

Research

The research on this project never reached the design side. The decisions below rest on stakeholder sessions and the logic of the workflow, and I say so.

This was one of my first projects, and the evidence underneath it should be stated plainly. What I had was stakeholder meetings: steady access to the people who owned the product, and whatever they knew about the field.

What I knew existed and never saw: the team ran a round of workshops abroad. I was not on that trip and nothing came back from it, no notes, no photos of a wall, no synthesis. I asked for it, and for anything from earlier research, more than once. Nothing arrived. Later, UI feedback started reaching me from someone who sounded like she knew the users, so I asked to meet her. She had been brought in for design review; her expertise was general UX, and she had never met a field officer either.

So the decisions below rest on stakeholder conversations and on the logic of the workflow itself. Where this case says admins were overwhelmed, or that logistics teams could not tell what was where, that reached me second-hand and I had no way to check it.

Key decisions

Resilience first: three decisions that keep the distribution line moving.

Decision 01 · Field

The offline mesh: devices verify each other when no server can

To prevent fraud — double-dipping, the same recipient collecting twice from two officers — devices connect directly over Bluetooth and Wi-Fi Direct, syncing distribution data between officers on the spot. When an officer walks out of range, the app queues the data and rejoins the mesh silently on return. The distribution line never stops for connectivity.

Decision 1 image
Why

Fraud thrives when devices can’t cross-check each other, and connectivity can never be assumed in the field.

Trade-off

Peer verification moves the source of truth off a server and onto a set of devices, and that costs three things I couldn’t design away. Two officers out of range of each other can both record a distribution to the same recipient, so something has to decide which record stands when they rejoin. Keeping the radios scanning drains batteries in exactly the places with nowhere to charge them. And the mesh only runs on hardware that supports it — in the field that means whatever the organisation already owns, not what the design would pick.

Decision 02 · Admin

Single-column forms and bulk onboarding for high-volume entry

Admins were drowning in feature bloat and multi-column forms. Single-column vertical forms restored natural top-to-bottom scanning, and a bulk-action flow onboards an entire country team in one batch — replacing hours of repetitive clicking, one staff member at a time.

Decision 2 image
Why

A multi-column form makes the eye jump sideways and guess what belongs with what. One column gives a single path down the page — one field, one decision, no ambiguity about reading order. On a screen where an admin enters records by the hundred, that ambiguity is where the errors come from.

Trade-off

One column is taller. Every record costs more scrolling than the packed multi-column version did, and less of the form fits on screen at once, so the admin loses the overview of what they’re about to submit. I took the longer form anyway: in high-volume entry, a mis-keyed field costs more than a scroll.

Decision 03 · Logistics

Office stock vs unit stock: where a card is, not just how many exist

Logistics teams could not tell whether stock was sitting in storage or already deployed to the field. A dashboard widget separates office stock (in storage) from unit stock (with field teams), showing the full lifecycle of a card from print request to handover.

Decision 3 image
Why

A single stock total answers “how many exist”. It can’t answer the question logistics actually has, which is “can I run a distribution tomorrow” — a card sitting in storage and a card already in an officer’s bag are the same number and completely different situations.

Trade-off

The lifecycle view is only as true as the handovers logged into it. Splitting one number into stages means someone has to record every movement between them, and a stage nobody updates is worse than the single total was: it looks precise while being wrong.

Outcome

A secured chain of custody, in places where the network cannot be part of the answer.

80+

countries with secure offline distribution

The offline mesh shipped. That is the part I know.

What happened after, I do not know. Fraud incidents, distributions per day, sync success rate: the numbers that would say whether this design held up in the field never reached me. My engagement ended after launch, before those numbers existed, and the organisation carried on without a designer. This case stops where my visibility stopped.

One figure I cut on purpose: 100% adoption of the vertical form standard. Adoption of a standard the organisation mandated internally measures compliance, not whether the design worked.

Outcome image

The chain of custody the system enforces: print request → handover.

Reflection

What I would do differently: put the evidence gap in front of the client instead of absorbing it.

I designed this without ever speaking to a field officer. At the time I read that as normal. I was new, I asked a couple of times, nothing came back, and I got on with the work.

What I would do now is stop absorbing that gap quietly. List which decisions rest on evidence and which rest on someone's account of the field, put that list in front of the client, and ask them to either fund some contact or accept the risk knowingly. That conversation is easier to have than it looks, and it moves the cost of not knowing off my desk and onto the project's.