Context & Problem
Designing trust into a fragmented claim experience
The extended warranty product for used cars had launched as a lean MVP through used car dealer networks, with the early focus on sales and plan activations rather than claim experience.
At launch, all claims had to be raised via calls
This worked well for breakdowns, where users preferred speaking to an agent for reassurance.
But for non-urgent issues, while the car was still in running condition, this call-only setup felt slow and created extra ops cost from repeated coordination calls.
There was no in-app journey for these users, and no post-claim visibility for anyone. Pickups were handled by unverified agents, and once the car left, users had no idea where it was, who had it, when they’d get an estimate, or what was covered.
This led to anxiety and distrust for users and constant manual firefighting for ops.
Problem Statement:
How might we add a self-serve in-app claim flow to reduce ops load, and design clear post-claim visibility to build trust for all users?
Goals & Success Criteria
Designing for scalability, trust, and operational efficiency
As we planned the new journey, my product manager and I focused on designing a system that could scale reliably while improving user trust and reducing operational load.
Our goals were clear:
Add a digital claim option, so users can self-serve without needing to call.
Reduce ops load and cost by cutting back-and-forth coordination calls.
Retain call-based claims for breakdowns, where human reassurance matters.
Provide end-to-end visibility through a real-time claim timeline, from pickup to delivery.
Add safety and trust signals like pickup agent photo, name, OTP, and live ETA.
Show coverage clarity early by splitting covered vs non-covered parts during estimation.
Integrate tightly with VehicleCare’s APIs to pull live status and trigger reminders/escalations.
We wanted it to feel as predictable as booking a cab, even though the backend world was nothing like that.
My Role & Collaboration
I was the sole UX designer on this project, partnered with one product manager. My focus was on making the claim journey usable and trustworthy, not just on screens, but across the entire system that powered it.
I framed the user journey, identified where milestones and verification were needed, and collaborated with ops and tech teams to confirm feasibility. Once the backbone was clear, I designed the chatbot and claim timeline flows, applying our design system to keep UI consistent and efficient.
In short: my role was to translate user needs into an experience that the business and backend could actually deliver at scale.
Research & Discovery
Understanding how the journey actually worked on the ground
Before designing solutions, I needed to understand why the current experience felt broken for users and chaotic for ops. I focused on seeing how claims were handled end-to-end in the existing call-based model.
To do this, I:
Visited 3 VehicleCare-affiliated service centers to observe real claim handling.
Shadowed customer care calls to map common friction points and delays.
Interviewed 15 users who had recently raised claims to hear their frustrations directly.
What I found:
Each workshop followed inconsistent, informal processes
Pickups were done by unverified agents, often without IDs or timelines
Users had no visibility once the car left, no status, no expected dates
Part-level coverage data was missing from VehicleCare’s APIs, so estimation was unclear
There was no fallback flow if a claim was unclear or rejected.
These findings shaped a key principle for the project:
Before designing the interface, we needed to design the system - aligning operations, data, and user experience around a single journey
Design Process
Aligning the system around user needs before designing the screens
The real problem wasn’t just missing screens. It was that the experience itself didn’t exist.
Users had no way to book claims through the app and no visibility once their car was picked up.
This created anxiety, distrust, and constant back-and-forth with support.
Before sketching interfaces, the first step was to define what the ideal experience should feel like for users, and then shape the system to deliver it.
Working with my product manager, I created a user flow for both user segments.
We used this user flow to align VehicleCare’s ops, product, and tech teams, along with our backend and frontend leads.
This provided everyone with a shared view of the journey, surfacing gaps such as missing part-level data, lack of scheduling logic, and no agent verification. It helped us identify and lock down key dependencies and SLAs before moving into the UI.
With the experience principles and system foundations in place, we could now begin designing the actual user-facing journey - starting with the chatbot flow and claim timeline.
✨ Crafting the Claim Flow
Chatbot for Raising a Claim
With the backbone aligned, the first user-facing layer I designed was a chatbot flow. The goal was to give users a way to raise claims digitally that felt natural, fast, and trustworthy, especially for those in Tier 2/3 cities who were more comfortable with chat-like interactions than complex forms.
What made this possible wasn’t just the chatbot itself, but the system-level changes behind it:
Service centre discovery (distance, ratings, reviews): Gave users confidence in where their car was going and pushed workshops to stay accountable.
Pickup scheduling (date/time slots): Turned open-ended waits into predictable plans while helping workshops manage capacity.
Multilingual support: Made the flow inclusive for Tier 2/3 users, lowering hesitation.
Backend automation: No typing, no forms; vehicle, address, and agent details flowed directly from APIs.
Together, these changes transformed a messy, call-heavy process into a guided, digital experience users could complete in minutes, while ops spent less time on repetitive coordination.
View Prototype (Raising Claim) →
Since we already had a design system in place, the UI work itself was straightforward, most of the effort went into shaping flows and aligning system dependencies, not reinventing visuals
Designing the Claim Timeline
If the chatbot made starting easy, the bigger trust gap appeared after raising a claim. Once a car was picked up, users entered a black hole, no updates, no clarity, no idea when it would come back. Most ended up calling support just to ask, “What’s happening with my car?”
The solution was to make progress visible. I designed a claim timeline that turned an unpredictable process into a guided sequence of milestones.
Instead of silence, users now saw:
Request Raised: Instant confirmation with claim ID and service centre.
Pickup Agent Assigned: Photo, name, OTP, and live ETA, so they knew exactly who was coming.
Vehicle Picked Up: verified through OTP at the doorstep.
Estimation Stage: Workshop diagnosis split clearly between covered and non-covered parts.
Repair Initiated: Shown once the user approved the estimate.
Vehicle Ready for Delivery: Delivery slot with a reminder.
Each milestone acted as a reassurance point, replacing doubt with predictability.
Originally, we explored live GPS tracking for pickup agents, but it wasn’t reliable across all workshops and devices. To avoid showing users a broken map, we designed milestone-based updates as the default, triggered by backend events (like OTP verification or estimate approval). This ensured users always saw progress, even when real-time tracking wasn’t possible.
View Prototype (Claim Timeline) →
Impact & Learnings
Impact
Claim initiation became a guided chatbot flow, cutting effort from hours of coordination to minutes.
The claim timeline reduced anxiety; users could see each stage clearly, instead of calling support for updates.
Trust improved through agent verification and part-level cost clarity, making handovers feel safe and predictable.
Learnings
Reliability matters: Live GPS wasn’t consistent, so milestone-based updates became the real trust builder.
Choice matters: Some users still preferred phone calls; keeping a human fallback made the experience inclusive.
System is UX: The biggest design work was shaping APIs, SLAs, and flows so the UI could actually deliver on its promise.
Reflection
This project reminded me that great UX isn’t just what happens on the screen. It’s how the whole system works around the user. The chatbot and timeline were visible outputs, but the real design work was in shaping flows, dependencies, and safeguards that made the journey predictable and trustworthy.
For me, this was a lesson in designing not just for usability, but for confidence. Turning an anxious, opaque process into one users could rely on.
