Problem for the Business

The company needed to address the problem of non-compliant drivers uploading random photos in place of proper photos of their truck. Our company had been randomly selected by the Department of Transportation to be audited for how closely we follow the safety and compliance requirements. This was when the business requirements really kicked our butts.

“I don’t care if they find it annoying, it is their job! If I could do it, they can surely figure it out.”

-Lauren Wilson, Former Driver and Current Safety & Compliance Manager

Gathering Requirements

We must implement features that force drivers to physically inspect their vehicle.

Researching the Guided Inspection

To address the issue of non-compliant drivers, we needed to restructure the DVIR in a way that would guide them through the inspection with easily digestible steps. We decided a guided inspection would force the drivers to go through a step-by-step inspection of their truck. This would have the drivers take closer to the expected 15 minutes for the inspection.

I did a competitive and comparative analysis on how other companies structure guided truck inspections. I cross referenced the parts listed on the paper DVIR with other guided inspections and categorized them into easily identifiable sections of the truck.

This is an excerpt of the document I created to organize the guided inspection. The full document can be found HERE.

I organized a meeting with the company mechanic as well as the company Safety and Compliance manager to verify the accuracy of my findings.

Rapid Prototyping

Keeping the user and business requirements in mind and utilizing the research I had done on guided inspections, I ideated two guided truck inspection designs to present to the team.

Iteration 1
Iteration 2
We decided on the second design since it forces the driver to go through each truck part one-by-one and gave more visual feedback on what parts were marked defective.

Passing to Developers

I regretfully didn’t have the time or resources to test my designs on drivers, as the audit deadline was approaching. I had to quickly pass my designs to the developers.

As a former developer, I knew that uploading artboards to Zeplin wouldn’t be enough. So I made detailed flow diagrams on Sketch showing all possible user flows and how screens are linked for each major functionality.

User Acceptance Testing

After the DVIR was fully developed, I led an User Acceptance Testing (UAT) session consisting of 5 new drivers and 2 current drivers. Since a group UAT presentation would give less valuable feedback than sitting down with each driver individually, I enlisted the help of 3 of my teammates to assist with user testing.

I created a user testing guide to obtain consistent data for the features I want to test. The user testing guide compiled with all the answers we got from each driver can be found HERE.

Overall, the app was well received! 4 out of 7 liked the guided inspection and found it as a helpful reminder for all the truck parts they need to check. The other 3 found it a bit extensive, but understood that the intention of the design was to enforce compliance.

“For someone who has no background in trucking, you did a really good job on making an easy to use inspection.”

-Armando Rosete, Company Driver

However, we did discover two major usability issues:

The Launch

We successfully launched the DVIR portion of the app on April 23, 2018. It was met with little to no complaints. It helped benefit the company in multiple ways:

1. It gave better visibility for driver managers to keep track of non-compliant drivers
2. Mechanics can now see ahead of time when a truck needs maintenance
3. The company can confidently pass the DOT audit by showing all the electronic DVIR’s the drivers are submitting

Learnings

Despite the successful launch, there are a lot of things I would’ve done differently if given the time and resources.

• I would’ve made sure to test and confirm my design decisions on drivers BEFORE development.
• Having my designs developed first and THEN user testing defied my ideal process. The time constraints really made it hard on me, as the only designer on the team to get proper testing done.
• Similarly, I would’ve wanted to complete UAT much sooner
• Since we had to give time for development, UAT was held 3 days before the launch date. After UAT, there were some UI issues I wanted to fix that couldn’t be fixed in the first release of the app because of this time crunch
• Having been on the developer’s side before, I sympathize with their struggles and understand there are often more important things to fix than UI. So I had to reluctantly forgive a lot of minor UI issues.