Carsparency Inspection — turning a physical survey into a structured record

Carsparency Inspection — turning a physical survey into a structured record | Sina Oshaghi

01Context

The evidence behind every bid

On Carsparency a dealer buys a car without seeing it. What they trust instead is the inspection: a Carsparency inspector's record of the car's condition, printed on every detail page in the dealer app and in the report the business hands over.

The inspection app is where that record is made. Its file holds 27 mobile frames, three local component sets and a benchmark page of another inspection app kept for reference.

02Problem

A walk around a car does not arrive in order

An inspector works standing next to the car, on a phone, and no two cars are the same: equipment differs, and a company car has a different title holder from a private one. Yet what comes out has to be comparable from one car to the next.

The design problem is to impose a structure the inspector can follow in any order, without forcing them to type what they can tap, and without letting a skipped area pass unnoticed.

03Flow

From the queue to a completed record

The inspector starts from a queue split into All, In Progress and Inspected. Each card says whether the car is ready to start or already half done, so interrupted inspections are picked up with Continue rather than restarted.

A short wizard captures the car's identity first. Then a dashboard opens the ten survey areas as tiles, each showing how many checks failed and passed, with a time-remaining bar and a single Complete inspection action at the bottom.

An inspection, as the app sequences it

01
Pick upChoose a car from the queue, or continue one in progress.
02
IdentifyMileage band, title holder, GCC specification, colour, keys, location.

Carsparency Inspection — the car-details wizard, step one: mileage band, title holder, GCC specification and colour

Carsparency Inspection — the same wizard with an unanswered title question outlined in red

Carsparency Inspection — the tyre and body checklist with pass or fail per part and defect toggles with descriptions and photos — Figure 03The tyre and body checklist, the core interaction of the app.

04Key decisions

Four decisions that fit the job to a phone

Read from the frames; the file shows the choices, not the discussion behind them.

01
A dashboard of areas instead of one long form
An inspector does not walk a car in a fixed order. Ten tiles, each with its own failed and passed counts, let them work in any order and see at a glance what is left.
Alternatives
A single scrolling form, which punishes any change of order.
02
Record exceptions, not everything
Each part has a default value that stands unless a defect is reported. Most parts of most cars are fine, so the inspector's time goes to the ones that are not.
Trade-off
A careless inspector can pass a part without looking; the per-area counts make that visible afterwards rather than preventing it.
03
Every defect carries its own proof
A scratch with no photo is an opinion. Each defect type opens its own description and photo slots, so the report a dealer reads is evidence rather than a checklist.

05Solution

Tap what is normal, document what is not

Inside an area, each part is a row with a pass and a fail button. A default value is recorded when no defect is reported, so the inspector only spends time on exceptions.

A defect opens its own controls, one toggle each for hail damage, painted, partly repainted, dent, scratch and replaced, and every one that is switched on asks for a description and its own photos. Pictures are taken against named slots (front driver alloy, rear passenger corner and so on), so the photo set is complete and comparable rather than a camera roll.

Queue: all, in progress and inspected, with search and empty states
Car details: mileage band, title holder, GCC specification, colour, keys and location
Ten areas: car body, transmission, engine, chassis, suspension and brakes, tyres, interior and electrical, air conditioning, glass and mirrors, features
Evidence: per-defect photos, named photo slots, images and videos

Carsparency Inspection — the car pictures page, a grid of photo slots each named for a wheel or corner of the car

Carsparency Inspection — the upload sheet offering gallery or camera, then moving on to the next named angle

06Ecosystem

The inspection becomes the report, and the report becomes the listing

The inspection sits between the seller's own account of the car and the dealer's bid. The seller answers the same questions on the web (title holder, finance, warranty, service history), and the inspector's app verifies them in the field.

What the inspector records flows out twice: into the Advanced Inspection Report, whose defects page uses the same exploded car map as the dealer app, and into the condition sections dealers read in Pro before they bid.

Carsparency inspection report — the defects page drawn on an exploded car map, with a legend for repainted, painted, original and not-available panels — Figure 05Where the inspection ends up: the defects page of the Advanced Inspection Report, drawn on the same exploded car map as the dealer app.

07My role

Sina's part

Listed from the Inspection file. The files do not record team size or who decided what, so this is the work in the file, not a claim of sole authorship.

Owned

The inspection queue, with its states and search
The car-details wizard and its validation
The ten-area dashboard and the area checklists
Defect entry with per-defect photos and descriptions
Photo capture against named angles

Co-owned

Collaborated

Inspection and operations colleagues, not named in the files

A second version of the wizard sits beside the first in the file (Version 1 and Version 2), so the car-details step was iterated.

08Outcomes

What the file delivers

Counts of designed work, not results. The profile screen shows inspected, rejected and scheduled counts and an average time, but those are placeholder values, not recorded data.

mobile frames: 27; Queue, wizard, dashboard, checklists, photos, sign-in and profile; Delivered output
survey areas: 10; From car body to glass and mirrors, each with pass and fail counts; Delivered output
defect types per part: 6; Hail damage, painted, partly repainted, dent, scratch and replaced; Delivered output

What was delivered

Inspection queue and search
Car-details wizard
Ten-area survey dashboard
Part checklists with defect entry
Named photo capture
Completion and time-remaining tracking

09What I learned

What this work taught

01
Structure is what makes field data comparable
The value of an inspection is that two cars can be compared. Named slots, fixed areas and fixed defect types do more for that than any amount of free text.
02
Design for the exception
A default value per part keeps the common case to one tap and saves the inspector's attention for the parts that need it.
03
A tool used standing up needs to survive interruption
Resumable inspections and a visible time bar matter as much in the field as any individual screen.

Language

Carsparency Inspection — turning a physical survey into a structured record

The evidence behind every bid

A walk around a car does not arrive in order

From the queue to a completed record

An inspection, as the app sequences it

Four decisions that fit the job to a phone

A dashboard of areas instead of one long form

Record exceptions, not everything

Every defect carries its own proof