Pitstop App

Predicting vehicle failures before they happen

Pitstop is a canadian company, and an app that connects your mobile with your car and dealership, predicting possible fails on your automovil. 

Here I developed a logic information functionality of the app, the diffusion of the app updating social networks and recently building a new branding for whats gonna be the next version for the app.


Branding

The company needed to redesign the brand, but without changing the most recognizable part of the logo. It was also necessary that the brand changes in the future but in a gradual way. So this first part was focused in to build a more modern, fresh and tech look through adding light, energy and contrast that will give a variety of elements that permit us to create a strong branding. 

Before 

After

Keeping the blue, the palette was changed to stronger shades, adding light through a gradient. This will allow us to have a more playful element and give more movement to the look of the brand, both in the app, as in stationery and social networks. Movement was also added to the shape that contains the P, creating a powerful and recognizable icon at any scale.



UX

Case: Herarchy

CONTEXT

In the first place, the app contained four main pillars of actions. It let you can scan your car with a device and have a complete report about it, you can also know the services needed by the car following the mileage of it, you can request your next appointment with your dealership, and also the team was working in trips record, so this should be added soon, with the option to have a historical trip´s action´s list that will give the user a detailed report about their driving and how to improve it. All this sections needed a herarchy, and a clear way to communicate the main actions and the secondaries to the users.

And in a second place, the first point was totally represented in the menu. Where the structure does not follow the logical order of reading, nor builds a hierarchy in the path.


Pitstop previous menu
SOLUTION

A hierarchy is defined, where the car is located as the main object and based on this, two main actions, car scan and record trips, these will be our two main pillars.


New flow proposal´s for UX using the old designs of the app


Proposal flow map


Proposal for new menu
Case: Services and Scan

CONTEXT

One of the cases to solve that I would like to highline is about the logistic of the reports that the app can give to the users about their cars. One of the requirements by the team was to make that the users should not depend from a device in the car to have a feedback about it. And to not make to the users feel if they dont have this device, they cant use a complete version of the app.

– A way to make a report about the car was having the car´s mileage´s data, that users give to the app. In this way if there is mileage, there is always be a report about which services the car soon will need, after this they can also book an appointment. This action was called Services.

– By other side, another way to generate a report about the car, was when the user have an specific device connected to the car, this will give all kind of data to the app. Since engine codes, to recalls and more, translating millions of lines of code. But, it will not generate any report, if there is no device. And the whole section will looks empty, without any kind of answer by the app. This action was called Scan.

This two ways for have data from a car, was built in different ways for the developers, because there was different systems to have data from the car and make a report about it. But was not necessary to transfer this difference to the users. They just need to have a report about the car.


SOLUTION

Part of the solution was to merge Services, which delivered reports following your mileage information and Scan, which delivered reports by reading the data of your car through a device, in a same main action now called Health Report.

So that within the user’s interaction with the app, the user when requesting a report, would always have a response from the app. This solution would not exclude users who do not have a device and that situation would be eliminated.



New design´s proposals for the app