Pitstop App
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.
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.
Before
After
UX
Case: Hierarchy
CONTEXT
A first part to highlight in the context is that the app contained four main pillars of actions.
First, it let you scan your car with a device and to have a complete report about it. Second, you can also know the services needed by the car by following the mileage of it. Third you can request your next appointment with your dealership. And last, the team was working on to have a record of the trips maded, with the option of 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.
A second part to hightlight, was that 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 app menu
SOLUTION
Understanding users:
To understand how users manage, organize and build a hierarchy about their car’s information, we used the card sorting technique in a groupal activity with users. This activity allowed us to understand the hierarchy users build and how they expect to see information.
The hierarchy defined, has the car located as the main object and based on this, two main actions: car scan and record trips, these two will be our main pillars. Those two actions answer to “Whats the status of my car?”.
And book an appointment will be considered as a secondary action as result of the car´s status.
And in a third level, the action to record a trip, appear as an action for dealerships so they can evaluate the state of the fleet and possible failure causes.
With a hierarchy defined, we can build the complete structure. We will see how this affects directly to the whole AI of the app.
Now with a hierarchy the first part is to reflect this hierarchy on the Menu’s design to then work in the main structure’s information architecture.
Proposal for new app menu
New flow proposal´s for UX using the old designs of the app
Proposal flow map
Case: Services and Scan
CONTEXT
One of the cases that I worked on and that I would like to highlight is about the logistic of the reports that the app can give to the users about their cars.
Requirements & Constraints Gathering:
After talk with some internal stakeholders, was a global interest on how users depend of an external device to make a scan of the car.
Understanding the problem:
– Services: 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.
– Scan: By other side, another way to generate a report about the car, was when the user had a 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.
Why we made this difference?
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. We were traspassing the developers mental model to the users. But was not necessary to reflect this difference in the structure of the app to the users.
Understanding users:
To discover how this affects to users we made user interviews where we realized that users feel totally exclude from the main actions in the app as they needed to have a specific device to scan their cars.
To have the device give a more complete report about the car, but not all the users have it. We were giving an all/nothing product, instead to have different levels following the different needs.
Usability testing:
After some usability testing with users, we checked goals, behaviours and environment of different users with the app. Here we realized that most of the users got confused, and frustrated when they see an empty report just because they didn´t had the device.
SOLUTION
The users needed a positive answer after trying to scan their cars.
Part of the solution was to merge Services (mileage report) and Scan (data with your device) and we called Health Report. So instead have it as two different actions, we have it all under the same report but with different levels.
The flow now is first with a main action called Health Report, where if you have the device it gives you a report scanning your car, and if you don’t have the device, it will give you a report following your mileage, based on the services you needed to attend soon.
Note: Interesting how a mental model without focus on users, can be represented on the architecture information through little details that at the end mean the complexity or misunderstood of a product.
New design´s proposals for the app
About UI
I built a new concept, and branding represented in the new guidelines for the app. I worked building a visual hierarchy creating different values on sizes, colors and iconography, that helped to understand complexity of all the data involved in car scanning in easier ways to communicate it for the users.
Software’s Dashboard
Pitstop also had created a software to can track data from car fleets that are using the service to predict possible failures and do maintenance.
Here I did maintenance from the design and contributed solutions for a better data delivery and a good data visualization to both the car dealers and car fleets.
Proposal for the Appointment’s section for the fleet cars user view:
Proposal for the Trip History section for the fleet cars user view:
