KIRFU 1.0 · Driver app · iOS & Android
Drivers plan multi-stop routes by hand, then drive with a phone competing for their attention. I designed and shipped KIRFU 1.0: import or enter your stops, get an optimised route, and navigate with minimal screen time.
Overview
Founding Product Designer
7 months
CEO, CTO, Engineering, Marketing.
Research · Interaction design · Prototyping · Handoff
Launched as a beta with 300+ downloads across the App Store and Google Play by the time I left. Tested with 3 users.
The problem
Planning is a chore. Driving is hard enough.
Drivers with multiple stops usually use their native app for route planning and optimisation. Then they drive, with traffic, parcels and deadlines all competing for attention.
How might we help drivers turn a list of stops into an efficient route fast, and keep their eyes on the road once they start?
Research
Learning from the road
I interviewed 10 delivery drivers working for Amazon Flex and Evri. Then I rode along with the same drivers to see where their tools slowed them down.
Navigation was the heaviest load
Routes, traffic, parcels and deadlines, all at once.
Drivers wanted control
They wanted to decide how their stops were ordered.
They expected polish
Their benchmark was the consumer apps they use daily.
Drivers found their delivery app hard to navigate, and sometimes switched to Apple Maps instead.
Ride-along observation, paraphrased
Design principles
Reduce cognitive load. Show only what the current task needs.
Disclose progressively. Reveal complexity gradually.
Design for speed. Clear hierarchy, concise interactions.
Context over complexity. The right information at the right moment.
Decision 1: Getting stops in
Challenge
Stops arrive as spreadsheets, platform lists or typed addresses. Messy data meant failed routes and wasted time.
What I did
I designed two ways in, bulk import and manual entry. After a bulk import, an import summary gives every row a clear status:
Ready · Needs confirmation · Suggested correction · Duplicate · Missing information · Not found · Skipped
From the summary, drivers can review issues, route the valid stops, remove invalid rows, export an error report or retry the import.
Each problem row opens an inline editor showing the original text, a standardised address, a map preview with a draggable pin, search, unit and notes fields, and a save-and-confirm action. Drivers fix errors without leaving the screen or restarting the route.
Why It Matters
If the first step fails, nothing after it matters.
Entry point- two ways to proceed
Import in progress
Manual entry of stops
Import summary with errors - Every row has a status.
Inline editor on a problem row
Optimised route review
Decision 2: Navigation for someone who's driving
Challenge
Show critical information without overloading a driver who's already juggling the road.
What I did
I built the screen around a clear hierarchy. Directions, ETA, speed and live traffic updates stay in view. The full stop list and delivery progress sit one drag up, revealed only when needed.
Why It Matters
The goal wasn't more on screen. It was fewer distractions.
Live navigation - Only what a driver needs right now.
Turn-by-turn directions, live traffic, ETA and the next stop, all in one view.
Stop list dragged up - view and track all stops
Rejected earlier version - messy UI make drivers hard to understand the page
Decision 3: A voice assistant that earns its place
Challenge
Drivers need timely information without looking at the screen.
What I did
I scoped NEMO to hands-free navigation tasks instead of the whole app. It could read out the next stop, announce upcoming turns, answer "what's next?", mark a stop complete, pause or resume navigation, add a quick note, handle a simple skip and replan, and report basic offline status.
I designed the conversation flows, states and error recovery, including this edge case. If a driver says "Done" and NEMO can't tell whether they mean "mark this stop complete", it asks before acting:
"Do you want me to mark the current stop as complete?"
If yes: "Stop marked complete. Next stop is 14 Green Road."
If no, or no reply: "Okay, I haven't changed the route."
Why It Matters
When a voice command is ambiguous, a wrong action costs a driver more than one extra question. AI features tempt you to do everything. The better call is knowing where an assistant earns its place.
NEMO's entry point on the navigation screen- upon voice command
Idle
NEMO is ready when you need it.
Listening
NEMO is hearing your request.
Speaking
NEMO is responding to your request.
Error or unsure
NEMO couldn't understand and asks for clarification.
NEMO states
The "Done" confirmation flow - When NEMO isn't sure, it asks before making changes.
Testing and results
What the beta showed
KIRFU 1.0 reached 300+ downloads across the App Store and Google Play while I was there. I left before retention data was mature enough to draw conclusions, so I tested the beta qualitatively with 3 users.
What worked
They found the app easy to understand, simple and straight to the point. NEMO was seen as a comfortable add-on.
What caused friction
NEMO was a new way of working, so it took time to trust. Bulk importing addresses and resolving errors was also slow.
Early, directional evidence from a small sample, not proof.
Where KIRFU was heading
Concept prototype · not shipped
KIRFU's longer-term vision was a multi-provider marketplace: drivers accept shifts across logistics companies in one app, and companies manage them from a dashboard. 1.0 was the route-planning foundation.
shift-discovery cards
r UI crops showing states: idle, listening, speaking, error
6/8
Drivers completed the key shift-to-delivery workflow independently.
5/8
Drivers preferred voice assistance during the navigation experience.
2/8
Drivers experienced friction during onboarding.
What I'd do differently
Test onboarding earlier. I found the friction late. Next time I'd test low-fidelity onboarding before building the full flow.
Make import errors faster to fix. Beta users found resolving them slow. I'd explore batch fixes for similar errors, such as accepting all suggested corrections at once.
Treat the design system as a deliverable. I built it from day one, but documentation lagged and cost engineering time. I'd document as I build.