Marathon Pilot
Patrol App



How it got started

Marathon was in desperate need of a more efficient way to collect and distribute information from Right of Way Inspections (ROW) which are federally mandated to keep pipelines operational and safe.

Being a business tool, this project had a small but important group of people it needed to work for. This group consisted of pilots and field crew members (aka field ops). Each had their unique needs which we were able to meet by creating a GIS app for the pilots.

The Team
The team for this project consisted for a Technical Architect/Project Manager, 2 Developers and an Application Designer. 

My role as Application Designer was:

  • Conduct user interviews

  • Simplify findings down one page personas/day in the life of

  • Assist development in application workflow

  • Wireframe / create medium fidelity prototype

  • Engage with client to gather feedback/insight

  • Design UI

  • Document UI for developers


person team


development approach


days to complete

My Process


I conducted user interviews on-site with 20 different employees involved in this aspect of Marathon’s business over the course of 2 days.

The employees where split up into 4 different groups; all pilots, all field crew members, all OneCall specialists, and the last group was a mix of each of these roles.

I chose to split the users up in this manner, so I could hear specifically their issues related to their jobs. In the mixed group, I felt it was good for them to hear each other opinions, pain points and what was working for them. This allowed us to see if some of these issues could be solved merely by communication versus adding a feature to an application. 

At the end of the interviews, I was really surprised to find how archaic this whole process was considering the magnitude of responsibility these folks had in keeping the communities safe along the pipelines.

Here’s a snippet of what I asked the users during the interviews and a copy of the personas/day in the life of.


While we were on site with the client, we took the time to put marker to whiteboard and start figuring out the what information needed to be collected and how the user would navigate through the app. 

During this brainstorming process, we also learned about technology limitations and equipment needs that we needed to make accommodations for. In this instance, we learned that Marathon had a very specific device in mind (ToughPads) which employees would use while doing inspections. We also determined that we needed a GPS unit, digital camera and special connector so all these devices could be connected together to for gathering data and keeping it connected to the same event. 

This was great process, because the client felt involved which allowed us gain their trust even more. 


I typically start the design process with quick, not pretty at all, sketches. This is the way I iterate through many ideas quickly and weed out the ones that don’t make sense.

Sketching is merely for me as my team and client were distributed across a few different states. I get into the nitty gritty details in wireframes.


For this client, I created medium fidelity wireframes using Axure. Medium fidelity? The wireframes are “functional” in the sense they allow the user to move through the app by clicking. They also show content options or where data is collected or populated. They are not aesthetic pleasing. I keep the styling to a minimum. 

I take this path, because this forces the customer to focus on functionality and what data needs to be collected. My experience has taught me the more polished graphics you put in the screens the more the customer will focus on those graphics than making sure we are meeting project and business goals.

Here's what I created.

User Testing

Once I got the wireframes solid, a developer helped me create a very bare bones app to place on the ToughPad for field testing. Since none of us on the team have ever had to do tasks in a single engine plane on tablet, we need to get up in the plane to see if we had was truly viable.

Before we jumped into the plane, we did do ground testing to make sure all the equipment (GPS, ToughPad, camera) worked together as we expected so not to waste air time.

After an hour of flying around, we found out we needed to rework a few things in the interface. The main problem was the app need bigger buttons. Single engine planes are not the smoothest rides, the bouncing around made it difficult to hit the input fields and buttons. 

Disclaimer: I didn’t fly. Bouncy single engine planes are not my thing. 

UI Design

Once we tested out all usability mistakes, I started designing the final screens in Photoshop. The style of the screens follow the branding guidelines of Marathon Oil. There was no ability to deviate for their brand standards, which I completely understand. 

The design of this app may seem clunky to most folks, but the app was a big success for the pilots and their observers. They found it easy to enter the data they were collecting during flight and cut way back on errors.

Non Interface Design

We didn’t forget about the FieldOps folks during this process. After interviewing them, we determined emails sent to segmented lists were the best way for them to get the information they needed. So in the app, we built in Geofencing. In the background while observer was collecting data, the application would send out emails to alert the FieldOps personnel when the plane was entering a zone and leaving a zone. They would also receive emails about incidents along the path that needed to be checked.

1000' to 20'

increased accuracy of incident


decrease in FieldOps calls


reduction in duplicate reports