Mobile App - UX / UI

Roadside Assistance Provider App

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
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.

  1. 01Service Blueprint & Field Research
  2. 02Provider Journey Mapping
  3. 03Critical-Flow Prototyping
  4. 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 verify
Business metrics are confidential. The product established a clearer operational flow for assistance providers, dispatch teams, and policyholders.
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.