Sherpa
10 years in-house, responsible for all design
Sherpa is an Australian platform connecting businesses with on-demand drivers for same-day delivery.
I was design lead, and for most of it, the only designer, so design across the product, marketing, sales, all of it sat with me. This is one of countless features released to the Sherpa Driver app.
Up next: Problem
The problem
Agents couldn't tell which job a driver was on
Tracking agents spent hours each day chasing drivers for ETAs by SMS and phone on late or uncertain deliveries. It was slow, and often fruitless.
→
Unreliable location: With no in-app navigation, location only updated reliably while the app was open in the foreground. Not knowing if drivers were following the suggested route, forgotten status updates and patchy signal added to it.
→
ETAs we couldn't trust: We could estimate one from the last known location and the next stop, but there was too much variability to rely on it.
→
Drivers couldn't always reply: Mid-pickup or mid-delivery, they couldn't always stop to answer a call or text, so replies were slow when they came at all.
Objectives
What we were solving for
We were shipping a first version, but we kept the end goal in view throughout: ETA requests that are automated, or not needed at all because location and driver data was reliable enough.
Cut the chasing
Fewer ETA-related SMS and phone calls, saving operational time and costs. Freeing agents for tasks less suited to automation.
Aim to remove requests entirely
Or automate where that isn't possible. This was the longer-term goal, and it shaped every decision.
Keep the watchlist focused
The agent dashboard should show genuinely urgent deliveries only, and clear jobs faster once a response or status update comes in.
Up next: Approach
Ideation
I explored two ways to solve it
I mapped how the feature would sit in the existing delivery flow before adding anything new. Full in-app maps would have fixed several problems at once, but needed investment the business wasn't ready to make. So we built on the data and behaviour we already had, guided by three principles.
→
Timing-conscious: Drivers reply when it's safe, never mid-drive.
→
Smart triggers: Existing location and job data decides when a prompt is worth sending — never unnecessarily.
→
Automatic visibility: Responses update logs and watchlists with no manual entry.
Path A
Job-level
Drivers tap a job to say they're heading there next. It moves to the top of their route and the route regenerates around it, so the system knows which job they're on. Drivers choose whether the tap opens their preferred maps app or keeps them in-app, for anyone navigating on a separate device.
Path B
Route-level
Drivers often didn't follow our suggested order, for good reasons: what was in the car, local knowledge, how they liked to work. This path let them reorder their own route and treat that as the plan, then play or pause the route as a whole instead of setting a status on every job. Pause meant not progressing right now, whether on a break or held up.
Up next: Decision
Weighing options
Two options, trade-offs on both sides
We weighed both against what drivers needed and what we could build in the time we had.
Path A: job-level
Upsides
It replaced the existing Navigate button, so there were no extra actions to set On My Way. And assuming all went smoothly, the ETA request wouldn't interrupt their flow.
Trade-offs
It's still manual. Drivers tap On My Way, then when an ETA request comes in they update their status or pick a time window and submit. The prompt can be answered when they're ready, but it's still work.
Path B: route-level
Upsides
Letting drivers set their own route meant we could have more confidence they'd follow it. It also meant fewer actions per job, which drivers told us has a big impact on their experience. Stop ETAs could be recalculated whenever a driver reordered their stops, and made visible to support agents in Active Admin.
Trade-offs
Drivers could forget to resume, though we could build reminders around location progressing and status updates. The route's current auto-refresh made keeping a driver-set order technically complex. And a possible merge of the My Jobs and Route screens meant the investment could be short-lived or underscoped given the time we had.
What both had in common:
Drivers could say they were heading to one job, then change their mind, and we still wouldn't know.
Route-level may have been the better experience, but we ran out of time to test the design properly and answer the unknowns. Job-level was achievable with the time and engineering bandwidth we had. There was a chance to revisit route-level controls later, alongside other work on the roadmap.
Up next: Impact
Results
Six weeks after launch
Drivers reported feeling less interrupted, and agents had more confidence in the information they were working from. It also gave us the data foundation for the longer-term goal: automated ETA prompts triggered by driver position and job status, with no agent involved.
A post-launch survey revealed most of the friction was practical: forgetting to update the status, especially when navigating on a separate device, and some hesitation about the status being visible, even though it's not shared with the end customers.
Reflection
Making the best of what you've got
Sometimes the best design solution isn't achievable, and the job is to make the best of what you've got. Here that meant a simpler solution that cut manual ETA texts and calls by 70%.
In-app maps would remove most manual status-setting and improve driver UX for this feature and many others. Unfortunately, as the sole designer across the business, there was rarely time to take some of these ideas further.
