To comply with my non-disclosure agreement, I have omitted and obfuscated confidential information in this case study. The information in this case study is my own and does not necessarily reflect the views of JB HUNT
Fuel Estimator is an application that estimates fuel cost for Train or Truck or both to serve customers with their unique and customized requirements. The application uses a formula to calculate the price based on the national fuel rate. It has a dependency on the Pricing system.
Time Frame: The time frame was about a total of 3 sprints (6 weeks) to complete from the initial research till the MVP for testing.
My Role: Being a hands-on user experience designer, I was asked to build a modernized version of the legacy system through extensive user research. I worked closely with the user researcher, SME, Product Owner, and Engineering Manager.
Process
Empathize
Stakeholder Interview
I created a list of stakeholder questionnaires to gauge the purpose/vision and goals for the application.
User Insight and System understanding
A dedicated system is there to store and manage all the customer fuel data that helps the rating engine rate effectively. However, the user still needs to spend hours validating, uploading, and managing data using the system. More manual work leads to human error. Furthermore, the user needs to key in data every week for selective customers manually.
• Searching the template is complex. The user needs to remember the actual name of the program.
• The system is not capable of automated validation.
• The user searches for the same program in two different systems.
Legacy System Study
The legacy system lives isolated from the pricing application. As a result, the agreement data doesn't flow from pricing to the fuel surcharge system. The following usability issues are equally prominent.
Broken Search: The fuel system has a broken search mechanism.
Complex form: The digital form to include the calculation method is not user-friendly, and new users can't operate without extensive training.
Navigation: The site map is narrow and deep, which results in many unnecessary clicks. The user loses their trail back to the origin due to the absence of a proper navigation system.
Expert evaluation done on the existing system
Existing Workflow
A sense-making framework to document the sequence of events starting to end representing actions performed by the user. The flow describes the complex path user takes to successfully author a fuel program and tie it to an agreement. The system's automation capability falls short when it comes to customer's variety of requirements.
The workflow helped understanding the cause and effect of interrelated elements
There are three significant ways to associate the fuel program with an agreement. The visual representation of steps shows the high-level idea.
• The user receives a request to attach the fuel plan to an agreement.
• The user needs to update the Fuel percentage rate weekly for the customer for the system's incapability to calculate the customer's unique calculation rule.
• Create a new section in the agreement for truck and train load that uses a different mileage program than the other section.
DEFINE
User Persona
With the help of the User researcher team, I consolidated the archetypal description of the user behavior pattern into a user representative profile.
Journey Map
Interviews with users gave me an in-depth understanding of the user's journey. Based on the data, I sketched out a probable journey towards associating power estimation. Three scenarios allow the user to get into the application and create or edit the Fuel program.
The journey map helped visualize the user's experience through a series of events for creating a fuel program successfully.
How Might Wes
I along with my teammates converted into question when heard something interesting during the stakeholder and user interview. Then we organized the notes into groups together and gave each group a label. Ease of use, source of fuel average, task notification, calculation, system setup are a few examples of many groups formed out of how might we notes.
We used dot voting to prioritize the notes and to skip lengthy debates. Two HMWs were short-listed with the participant's and Product owners' vote.
Proposed workflow of the modernized system
Simplified version
The simplified version shows the way of mapping the customer given date with the date range to pick up the DOE fuel price and apply the formula to it.
Hypothesis
I believe that leveraging the system's computation capability would stop the company's vast ramifications caused by human error.
I'll know that I am right when the system can accommodate and execute all kinds of unique and customized computational requirements successfully with minimum human intervention.
IDEATE
White boarding
Whiteboard ideation
Calendar - Legacy System
Calendar allows the user to control what to use because the agreement with customers doesn’t update weekly—May update monthly, every other week, once per quarter, etc.
•User manually defines the calendar within/outside the application from the verbiage of the fuel agreement or receive a spreadsheet from the customer.
•Users may create the calendar for two or three years if the rules are clean and easy. In general, the minimum setup is one year.
•User manually defines the calendar within/outside the application from the verbiage of the fuel agreement or receive a spreadsheet from the customer.
•Users may create the calendar for two or three years if the rules are clean and easy. In general, the minimum setup is one year.
Calendar - Modernized Application
The user enters the formula to allow the system to generate the calendar.
Calculation Method - Legacy System
Pain Point
Complex form: The digital form to include the calculation method is not user-friendly, and new users can't operate without extensive training.
Calculation Method - Modernized Application
Increment - Legacy System
Pain Point
Manual : The difference between the fuel's begin and end price needs to be consistent, and the user does the job manually in the present world, which takes between 15 minutes to one hour.
Increment - Modernized Application
System validates the inconsistency and highlights the same.
Negotiation with the business
The business agreed to implement:
• Business agreed to implement the process of validating and identify the inconsistency.
• Restructuring the form by breaking into meaningful steps.
• Merge the application with the system that maintains the customer agreement.
Ballpark:
• UX proposal for automating the process of validating and resolve customer price range was parked for Phase 2.
• System creates the customized calendar.
• System accommodates all the variances in the program setup.
PROTOTYPE
Wire-framing
The entire process is broken into 3 steps: search and assign the customer agreement to the fuel program for a time period in the first step; define the detail and method of the calculation; and mention the price basis and region.
TEST
The usability test for the Fuel calculator modernized design scored 84.2 on the System usability scale of 100.
The ball-parked list is open for discussion again for the phase two scope
Ballpark:
• UX proposal for automating the process of validate and resolve customer price range was parked for Phase 2.
• System creates the customized calendar.
• System accommodates all the variances in the program setup.
