carwow is a marketplace for car buyers and car dealers where buyers can find the best deals on a car and dealers can increase their chances of selling a car. I was part of Supply, a team of 8 developers, 2 product managers and 2 designers looking after the web application dealers use to manage incoming enquiries, conversations with users, stock and overall dealership performance.
The current Pricing Page allows dealers to view a list of the models they are already selling and the discount (pricing) they are selling them at. It also gives them an overview of the market by displaying the average and maximum discount for that car (on carwow).
Because it’s display only, in order to make changes to their pricing dealers have to contact carwow’s HQ and speak to their Partnership Manager. This involves dealers having to create a separate spreadsheet with all their pricing changes for models and derivatives, sending that across to their PM and then having the PM manually input the data and make the changes.
It’s an inefficient system that relies heavily on carwow’s workforce doing admin work and prevents dealers from taking full ownership of their carwow account.
The new Pricing Page had to enable dealers to do the following:
The new Pricing Page takes the shape of a table that lists all models and all derivatives, including those that don’t have a pricing yet.
This project required a massive team effort, as it grew in complexity the more in depth we went.
Who knew something so simple could turn into something so complicated?
There were so many iterations for this project that I lost count, mostly because problems arose on every front. From the way the data was stored, to actual usability problems, to the pricing system and process itself, the Pricing Page was challenging in every way.
Here’s what I learned from this project: