Process prototype
One device, three roles, one signature
A paper handling process where a tablet passes from a ground agent to a flight captain and back. I prototyped the handover itself, because that is the moment the process either works or does not.
- Agent on a phone, crew on a tablet, office on a desktop
- 3 rolesAgent on a phone, crew on a tablet, office on a desktop
- The device changing hands prototyped as the central moment
- The handoverThe device changing hands prototyped as the central moment
- Because the apron is where connectivity fails
- Offline simulatedBecause the apron is where connectivity fails
The client
A European flag-carrier airline replacing a paper ground-handling process — extra services agreed at the aircraft, signed off by the crew, then reconciled and approved by a back-office team.
The engagement
A high-fidelity clickable prototype covering three roles on three form factors, with offline behaviour simulated and no real authentication in the way.
A working demo of this build exists.
It is not public yet — ask for access, and where the NDA allows I will send a link or walk you through it on a call.
The problem
Ground handling looks like a form and behaves like a relay. A ground agent agrees extra services at the aircraft, a captain signs for them, and a back-office team turns that into money — three roles, three devices, and one physical handover in the middle, usually outdoors, frequently without a signal. Prototyping the screens without prototyping the handover produces a demo that everyone approves and nobody can use.
What I did
I built the seam. The prototype carries all three roles and lets you walk the device from one to the next, so the room can see what the crew member sees when the tablet arrives and what state the agent gets back afterwards. The captain's signature is treated as the moment of record rather than as a form field, because that is where an informal agreement becomes a billable fact. State persists locally and offline is simulated, since the apron is precisely where connectivity is unreliable and a design that assumes a connection will fail on its first real shift. Login was replaced by role selection deliberately — a demo that stalls on authentication wastes the only ten minutes you get. And while building it I kept a running list of discrepancies between the described process and what the screens actually required, which became its own deliverable.
What was built
Three role journeys in one prototype — the ground agent on a phone selecting a flight and adding extra handling, the crew on a tablet reviewing services, entering an identifier and signing, and the back office on a desktop reviewing reports and approving or rejecting — with state persisted locally, offline simulated, and role selection replacing login so a demo never stalls on a password.
On the table at the end
- Clickable prototype across three roles and three form factors
- Captain signature capture and confirmation flow
- Back-office approval and rejection flow with reports
- Internal notes on demo gaps, quick wins and discrepancies found while building
What it changed
Made the risky part of the process visible before anyone specified it: the physical handover of a device between two people with different roles, different screens and different accountability — and the captain's signature that turns an agreement into a billable record.
How it ran
- 01
Prototype the seam, not the screens
The device physically changing hands between agent and crew built as the central interaction.
- 02
Treat the signature as the record
The captain's signature designed as the point where an agreement becomes billable, not as a form field.
- 03
Assume no signal
Local persistence and simulated offline, because the apron is where connectivity fails.
- 04
Remove the login
Role selection instead of authentication, so a ten-minute demo is never lost to a password.
- 05
Log the discrepancies
Gaps between the described process and what the screens actually needed captured as a deliverable rather than resolved silently.
Other work
All case studies →- Food manufacturing
Clipboard rounds into work orders
Utility readings taken on paper, typed in later, and analysed never. I prototyped the whole chain — the technician's round, the alert, the trend, and the write-back into the maintenance system.
- Healthcare services
The demo that admitted its AI was a rulebook
A treatment-acceptance flow where the assistant suggests answers to a patient's objections. The suggestions came from rules, not a model — and saying so made the demo stronger, not weaker.
- Industrial operations
A command centre demo that ends in a work order
Operations people do not buy dashboards, they buy what happens after the dashboard. I built the demo so every insight terminates in the maintenance system, in the client's own brand.
Something similar on your plate?
Thirty minutes, no deck. I will tell you whether it is worth doing at all.