Cartow header image

CarTow

CarTow is a road emergency service based in Ireland. The app lets the customer request a service car to their location, track the driver’s progress and submit feedback on the service after it’s done. I worked on this project in 2015.
My role in this project was making the information architecture and wireframes. The final UI design was another colleague’s responsibility.

Decrease phone requests

Part of the reason behind the app is to decrease the load on the phone customer service. So we’ve displayed the 3 most requested services to let the user request them with minimal interaction on the phone.

Request default screen
Request default screen
Request second screen
Request second step which lists the 3 most requested services

Long waiting time

The most critical problem in CarTow’s service was the long waiting time between the customer request and the service car arrival. On average it was 40min, which is a very long time to wait in an emergency, so we needed to find a way to make that feel shorter.
So the user would see 4 tabs while they’re waiting for the service car.

  1. The tracking tab, which contains the service vehicle live location, ETA, info, driver’s info and can also call the driver.
  2. Safety instructions that should be followed while the user is waiting for the service vehicle.
  3. A tab to encourage the user to take photos of the incident if they want to attach it to the receipt for the insurance.
  4. After all that if the user still got some time, there’s a simple game of avoiding obstacles, inspired by Google Chrome offline game.
the tracking tab
The tracking tab
The safety instructions tab
The safety instructions tab
The game tab
The game tab
The photos for insurance tab
The photos for insurance tab

Vehicle condition and job finish reports

After the service vehicle arrives, if the user requested something to be changed or fixed in their car, the service agent is required to generate a customer vehicle condition report with photos and text through their agent app before working. This report will appear on the customer’s app to confirm it. Then after the agent finishes the job, they are required to generate another report stating what was done exactly and also this report appears on the customer’s app to confirm before the agent generates the receipt.

Service agent entering vehicle condition from his app
Service agent entering vehicle condition from his app
Service agent entering vehicle condition from his app (Filled)
Service agent entering vehicle condition from his app (Filled)
Condition entered appears on the customer app for confirmation
Condition entered appears on the customer app for confirmation
Service agent enters the job finish report
Service agent enters the job finish report
Job finish report entered appears on the customer app for confirmation
Job finish report entered appears on the customer app for confirmation

Closure

Those were the relatively unique features of the app, other than that it was just like any normal ride-hailing app. Also, unfortunately, I have no idea whether the client decided to proceed with the development of the app or not because I didn’t hear any news about it after delivering the design.

I hope you’ve enjoyed reading this case study, feel free to reach out to me at any time through the below links.

Back to projects