Carsparency Pro — the dealer platform, from bid to title transfer
The dealer side of a UAE car marketplace: timed auctions up front, and a five-stage path from winning bid to title transfer behind them.
Company
Carsparency
Role
Product designer
Type
Product
Industry
Automotive marketplace · B2B
Team
Product designer; team size and roles are not recorded in the files
Tools
Figma
The problem
A dealer wins a car they have never touched. Price, payment, papers, delivery and title transfer still have to happen, and any of them can stall the trade.
The role
Product designer on the dealer platform: the app and the desktop web product, from the auction list to title transfer.
The result
129 app frames and 167 desktop frames covering the whole buy-side lifecycle. The files record no launch date or usage data.
Figure 01
Figure 01The dealer app: the live auction list filtered by make and year, the bid sheet, and pending orders that each show their step in the purchase.
01Context
A dealer platform, designed as an app and a desktop site at once
Carsparency ran a used-car marketplace in the UAE: private sellers listed a car, an inspector recorded its condition, and verified dealers competed for it in timed auctions. Pro is the dealer side, the product the buyers used.
Its Figma file holds both halves of that product. Four app pages cover auctions, orders, account and sign-in, and four web pages repeat the same areas at desktop width. Together they hold 129 app frames and 167 desktop frames, most of them states of the same screens rather than new screens.
Figure 02The desktop auction list: Live, Upcoming and Inventory tabs, a filter panel for price, mileage, year, make and distance, and on every card the current bid set against Fair Market Value.
02Problem
Winning the auction is the middle of the purchase, not the end
A dealer bids on a car they have not seen, against rivals they cannot see, with a countdown running. The auction screens have to make that decision quick and defensible.
Then the harder part starts. After the hammer the car still has to be priced, paid for in stages, documented, delivered and legally transferred. That work runs between the dealer, the seller and Carsparency's staff, and it can stall at any step. Most marketplace flows stop at the winning bid; this one keeps going.
03Flow
One lifecycle, five numbered stages
The largest area of the file is not the auction but Orders. Every won car moves through In Negotiation, Pending and Procured, and a card never just says pending: it says which of five steps the order is on and what comes next.
The status sits in the same place on every card and every detail page, as a coloured band with a single action beside it, so the dealer can always see whether the next move is theirs.
The buy-side lifecycle as the file lays it out
01
BidLive, upcoming and inventory lists; bid, proxy bid, automatic bid or buy it now; winning and losing states.
02
NegotiateIf the seller declines, raise the offer or accept the seller's price.
Losing
Figure 04Pending orders on desktop. The strip under each card carries the step number and its name, such as 3 of 5, pending settlement, and the button above it is the one action that step needs.
04Key decisions
Four decisions that shape the dealer's day
These choices are visible in the frames. The file does not record the reasoning, so the reasons below are read from how the screens are built.
01
Print Fair Market Value under every bid
A dealer bidding against a clock needs a reference point that is not the other bidders. Showing the platform's valuation next to the current bid, on the list and on the detail page, turns each bid into a comparison rather than a guess.
Trade-off
It opens the valuation to argument: a bid far above Fair Market Value invites the question why.
02
Number the steps after the hammer
Pending tells a dealer nothing about what to do. Step 1 of 5, pending pre-payment, tells them where they are, how much is left and whose move it is.
Alternatives
A single in-progress state, or a separate timeline page.
03
One detail template for the whole lifecycle
The car page a dealer bid from is the page they later track delivery on. Only the status band and its single action change, so nothing has to be relearned between stages.
05Solution
Auction speed up front, visible paperwork behind it
The auction side is built for fast comparison. The countdown turns red in the last minutes, a coloured pill says Winning or Losing, and proxy and automatic bids let a dealer compete without watching the clock.
The order side is built for trust. Pre-payment shows the balance due, the funds available and the wallet before anything is charged. The price breakdown itemises every deduction, the document list names each paper the transfer needs, and each step has its own failure state (payment failed, upload rejected, over-payment) instead of a generic error.
Auctions: Live, Upcoming and Inventory, with filters and sorting
Bidding: bid, proxy bid, automatic bid and buy it now, with success and error messages
Orders: negotiation, pre-payment, settlement, proof of payment, delivery and title transfer
Account: wallet, bank accounts under review, documents, notifications and help
Figure 05The car detail on desktop. The price card pairs the current bid with Fair Market Value, the remaining time and two ways to bid: proxy or direct.
In negotiation
Pending delivery
Figure 06The same price card at two stages. Only the status band and the action change: in negotiation with the seller, with Increase Price, then pending vehicle delivery.
Pre-payment
Price breakdown
Figure 07Pre-payment and price breakdown, cropped from the desktop dialogs: balance due against funds available, then net price, discounts and withholdings before the final amount.
Figure 08The exploded car map drawn in the Pro file: roof, bonnet, doors and bumpers laid flat, with glyphs for dents, scratches and paintwork. The same drawing returns on the defects page of the inspection report.
06Every screen
216 phone screens and 170 desktop pages
Every page of the Pro Figma file was scanned on 27 September 2026 and every screen-sized frame exported: phone screens at 390 points, desktop pages at 1,440 pixels. The four app pages hold 129 frames and the four web pages 167 desktop frames; shown once each, with the web’s own phone layouts and the Updates page added, that makes 216 phone screens and 170 desktop pages. Both indexes follow the dealer: sign-in, the auction list and a car’s detail, then the orders a win opens (negotiation, pre-payment, settlement and proof of payment, title and delivery), then the account, bank accounts, wallet and help.
Most of the web pages’ phone frames copy the app’s and are shown once; the 42 that differ, with dollar prices, real Privacy, About and Help copy, empty states and a share sheet, are under Mobile web. The Redesign tabs hold the Updates page: a rebuilt car detail with a defects map, sign-in by phone number and loading states; the App Store sizes and the auction-card Explorations have tabs of their own. Sample emails, phone numbers and the sample portrait are masked, and so is the bank-transfer screenshot used as a sample proof of payment.
07Ecosystem
The last stop for a car that started on the seller's phone
Everything a dealer reads in Pro was produced upstream. The seller described the car in the web wizard, an inspector verified it in the inspection app, and operators priced it and invited dealers from the back office. Pro is where that record meets a buyer.
The shared pieces are visible across the files: the same car record (mileage band, GCC specification, title holder, service history), the same condition grades, the same price vocabulary (Fair Market Value here, Fair in the back office) and the same component library underneath.
08My role
Sina's part
Listed from the Pro 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
↳Navigation and structure for the app and the desktop web product
↳The auction list, filters, and the bid, proxy and automatic-bid states
↳The order lifecycle: negotiation, payment, settlement, delivery and title-transfer states
↳Account, wallet, bank-account and document flows with their review states
↳The exploded car map used to locate damage
Co-owned
—
Collaborated
↳Engineering and operations colleagues, not named in the files
The file also keeps an Updates page and numbered card tests (Test 2 to Test 7), evidence that the auction card was iterated rather than drawn once.
09Outcomes
What the file delivers
Counts of designed frames, not results. No launch date, usage or conversion figure is recorded in the Carsparency files.
app frames
129
Four app pages: Auctions, My Cars, Account, and Login and Onboarding
Delivered output
desktop frames
167
Four web pages repeating the same areas at 1,440 px
Delivered output
numbered order stages
5
From pre-payment to proof of payment, each with its own status and action
Delivered output
What was delivered
↳Auction list, filters and sorting
↳Bid, proxy bid, automatic bid and buy it now
↳Negotiation and counter-offers
↳Pre-payment, settlement and proof of payment
↳Delivery and title-transfer tracking
↳Wallet, bank accounts and documents
10What I learned
What this work taught
01
Design the part after the success state
The winning bid is where most auction flows end. Here it is roughly the midpoint, and the frames after it (payments, papers, delivery) outnumber the auction screens.
02
Numbers beat adjectives in a status
Step 3 of 5, pending settlement, answers the three questions a dealer has: where am I, how much is left, and what do I do next. Pending on its own answers none of them.
03
Placeholder data hides the hard cases
Every card in the file shows the same car and the same price, so the layout is never tested against a long title, a cheap car beside an expensive one, or a bid far above its valuation.
Pre-payPay from the wallet or online, with the funds available shown first.
04
SettlePrice breakdown, final settlement and proof of payment, with rejected and over-payment states.
05
TransferPending vehicle delivery, then waiting on title transfer, then procured.
Winning
Proxy bid
Figure 03The bid card in three states: losing, winning, and a proxy bid being set. The Fair Market Value line stays under the bid in all of them.
Trade-off
The page stays long: the inspection report sits below the price card at every stage.
04
Show the cost of winning before asking for it
The price breakdown separates net purchase price, discounts and withholdings, and the bid sheet adds transport and extended buyer assurance, so the dealer sees the landed cost rather than the hammer price.
Figure 09Every screen at phone width: the app flow by flow, then the web’s own phone layouts and the redesigns; open any screen to see all of it.
Figure 10Every desktop page, flow by flow; open any page to see all of it.
