Vinsyt / Consumer mobile app

iVin

Vehicle care, coverage, and booking, organized around the owner’s questions

I designed Vinsyt's owner-facing mobile app, bringing maintenance, service history, documents, coverage, and booking into one experience. My work included the AI assistant's conversation flows, answer presentation, and transition into booking, alongside the app's navigation, components, and copy.

Role

Product design, interaction design, UI, components, and UX writing.

Team: I was the sole designer, with a product owner and a lead developer.
Surfaces: iOS and Android. Shared components with the owner web app.
Stage: Production product. Featured screens: Figma prototype.

The owner's record

Bring the record together around four questions

A maintenance schedule, an invoice, a coverage document and an appointment, each held somewhere different — Where it lives now

A maintenance schedule, an invoice, a coverage document, and an appointment each answer a different part of the same question: what do I need to do about this car?

The four owner questions the app is organized around — The four questions

I organized the experience around four owner questions. The record provides the detail; those questions give it a useful structure.

The first visit

Make the first visit useful before asking for the app

The wider experience includes a browser route as well as the phone app. A link can take an owner into their record without making installation the first task.

The app invitation then has a specific job: explain what the phone experience adds.

Two routes into the record: a browser link and an app invitation — Two ways in

The browser provides an entry to the record; the invitation explains the phone experience. Roughly 19 of every 100 owners who receive a record go on to sign up for the app.

The AI assistant

Make a vehicle-aware assistant the starting point

We developed an AI assistant that starts with the selected vehicle and the information already available about it. It uses the owner's manual for model-specific guidance, the vehicle's history and coverage information for context, and dealership data for service prices and offers.

I designed how that information becomes an interaction: how an owner asks a question, how the answer is presented, and how it leads into booking. The owner describes what they need help with, rather than first supplying the background the platform already holds.

That capability shaped the app's entry point. Instead of adding the assistant as another destination in a directory, I made it the starting point. The assistant, service advisor, and owner's notes sit in one chronological view, while coverage has a destination of its own.

A spoken question answered from the contract and priced from the dealership list — What it knows before the question

One question, asked out loud in the owner’s own words, answered from the contract and priced from the store’s own list.

The app information architecture, with the conversation first and coverage as its own destination — The information architecture

The main destinations keep the vehicle record and coverage accessible.

A question-led entry gives someone with a clear concern a place to start, but makes an unfamiliar feature harder to find when they do not know what to ask.

The coverage answer

Keep the answer, the price, and the next step separate

I kept the coverage link secondary rather than turning the answer into a sales offer. The owner can understand what is covered, what a diagnosis would cost, and what to do next as separate decisions.

A coverage answer split into what is covered, what it costs and what to do next — One answer, three parts

The answer explains the contract and offers a next step without selling inside the response.

The path from the coverage question through the contract to the dealership price — The path it is shaped around

Contract information answers the coverage question; the dealership supplies the price.

Booking a visit

Turn the answer into a service visit

The featured flow connects the owner's question to three sources: the coverage contract, the vehicle record, and the dealership's current service offer. The assistant explains what the contract covers, presents the dealership's diagnostic price, and offers a booking step without turning the answer into a sales pitch.

The conversation carries the vehicle, relevant service, and open recall forward. It asks for what still needs confirming: a current mileage reading, a preferred day, and whether the owner plans to wait.

The booking flow from the question through to a confirmed appointment — Asked, answered, priced, booked

The AI-assisted booking flow carries the vehicle, service, and recall forward, then asks for the visit details that still need confirming. 537 of the 649 service appointments the platform produced in 2026 were booked here.

The connected product

Keep the rest of the product directly accessible

The garage is organized around a household, with the advisor above the vehicles. Coverage puts exclusions alongside inclusions. The record holds what is due, what has been done, and the documents an owner may need to produce.

The garage, the coverage view and the vehicle record — The rest of the product

These views support the question-led entry while keeping the record and other owner tasks visible in the interface.

A reminder leading back into the booking thread it belongs to — The booking thread

A reminder should also lead back to something the owner can act on. Its wording and destination are part of the same flow as the screen it opens.

Delivery & scope

One owner experience, connected to the wider platform

The work covers the mobile app’s structure, interface, shared components, and copy. The browser experience, lifecycle messages, and design system are covered in separate case studies.

1,895 sign-ups in the first eight months of 2026
2,057 assistant sessions over the same period
iOS and Android, on shared components with the owner web app
The product is in production. The featured screens on this page are from a Figma prototype.