Verizon Family App: Roadside Assistance

End-to-end product design for a roadside assistance feature in Verizon's Family App, unifying two legacy services into a single experience for users who need help when their vehicle breaks down.

Three Roadside Assistance screens in a row. The first, “Where do you need assistance?”, sits under a map with a “Select location” pin and a “Move map to adjust” hint, over a location address field reading 1234 Webb Bridge Rd and a Confirm button. The second, “Request submitted.”, explains that someone will be assigned within five minutes, above a “Track your progress” bar at its first step and a Cancel request button. The third, “JC Towing is on the way.”, targets an ETA of 10:05 AM, its progress bar a step further along, with a tow truck marker on the map and a Contact provider button.

Role & Scope

As a lead designer on a cross-functional team, I owned the end-to-end UX design of the roadside assistance feature for Verizon's Family App. The work spanned about three months from discovery through high-fidelity design, covering user research and flow mapping, current state audits of two existing RSA products, and a complete new experience built to serve multiple user types simultaneously. I worked closely with product and engineering throughout, navigating complex subscription logic and real-world constraints to deliver a feature that holds up under pressure.

Overview

User Research & Segmentation
Entry Point Mapping
Current State Audit
User Flow Design
High-Fidelity Design

User Research & Segmentation

The Family App was absorbing roadside assistance capabilities from two separate products, each with its own flow, its own subscription model, and its own user expectations. Before any design work could begin, the first priority was understanding who was actually going to use this feature and what they were walking in with.

Users fell into distinct segments based on their subscription state and which legacy product they were migrating from. Each segment had different access to features, different starting points within the app, and different levels of familiarity with how roadside assistance worked. Mapping these groups early was what made it possible to design a single flow that served all of them without forcing anyone through unnecessary steps.

A diagram headed “Users”. Six boxes sit in a row: four migrants from Legacy Service 1 and Legacy Service 2, each split by whether they hold a Verizon Family subscription; then Verizon Family subscription with an RSA subscription; then Verizon Family subscription without one. Lines from the first five converge into a single box, “Unified RSA Experience”. The sixth drops instead into a dashed “Purchase path” box, which arrows back into the unified experience. — Six segments, one destination. The group without an RSA subscription reaches it through a purchase path rather than a dead end.

Entry Point Mapping

Roadside assistance isn't a feature users normally browse to. It's one they reach in the middle of something going wrong. Understanding how users would actually land on the feature was as important as designing the feature itself.

I mapped three distinct entry points: direct navigation from the primary nav, a link from the driving insights page, and a link triggered by a crash detection notification. Each one carried different context about what the user already knew and what they needed next. Designing for the most common paths first kept the core flow clean, while edge cases were handled without complicating the primary experience.

A crash detection push notification reading “Possible crash detected.” connects by labelled arrows to four screens. Tapping it opens “Were you in an accident?”, which notes a crash detected near 2345 Webb Bridge Rd and counts down from 00:59 above Yes and No buttons. Yes leads to “Do you need an ambulance?”, the same location under an ambulance icon. No leads to “Glad you're ok! Do you need a tow?”, a tow truck icon over Yes and No. Yes leads to “You can request a tow using Roadside Assistance.”, which offers a “Go to Roadside Assistance” link for one of the free tows in Verizon Family, and a “Call Verizon Professional Monitoring” link below it. Every screen carries a “Call Verizon SOS” button at the foot. A label at the right reads “Opens Roadside Assistance”. — The crash detection entry point to RSA from the initial “Crash detected” push notification.

Current State Audit

Both existing RSA products had documented flows, and auditing them side by side made the gaps immediately visible. One experience was stripped down to the essentials but left users without enough feedback during the request and wait period. The other was more thorough: covering tow destination selection, driver information, and live tracking. However, it introduced friction through redundant steps and unclear subscription states.

The audit shaped two core goals for the new design: reduce the steps users had to take to get help, and give them consistent, clear feedback at every stage of the process.

A flow diagram titled “Current State Flow - Legacy Service 1”. Solid boxes mark screens and dashed boxes mark actions and states. Login leads to a Get Assistance CTA, then Select Problem, annotated “Greyed out with phone # msg if no events available”, then a towing branch, Select Vehicle, Review Request, Submit Request, Set Pickup Location, Request Confirmation, Request Tracking, Feedback, and Complete. Request Tracking carries no actions of its own. — Legacy Service 1, the leaner of the two: the tracking step offers the user nothing to do or check.

A flow diagram titled “Current State Flow - Legacy Service 2”, in the same notation. Login, with “Continue as guest” beneath it, leads to Confirm Your Info, Select Problem, a towing branch, Set Pickup Location, Select Provider, Confirm Dropoff Location, Select Vehicle with “Add vehicle” beneath, Select Driver with “Payment if sub not available” beneath, Review Request, Submit Request, then Request Tracking, which branches to Call, Share, Cancel and Live Chat, and finally Complete. — Legacy Service 2 was thorough enough to cover dropoff, driver and live tracking, but at the cost of a much longer path to the same help.

User Flow Design

The proposed flow organized the RSA experience into a linear sequence: open the RSA landing page, select or add a vehicle, choose a service type, confirm a pickup location, select a service provider, submit the request, and track in real time. Phases were grouped into five stages: Open RSA, Request Service, Pre-Service, Service in Progress, and Service Closeout, giving both users and the cross-functional team a shared mental model for how the feature worked end to end.

