Role: UX Designer

Duration: Oct 2017 - June 2019

Platform: Responsive Desktop SAAS App

Vehicle Fuel Data Import

I took the initiative to design a framework to better handle importing thousands of re-fueling transactional records. these records came from third party organizations that tracked every time a vehicle filled up at a gas station using an assigned card.‍

My design addressed issues such as creating bad data or not importing all relevant data.

Demonstration of the workflow recorded in the desktop application. Here you can see a user correcting a record that failed to match an vehicle to an imported transaction.

Outcome

Roughly 35% of our customers have at least 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.

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.

01. Create a support ticket with engineering.

❌Agile SWE may deprioritize the task. It may not start work until 6 months.

❌Any future issues would require SWE as app dev and support agents do not have backend access.

02. Design a solution to improve the middleware's functionality.

✅The issue will never require app dev time to fix going forward.

✅Reduces support ticket open time for this issue.

✅Easy for app devs to add future functionality

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.

What went well?

The time app devs were spending to fix data after an issue occurred 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.