Marathon Pilot Patrol
How it got started
The Pilot Patrol Dashboard was part of the whole Marathon Pilot Patrol project. This portion was web-based created for OneCall specialists who were based at Marathon Headquarters.
The team for this project consisted of a Technical Architect/Project Manager, 2 Developers and an Application Designer.
My role as Application Designer was:
Assist development in application workflow
Wireframe / create medium fidelity prototype
Engage with client to gather feedback/insight
Document UI for developers
While we were on site with the client, we took the time to put marker to whiteboard and start figuring out the what information was key for pulling reports, tracking invoices and tracking pilots while aerial inspections were happening.
During this brainstorming process, we also learned about how it can be quite stressful for these employees. Every 45 days they have a government official hovering over their shoulder making sure they are in compliance, as well as being bombared by calls from the FieldOps employees inquiring about the locations of planes or if they area was going to be inspected that day.
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. Originally, this group had several different tools they used to pull together the information individuals were inquiring about. With new dashboard linked to the Pilot Patrol App, they had one spot where they could pull reports, see if they were in compliance and track invoicing.
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 our goals. 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.
Once I got the wireframes pulled together, we got them in front of the OneCall Specialists. This was bare bones testing, as the main focus (and budget) was on the pilot app. I gave them access to the URL and asked them do simple tasks which based on daily requests from pilots, fieldops and as well as management. There were a couple of places that needed work which I quickly reworked while we were in the session. This was all done remotely using a GoTo meeting.
The seemed to be excited about having everything in one place and didn't have any issues of finding what they were looking. I made sure to keep wording them same that was presented in their other apps, so training could be kept to a minimum.
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 dashboard was clean and easy to use. The OneCall Specialists excitement about this definitely put a smile on my face and gave me that validation.