A wide swimlane diagram headed “Verizon Unified Family App”, subtitled “RSA Event Initiation: Account Owner - Towing”, for a Verizon service provider with an active account and RSA subscription. An Overview lane runs banded arrows across the top (Open RSA, Request Service, Pre-Service, Service in Progress, Service Closeout, History) over a User flow lane below. That flow runs START, Open Family App, MDN subscription validation, Open RSA Page, Select/Add New Vehicle, Select Service (Towing), Location Selection, Select Service Provider, Submit Request, Processing Request, Request Confirmed, Provider Confirmed, Track Provider Loc. Progress, Provider Arrival, Track Towing Progress, Receive Service from RSA Provider, Service Completed, Satisfaction Survey, END, and Event Detail Saved to Family App. Requirements and open questions are noted beneath the steps they belong to. — The account owner's towing journey, with the five stages banded across the top. This was the shared mental model the whole team worked from. View full size (opens in a new tab)

Several decisions shaped how the flow came together:

Subscription-aware entry.

The RSA landing page surfaced different content depending on a user's plan status. Active subscribers saw their event allotment, member ID, and a direct call-to-action. Users without an active plan saw a clear path to purchase. The same entry point served both without either group hitting a dead end.

Map-first location input.

Rather than requiring users to type a precise address while stranded, I pushed for a map-based pickup selection where users could move the pin to adjust their location, supplemented by free-text search for situations like highway breakdowns where no address exists.

10-mile towing constraint handling.

Towing destinations beyond 10 miles couldn't be serviced. Rather than surfacing this at submission time, I designed the error state to appear inline as soon as an out-of-range destination was selected, keeping the map visible so users could immediately course-correct without losing their progress.

A Roadside Assistance screen. A map with a “Select location” pin sits above a drawer headed “Where would you like your vehicle to be towed?”. The location address field, reading 123 Old Roswell Rd, Garlow, PA, is outlined in amber with a warning icon. Beneath it an amber panel headed “Select a closer towing location or call.” explains that the current towing location is more than 10 miles away, gives a member ID of 1234567XYZ to have ready, and offers a Call button. The Confirm button below is greyed out. — Map-first input, with the 10-mile limit caught inline the moment the destination is picked. The map stays on screen so the user can just move the pin or search a nearer one.

Pre-populated driver info.

The driver information step pulled from account data by default, keeping the experience fast for repeat users while still allowing overrides when needed.

A detailed flow titled “RSA: Towing Service”, entered from Roadside Assistance. Boxes and decision diamonds run left to right with the real screen beneath each, and a red line traces the path a user takes through them. START leads to the RSA landing page, headed “Need assistance?”, which shows 2 of 4 events remaining, a member ID, three saved vehicles and a request history, with its “Start a request” button ringed. From there: Start a request, Select / Add New Vehicle (“Which vehicle needs assistance?”), Select vehicle, Select service (Towing, Lockout, Fuel delivery, Tire change, Jumpstart), Towing, Location selection (“Where do you need assistance?”, a map with a movable pin over an address field), Select destination (“Where would you like your vehicle to be towed?”, providers listed by distance), Driver details (“Which driver needs help?”, name and phone already filled in), and Confirmation (Submitted), which hands off to the RSA service flow. Notes on the interaction sit beneath the steps they belong to. — The towing request screen by screen, from the landing page through to submission, with the driver's details already filled in by the time they reach that step. View full size (opens in a new tab)

High-Fidelity Design

The high-fidelity phase translated the flow into a complete set of screens built against the Verizon design system. Key screens included the RSA landing page with subscription status and event tracking, vehicle selection with add-vehicle support, service type selection, map-based pickup and dropoff location, service provider list sorted by RepairPal certification and distance, real-time tracking with two progress milestones, and a post-service satisfaction survey.

Edge cases were designed with the same level of care as the primary flow, including the 10-mile error state, the out-of-subscription purchase path, and the handling of vehicles without GPS that fell back to ETA-only tracking.

Three screens. The first is the Verizon Family home map, with family members' photos pinned and a card at the foot reading “You requested a Towing service at 9:51 AM.” above a segmented progress bar, a greyed-out Call button and a Cancel request button. An arrow labelled “Open RSA” leads to the second and third. “Request submitted.” says someone will be assigned or the user contacted within five minutes, with its progress bar at the first segment and a Cancel request button. “JC Towing is on the way.” warns of possible delays while targeting an ETA of 10:05 AM, with the bar at the second segment, a tow truck marker added to the map, and a Contact provider button. — The two tracking milestones, reached from the live request card on the Family App home screen.

Impact & Learnings

The RSA designs shipped as part of the larger Family App unification effort, consolidating two separate product experiences into one coherent interface that served multiple user states without added complexity. The inline constraint handling and map-based location input were both retained through final review; two of the decisions I advocated for most directly.

What this project reinforced was how much user context matters when the stakes are real. Someone stranded on the side of the road isn't in a position to troubleshoot a confusing flow or re-enter information they've already provided. Every step that could be simplified or pre-populated needed to be. That constraint made the design decisions easier to defend and sharper to execute.