A roadside request is urgent, but accepting it blindly helps no one. I designed a field app that gives tow-truck drivers enough context to say yes with confidence — or decline before the customer is left waiting.
RoleLead UX/UI Designer
ScopeDiscovery, service blueprint, user flows, UI system, interactive prototype
PlatformOperational mobile product
Duration14 weeks
Year2025
My Role
Built around real people, not perfect scenarios.Product thinking + craft
Interface studyScroll to unpack the thinking ↓
The setup
What was really going on.
The roadside-assistance operation depended on fast coordination between the insurer, its provider network and a customer waiting in a vulnerable situation. The design brief was to reduce manual dispatch work without pressuring partners to accept jobs they could not complete within a safe and realistic time.
Key constraints
Use while driving required minimal interaction and strong safety safeguards
Weak connectivity in highways and remote areas
Requests vary by vehicle, incident type and equipment required
ETAs must remain realistic and transparent to the policyholder
01
Where it got messy
Roadside incidents are stressful for policyholders and operationally complex for assistance teams. Providers often received incomplete requests through phone calls, had little visibility into distance or expected arrival time and could not easily signal availability. This created rejected assignments, repeated calls and uncertainty for everyone involved.
02
What I designed
The app turns each request into a clear, time-sensitive job offer. Providers can set their availability, review pickup and destination details, assess distance and required equipment, accept or decline, negotiate an achievable arrival time and update the service status from dispatch to completion.
03
What changed
The experience made capacity, timing and service progress visible to everyone involved. That meant fewer coordination calls, more realistic ETAs and better operational feedback. The business metrics remain confidential, so the case focuses on the product decisions we could observe and test.
How I worked
Messy problem, clear path.
01Service Blueprint & Field Research
02Provider Journey Mapping
03Critical-Flow Prototyping
04Mobile Usability Testing
Discovery
Before opening Figma.
I started by listening for the moments where the experience stopped making sense.
Methods
Ride-alongs with assistance providers, 9 contextual interviews, dispatch-call listening, support-ticket analysis and a service-blueprint workshop with operations.
Key insight
Providers did not reject work because of low interest alone. Most refusals came from missing context: they could not quickly judge distance, traffic, equipment fit or whether a current service would delay the next customer.
Opportunity
Present every operational variable before acceptance and let the provider communicate a viable ETA, creating a more reliable promise for the stranded policyholder.
Design rationale
Why it works this way.
01
Availability belongs to the provider
A prominent availability control lets partners pause new assignments while completing a service, taking a break or operating at capacity, reducing avoidable refusals and dispatch attempts.
02
A complete offer in one glance
Incident type, vehicle location, destination, maximum arrival time and equipment needs are grouped into a single decision screen with clear accept and decline actions.
03
Progress that reassures everyone
Milestones such as accepted, en route, arrived and completed keep dispatch teams and policyholders informed without requiring repeated phone calls.
04
Designed for interrupted connectivity
Critical job details remain available offline, while status changes are queued and synchronized as soon as the connection returns.
Test, learn, repeat
What feedback changed.
Two prototype rounds were conducted with 12 roadside-assistance professionals using urban towing, highway breakdown and schedule-conflict scenarios. Testing led to larger controls, a clearer assignment countdown, confirmation before declining and a dedicated option to negotiate arrival time.
What we could verifyBusiness metrics are confidential. The product established a clearer operational flow for assistance providers, dispatch teams, and policyholders.
Selected screens
A closer look.
Looking back
What I’d carry forward.
Operational speed does not come from removing every decision. It comes from giving people enough context to make the right decision quickly. A next phase would validate live routing, battery usage and ETA accuracy across different regions and provider profiles.
Want the full story?
I’m happy to walk through the decisions, constraints and details behind the work.