SWMH • 2024

Digital Delivery Book

Replacing paper workflows with a voice-guided tool — for people who never asked for one.

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 this product existed, courier workflows ran on paper books, sticky notes, and memory. Managers couldn't push real-time updates to drivers already on the road — if a delivery address changed, someone had to call. Drivers cycled through dense urban areas under time pressure, switching between tools, managing exceptions on the fly. The system wasn't failing because people were careless. It was failing because the tools hadn't kept up with the actual complexity of the job.
This was also a pre-AI project. Our team was designing voice interaction at a time when no established patterns existed for it. The NLP engineers were building the voice assistant in-house, and I was working alongside them to shape how it actually behaved — translating real courier behavior into prompts that would hold up in noisy, high-pressure environments.

What Field Research Revealed

The product owner built observation rides into the research plan early. I joined couriers on actual shifts — not to observe from a distance, but to do the job alongside them.
Two things came out of that fieldwork that changed the product meaningfully.
The first was about routes. The working assumption — shared by the client and product owner — was that couriers would follow an optimized sequence. What we found was different. Couriers had developed personal systems over time. When someone took over a colleague's route, they'd reorganize it to match how they liked to move. When the original courier returned, they'd change it back. A route wasn't just a list of stops — it was something each driver had quietly made their own. Locking the sequence would have produced a tool that technically worked and felt completely wrong to use. The re-orderable stop list wasn't a feature we added for flexibility. It was the only honest response to what we observed.
The second was about voice. Testing revealed that long prompts caused more distraction than no prompt at all. A courier mid-cycle in traffic doesn't have bandwidth for a sentence — they need a word or two at exactly the right moment. The voice guidance had to confirm what drivers already knew was coming, not instruct them. Once we understood that, we stripped everything back. Brevity wasn't a design preference, it was a functional requirement.

The Work

As the only designer, I was responsible for the full scope: research, information architecture, interface design, prototyping, and testing through implementation. Some decisions were straightforward once the field research was done — dark mode by default because couriers mostly worked at night; map and list views because drivers often parked and delivered several stops in one area. Others required more back and forth with the product owner and developers, questioning assumptions until the solution felt right for everyone.
The design system built for this project was modular enough that it was later reused across other company products.

What Changed

Pilot testing showed fewer navigation and reporting errors and noticeably smoother delivery flow. The more interesting outcome was behavioral: the couriers who had been most skeptical about the app became its strongest advocates once they saw it didn't try to override how they worked — it adapted to it.

Reflections

The observation rides were the most valuable part of the research process, but they happened early and then stopped. Building in a second round of fieldwork mid-project — after the first prototype was in people's hands — would have surfaced friction faster than lab testing did.

Based in Berlin, DE

[contact] [email protected]