SWMH • 2024

Digital Delivery Book

Replacing paper, sticky notes, and memory with a voice-guided tool. Designed before AI made voice interaction feel familiar.

Scope

B2B tool
Pre-AI era voice-guided workflows

Team

CTO & Product owner
Project Manager
Android developers (2)
NLP Engineers (2)
UX/UI Designer (me)

Responsibilities

UX/UI research and field studies
Core UX/UI design
Design direction and prototyping
User testing

The Situation

Before our work, couriers ran their days on paper books, sticky notes, and memory. The system was held together by individual skill and tolerance for error, both of which have limits. Last-minute changes — new deliveries, address corrections, schedule shifts — could only reach drivers by phone, often while they were already in motion. Mistakes accumulated. So did stress.

The brief was to digitize the workflow without breaking what worked. Couriers knew their routes. Managers knew the changes. The question was how to connect them in real time without burying drivers in screens while they were cycling through dense urban areas at speed.

The Hard Part

Two things made this harder than a typical workflow tool. First: voice. The team was building an in-house voice assistant before LLMs had made conversational interfaces feel obvious. There were no patterns to borrow from. We had to figure out from first principles what "natural" sounded like in a noisy van at night, when a driver's hands were full and their attention was on traffic.

Second: resistance. The couriers who would be using this tool hadn't asked for it. Years of paper had produced workflows that worked, more or less, and the people doing the work were skeptical that anything new would actually help. Trust had to be earned, not assumed.

I spent time on observation rides — riding along on routes, watching where the friction actually was. The interview-and-workshop version of this research would have given us a different and weaker product. Most of the decisions that mattered came from those rides.

What the Work Produced

A few decisions defined the product:

Dark mode by default. Most couriers worked at night. The interface had to follow them, not fight them.
Re-orderable stops. Paper routes were fixed in print. Couriers knew their areas better than the routing software did. Letting them adapt the sequence respected that.
Map and list views. Many drivers parked once and walked multiple deliveries. List view supported that workflow without forcing a return to map mode.
Digital and voice notes. Paper notes were often unreadable or lost. Quick voice annotations meant local knowledge stayed with the stop, not the driver's memory.
Live issue reporting. Broken elevators, blocked entrances, missing door numbers — couriers could log them instantly, creating a real-time picture for managers.
Short voice prompts, timed to motion. Brevity mattered more than tone. Prompts had to match the rhythm of movement, not interrupt it.

Testing confirmed something we'd suspected: couriers didn't want a friendlier voice. They wanted a faster one.

Reflections

Three things stayed with me from this project.

The first: if you can experience the work yourself, do it. Delivering packages firsthand exposed friction that no interview surfaced. It made me a more accurate decision-maker downstream.

The second: invite challenge. The strongest decisions came from uncomfortable ping-pong between me, the product owner, and the developers. We questioned every assumption until the answer felt right for everyone in the room.

The third: resistance often becomes ownership, if the tool actually works. The same couriers who initially refused to try the app embraced it once it made their days smoother. That reminded me that adoption isn't about persuasion — it's about being right enough that the proof speaks for itself.

Based in Berlin, DE

[contact] [email protected]