Vehicle Fuel Data Import
Harnessing third-party fuel data to automate vehicle maintenance scheduling.
Duration
Oct 2017 - June 2019
My Role
Product Designer
Platform
Responsive Desktop SAAS App
Project Brief (TLDR)
Collective Data is a cloud software company that sells enterprise asset management software to construction, utilities, law enforcement and government industries. At the time I was there, they had 30 employees and 400 customers across the continental USA.
The company's engineering resources were being wasted dealing with support tickets caused by infrastructural issues with a fuel transaction import.
The engineers could not focus on the main product.
I took the initiative to re-design the framework/logic to better handle importing thousands of re-fueling transactional records from a third party source to address the aforementioned infrastructural issues.
Recording of the workflow to fix a record that couldn't find an matching vehicle in the system.
Outcome
Roughly 35% of our customers have atleast one fuel integration, with half of those customers using the advanced fuel integration (as of July 2022).
The improved fuel integration module now groups records by the vendor, month, and fuel type. End users are able to resolve any errors with the imported transactions directly within the system.
Research : User Interviews
To establish a baseline understanding: I interviewed internal support agents, and account managers.
I also reached out to reps from the third party companies we were importing from.
If you want to see the deliverables from the research in 2019, please invest in time machine.
The Problem : Under-designed
The middleware handling the data was not robust enough to handle certain scenarios.
Simple scenarios such as "hey does this vehicle exist in the system" did not have graceful failures or notifications to users that anything went wrong.
The problem could go on for 6 months before anyone noticed. That's 6 months of data clean-up for support to deal with as well.
User Notifications and Problem Resolution
Our system can detect and notify users of when problems happen and how to resolve them.
Solution: Two Paths Forward
Moving forward there were two options: working with the software engineering (SWE) team to implement a solution in the backend or design and develop a solution myself in the middleware.
Create a support ticket with engineering.
Design a solution to improve the middleware's functionality.
Backend? Middleware? Huh?
Here's a rough approximation of how the sausage is made at Collective Data.
settings_applications
Backend
Software Engineers
hub
Middleware
App Devs & UX Designer
web
Frontend
End-Users
The building, whether it be a house, an office building, a barn. Made specifically to what users need.
That's cool, but how the hell did you know what to do?
Years of working for Collective Data gave me extensive product middleware knowledge. This understanding included both functionality and database perspectives. I worked with app devs and software engineers daily. Their knowledge passed on to me.
Leveraging this knowledge, I first started to map out the information architecture and user-flows. Both of which were enhanced by the information gained during the research interviews.
Research - How did it impact the designs?
An example of the info gained during research was finding out that customers could be integrated with multiple third party vendors. Customers informed me they wanted odometers to come from source A but fuel transactions to come from source B.
So I added an "integration" field. The values being the third party company's name.
With the integration field the system could differentiate imported transactions by source and what data was brought in.
To put it briefly, the legacy system did not account for missing or bad data. On top of that it did not send any notification that an issue had occurred.
My new design, would first detect missing or bad data based on preset metrics (which could be updated later).
As seen in the service flow below, if bad data is detected, the records are flagged and the end-user is notified allowing them to take action.
Design - Proof of Concept
A proof of concept to demo to leadership and the app-dev team for feedback was made.
In red are transactions that couldn't match an Asset in the system (either by Asset #, VIN, or license plate).
In the previous system, these records would not have been imported at all.
Design - New View
The new view allows users to fix bad records, like a mismatching asset #.
If a user needs to fix multiple records for the same vehicle, they will only need to resolve one and the system will detect the others.
Further, the system will now associate the mismatched number with the Asset selected so going forward the user will never need to fix it again.
Recording of the workflow to fix a record that couldn't find an matching vehicle in the system.
What went well?
The time app devs were spending to fix data after an issue occured with the third party was drastically reduced. The easy to understand workflow/UI allowed support agents to field a lot of the questions.
The internal training seminar I lead to train the client trainers how it works went really well too.
What could have gone better?
As previously mentioned, the reason why this was an issue in the first place was a sales rep who decided to design and override the design/dev team.
Their version was first sold in 2011.
My version released in 2019 after I started at the company in 2017.
That's a solid 8 years of our system not better handling data import issues and pissing off customers. That should have never happened.
In addition, if the SWE team was more available some of this functionality could have been implemented in the backend for better performance with large data sets.
Case Studies
Easily access library materials on mobile devices with WorldCat Find.
Impact :Collaborated with product management and engineering to scope, drive alignment, design and launch iOS and Android app in 8 weeks.