01 / Supervisor — Creates the campaign, imports the list, assigns distributors.
Arabic-First · Android · Shipped
Proof of Delivery
An Android app for humanitarian aid distribution, built with Tadamoun and used in the field in Sudan — where connectivity can't be assumed and a duplicate collection means someone else goes without.
Download on Google Play
01 — The Problem
A hundred names on one sheet of paper.
Distribution day. People have queued since morning in the heat, and the supervisor holds a paper list of a hundred names — scanning the page by hand every time someone reaches the front. That day some people collected twice, not through dishonesty but because there was no fast way to check. Someone genuinely eligible wasn't found where the supervisor expected, and waited two hours. The problem in aid distribution usually isn't a shortage of aid. It's that nobody can say quickly who has already received.
02 — Roles
Three people, three different jobs.
A supervisor sets up the campaign and imports the list. A distributor works the queue — sending, verifying, recording. A viewer follows progress without touching anything. Building three permission sets rather than one shared interface kept the distributor's screen narrow and fast, which is what matters with forty people waiting.
02 / Distributor — Works the queue. Sends, verifies, records.
03 / Viewer — Follows progress. Changes nothing.
03 — Offline First
The connection is not something you can assume.
Connectivity in these locations is intermittent at best, and a product that needs a signal to confirm a collection stops working on the day it matters most. Everything runs locally after first login — actions queue on the device and sync when a connection returns. That constraint shaped the interface too: components had to communicate state on their own, without a server to confirm anything.
Offline state
Queued locally first, synced when the signal returns.
04 — Accountability
Every confirmation has a name behind it.
Aid distribution is answerable to donors, so it isn't enough for a collection to be recorded — it has to be attributable. Distributors sign in as themselves and are assigned to specific campaigns, which means every confirmation carries who made it and when. The supervisor sees the campaign totals move in real time rather than reconciling paper at the end of the day, and the record that reaches the donor is built as the distribution happens rather than reconstructed afterwards.
01 / Sign in — Every action is tied to a named person.
02 / Assign — Distributors are given specific campaigns, not blanket access.
03 / Oversee — Totals update as collections happen, not after.
05 — Design System
A system that has to hold under pressure.
The system is built around Arabic first — a five-step type ramp, semantic colour tokens rather than descriptive ones, and a documented button sequence for the confirmation flow so the irreversible action always behaves the same way. Authorization codes get their own treatment: Latin characters, letterspaced, so a code reads as a code inside an Arabic interface rather than as text.
01 / Colour Named by meaning, not appearance.
02 / Type Five steps, Arabic-first, with a dedicated code style.
03 / Button Primary, confirm, done. The sequence is documented, not improvised.
06 — Reflection
Constraints that couldn't move.
Most product constraints are negotiable — a deadline shifts, a scope shrinks. None of these were. No signal, no undo, no time to learn an interface. Almost everything I considered adding failed the same test: does it still work in the sun, offline, with forty people waiting. Very little survived that, and what did is the app.