A project during my time working as a Design Researcher at Caterpillar Inc. This project was completed for Kiewit, one of Caterpillar's largest customers. This project was part of a larger interest from Caterpillar regarding the Industrial Internet of Things, or a digitally connected jobsite.
Andrew Kunk – Design Research / User Experience
Karan Patel – Business / Information Systems Management
Manasa Bandapalle – Computer Science
Don Bergh – CatLab Director
Samantha Melchiori – Caterpillar Digital / Analytics Site Director
Machines are running out of fuel and sitting idle, creating a backlog and ripple effect of delays, ultimately bringing projects over budget and behind schedule.
Prevent equipment from running out of fuel.
Better documentation of fuel usage records– How much fuel each machine used, and when?
A scalable solution that Kiewit could use on other jobsites, and a product that Caterpillar could offer to other customers.
An iPad based digital solution providing machine location and fuel level heatmaps to visualize areas that need fuel urgently, machine tracking and search to help find missing machines, and automated documentation of quantities of fuel and fluids dispensed to each machine.
This project takes place on a 50 mile stretch of highway construction outside of the Dallas Fort Worth Airport, specifically TX-HWY 183, also known as the Midtown Express. Already behind schedule, and nearly over budget, the issue of machines running out of fuel was part of a much larger problem of effective site management for such a large job site.
The site features about 900 pieces of heavy machinery working on dozens of smaller projects within the larger job. This massive fleet of excavators, dozers, graders, dump trucks, cranes, rollers, light towers, and other specialized equipment is moved around to crews working on different tasks, such as grading, drainage, structures, and paving. Due to the expensive nature and limited supply of these machines, the goal is to maximize machine utilization by having every piece of machinery being used each shift, so that extra machines can be transported to be used at other job sites. Because these machines are so expensive, sometimes costing as much as $1m to purchase, as well as the cost of regular maintenance, Kiewit determined that it is actually more cost effective to keep them running constantly and making progress on completing jobs, than it is to keep extra machines at each job site sitting idle and waiting to be used.
This goal of nearly 100% machine utilization is important in understanding the structuring of the workflow throughout the project. There are day and night shifts, each 12 hours long, allowing work to be coordinated around typical highway traffic patterns. There is a Machine Transport team that facilitates moving these machines back and forth across the job site every shift, and Machine Operators, Foremen, Superintendents, and Civil Engineers usually move together as groups based on their area of specialty.
These machines are fueled by Fuel and Lube Technicians who drive a fuel truck around the site refilling machines with off-road diesel, hydraulic fluid, motor and transmission oil, grease, and performing other in-the-field services. The Fuel Tech drives across the job site every shift, ideally fueling every machine before or after being transported. However, between these machines burning fuel quickly, and being moved around often, the Fuel Tech often misses machines, resulting in emergency calls from Machine Operators for fuel.
We kicked off the project with interviewing the Fuel Foreman responsible for overseeing fuel consumption and distribution on the site. We also spoke with Caterpillar engineers who worked on previous products involving telematics and fuel reporting. After several calls, and reading through lots of documentation of previous products, we used an Activities, Environment, Interactions, Objects, and Users framework to get a better understanding of all of the different components of the problem.
Our findings are summarized as follows:
There are usually two Fuel Technicians working during each shift, and it is their responsibility to make sure every machine has fuel. Additionally, they are required to keep records of how much fuel they give each machine, for tax purposes, however, many of the Fuel Techs do not do this. Despite each Fuel Tech fueling about 100 machines per shift, they still receive emergency calls from empty machines multiple times per shift.
An empty machine causes a backup of delays. Not only can the empty machine not work, but there are often other machines delayed working with it. For instance, if an excavator runs out while filling 5 dump trucks, all 5 of the dump trucks and their operators also sit idle. Sometimes there may even be a dozer sitting idle waiting for those dump trucks halfway across the site.
The technology that is available on the job site is not capable of accurately tracking fuel consumption. Some of the newer Caterpillar equipment has telematics functions, reporting location data, machine hours, and other metrics including approximate fuel level. However, not only is there a mixed fleet with equipment from other OEMs, using proprietary telematics platforms, but many of the machines are old and have non-compatible telematics. Many older machines don't have any telematics data at all.
The data that these machines are putting out is not always accurate, many of these machines only update their telematics every 12–24 hours, and won't update at all if parked under a bridge or if the battery is low. With so many changes occurring during each shift, these machines could be 50 miles away by the time they update their location data. Some machines send their data to Caterpillar's platform VisionLink, and others sync to Kiewit's Management Portal software. Besides the issue of using several telematics platforms, the data that is collected is not easily accessible, especially not in the field. These applications aren't accessible on a mobile device, and there is no way to determine exactly what platform a specific machine would be reporting to.
The larger job site management teams and superintendents usually know roughly where machines are, but most of their planning and tracking is done on paper and whiteboards. There are lots of uncertainties, many different users, and tons of errors that prevent better tracking of machines. Oftentimes, a problem will arise and a crew will need a specific machine transported mid-shift. Sometimes they will make the proper calls to management to request it, however, usually during the night shift or when very busy, they will just call other crews to see if they can borrow one. To make matters worse, if the machine has rubber tires they will even drive it along the highway to where it needs to go, keeping Management, the Transport Team, and Fuel Techs completely out of the loop. Being spread out across several fleet management software, engineering planning software, permits, regulations, and planning, site management is chaotic. Even with strategic planning, incidents come up, schedules change, and crews need to improvise and pivot.
We spent some time reviewing our findings and thinking about the scope of this project. We saw a potential need for a larger site management platform, a way to streamline the spread of information from the office to the field and back. However, we had to trust that Kiewit and the site management and engineers understood their jobs better than we did, and we understood that completely disrupting their workflow might cause more problems than it solved. Focusing in on the Fuel Technician, we identified what we believed were the biggest challenges they faced, and crafted a hunt statement to focus our research and development moving forward.
On large construction sites, it's essential to maintain equipment fuel at an operable level to ensure productivity. The Fuel Technician Driver responsible for this has limited access to live equipment location, fuel level and operation status. Due to this, the driver has to manually search for equipment to refuel, which is slow and inaccurate. We would like to maximize the productivity of Fuel Technician Drivers and increase the effectiveness of the refueling process to eliminate machine downtime and unnecessary fueling. This will ultimately reduce costs for the company and facilitate accurate record keeping.
We began using our initial findings to map out the Fuel Technician's journey throughout a shift. We focused on the necessary actions performed every day, identifying pain points and areas of opportunity that could address issues we learned of on the call. We made assumptions about the steps a Fuel Tech could logically take in an effort to understand possible strategies. We explored ways this process could be streamlined, trying to eliminate unnecessary steps, and thinking about what features could potentially help the Fuel Tech work faster and more effectively.
Fuel and Lube Technicians have a high turnover rate, despite being a specialized job with specific license requirements. We began putting together User Personas that covered a range of experience levels that might be found with experienced existing employees, as well as mid-range based on our findings from initial interviews.
We took a trip to Dallas Texas to interview some of the stakeholders and shadow a Fuel Tech during a shift, riding along with him for 12 hours. We met an experienced Fuel Tech named Alejandro. Alejandro has been a fuel truck driver for 17 years. He's in his 40s, and immigrated to the U.S. from Mexico with his family. He doesn't speak much English, but has a friendly personality, and good relationships with the machine operators on-site.
Having been on this job site for about 8 months now, Alejandro is familiar with the work being done on each location. He mentally keeps track of which machines were fueled recently, and will skip machines he knows are full. Although he's familiar with the machines, Alejandro often has to spend a lot of time manually checking the fuel levels of machines when operators are not present. Sometimes he'll spend 20 minutes trying to drive to a machine, only to find that it doesn't need fuel. He gets a lot of phone calls from machine operators and the fuel foreman, which he has to attend to while navigating through traffic. He uses the phone for calls, but is unfamiliar with technology otherwise. However, he's open to learning new things.
We used a Who What Where When Why How framework to document and understand our findings. Identifying what and how behavior, technology, and site-condition barriers impact Alejandro and other users throughout their shift, and using these barriers to inform an initial feature list, sorted into Must Should and Could categories.
We also began classifying the steps that Alejandro and the other Fuel Technicians had to complete every shift in order to do their jobs. These task could be sorted into the following categories and subcategories:
To better visualize the workings of the site, we created a map of the job site, and pulled in fueling locations from the trip using the location data in our photos. We started mapping out Alejandro's route, and began running through sample scenarios, testing possible features along the way. We explored different technology that could be utilized to capture the necessary data to provide fleet fuel monitoring across the many machines across the job site.
Trying to avoid jumping to a potential solution too quickly, we explored a variety of ways to directly address user needs. This allowed us to get an idea of what technology implementations would be necessary, and compare them to the information and tools available.
Can we group machines into smaller zones to make it easier to find them, and have Project Managers update the locations on a digital platform?
Can we use better signage to help Alejandro find site entrances on the side of a 65mph highway?
Can we require Machine Operators to report their machine fuel level at the beginning and end each shift, and forward that information for Alejandro to better plan his route?
Can we put an RFID tag on each machine's gas cap, and a reader on the fuel hose to record what machine was filled and when to predict what machines might run out first?
Can we produce a battery powered, GPS transponder to put on every machine to report its location?
Can we use Bluetooth LE towers spread across the site zones to transmit local machine GPS locations and fuel data?
Can we use employee issued company phones to upload photos of fuel gauges and GPS information?
Can we integrate with the Fuel Technician Department of Transportation required telematics through the fuel truck?
Using the diorama as a presentation tool, we were able to walk through scenarios with stakeholders and engineers from Kiewit and Caterpillar to gauge the feasibility, desirability, and viability of the different options and their technological development requirements. Both companies wanted to pursue creating a digital mapping and accurate fuel reporting tool, and were open to exploring whatever technology implementations would be most effective to facilitate that.
After focusing in on using a digital solution, we began exploring what the different interfaces would look like, and how the information architecture and functions of the app would correlate with the Fuel Technician's workflow. We knew that the primary functions would be mapping machines and recording fuel dispensed, but how would that information be visualized most effectively, and how could interaction and usability be streamlined and improved? Additionally, were there other secondary features that would solve smaller pain points for the Fuel Techs?
At the same time, we identified a very real safety risk from having Fuel Tech Drivers answering their phones while driving. We knew we needed to utilize safer forms of communication for the drivers, and the communication channels had to be just as easy and effective for the Machine Operators as making a phone call, otherwise they might revert back to making a call. We found that using an iPad or Tablet mounted in the vehicle would provide the best interface for mapping machine locations and navigation, and the dashboard mount would force phone calls to be hands free. The larger display would also be easier to operate in gloves when searching for machines numbers or entering fuel quantities.
We aligned the key actions of Pre-Shift, Driving, Hunting, Fueling, and Documentation with the different screens of the layout, tailoring the information shown at what stages, particularly not overwhelming him with too much information.
We put together a variety of other potential features that could accompany the core app functionality. These were made into card format to be placed along the route of the diorama during usability scenarios. Additionally we performed card ranking and sorting exercises to prevent feature creep and to establish priorities of needs.
We began designing layouts, with requirements of displaying machine locations well at a far distance, as well as providing more information as to what machine each pin represents when displayed on the map. We explored different views that would auto populate nearby machines so that the Fuel Tech didn't have to tap through different machines to find the one he wants.
We went back down to Texas, this time to conduct ride-along research with a few other Fuel Tech Drivers, as well as to interview other key stakeholders in the office and field. Our primary goals were to uncover any important variations in needs that might occur with different Fuel Technicians, and to get feedback and gauge the effectiveness of potential features and app prototypes.
We brought with us sets of feature cards and print mockups of the tablet to get some early feedback from the Fuel Techs, as well as share our progress with stakeholders. Using the feature cards we asked Fuel Techs to sort features based on how helpful they were for them. Walking through the mockups, we got a better understanding of how the Fuel Techs interacted with the layouts. I put together an in-depth field research guide that included sample questions to better facilitate the feature card sorting and a structure for usability testing to take more specific notes while conducting interviews.
We met with several Equipment Managers and Engineers who oversaw the strategic movement of pieces of equipment across the site to learn more about how they keep track of everything, and what technology tracking they would like to see. They had lots of great information on what features they already use, and what they would most benefit from. We spoke with a Fuel Foreman to better understand his job, and what process he uses to keep track of the Fueling Team and report their progress to other disciplines. He had the most direct understanding of the problems the Fuel Techs face, and saw how the lack and limitations of the digital site management impacted his drivers. We learned about what strategies they use to work effectively, how they determined what machines to fill, how they respond to calls. We learned about key differences between the different Fuel Techs, and how some drivers put more effort into different parts of the job.
However, the best way to really understand Alejandro's job and needs is through seeing him in action.
Using new findings from a wider variety of users, and a better understanding of the key actions of the Fuel Technicians, we mapped features that would occur during each task. Breaking the process into 8 tasks, we created journeys of an entry level, mid-level, and experienced Fuel Tech. We explored different Thoughts and Actions each Tech might have during each step. We noted instances of User Error, Cognitive Load, Physical Load, and instances of a Fuel Tech doing too much work or too little. We evaluated information that the user would want to know, actions the user would want to do, and instances when the user would want to go to a specific place.
Some of the final findings we took away from the previous highly specific journey mapping, as well as direct feedback from users on our trip to Texas, was used to inform the final versions of high fidelity mockups. We learned that we needed to make the interface accessible to users who speak different languages. English and Spanish were most commonly spoken on the job site, but Caterpillar equipment is used globally, and the software could be used anywhere. We found that drivers understood icons slightly better than text boxes, and when combined with instructional tutorials they had a stronger understanding. Having to teach the drivers how to use the app was definitely not ideal from an intuitiveness standpoint, but technological literacy was low among this group, and introducing common mental models of pinch and zoom, swiping back, and searching were among the primary goals.
At this point, the general layout was locked in. There would be several "mapping" focused views, as well as several "list" or "search" focused views. The modifications we needed to make were more about layout and app navigation, how the drivers could efforlessly move to different features of the app, and making that architecture intuitive without language barriers.
The primary feature of the application is the mapping and navigation. The Fuel Tech Driver is presented with a Heat Map displaying where higher concentrations of empty machines are located. This provides them with useful information about where they should go first during their shift, but also empowers them to make the decision themselves, balancing data inputs with their own understanding of the jobsite on that particular day. The reason for this less specific, less AI driven approach to mapping machine locations, is due to the potential uncertainties around the accuracy of the machine location and fuel level data. Additionally, because so much of the job site is not managed through a data driven telematics platform, having Fuel Tech Drivers rationalize their own priorities gives them much more freedom to make executive decisions based on a conversation they may have had with management, or a specific need of a driver, rather than being forced to follow a specific route given to them by the app.
However, we also use the app to circumvent traditional streams of communication in the interest of safety. We implemented a Emergency Call for Fuel feature, allowing Machine Operators and Foremen to submit last minute calls for fuel without bothering the driver with a phone call. This takes the phone out of the driver's hand, and instead displays the information on the tablet, preventing the Fuel Tech from having to remember a machine type, number, and location at inopportune and dangerous times.
Finally, we streamlined the Fuel and Fluids dispensed recording process. Instead of recording machine numbers and quantities in a notebook, or completely ignoring the fuel recording process entirely, Fuel Tech Drivers can quickly type in numbers through the app. Using a list populated with machines in close proximity, the Fuel Tech can quickly input gallons dispensed, as well as checking off what other fluids were dispensed, giving him a general idea of what fluids aren't necessary to check.
The biggest issues that we improved were:
Finding Machines: Alejandro struggled to find all of the machines on his route, and wasted a lot of time manually checking machines that didn't need fuel. He paid attention to what he had recently fueled and when, but still was redundant.
Answering Calls: Besides being dangerous to answer his phone while driving, Alejandro would often times get an urgent call for fuel 50 miles away, interrupting his current route and requiring him to turn around and navigate across the job site before returning to his normal route.
Recording Numbers: Alejandro used a pencil and paper to record fuel quantities and machine id numbers, and the gauge on the back of his truck only reported total fuel dispensed, requiring him to remember the amount before fueling and calculate the difference after. He didn't record other fluids, instead remembering specific machines.