Rig Life!

To truly understand the petroleum and natural gas industry, it's essential to leave the office and immerse yourself in the environment (FIG 1A). I needed to speak with the users and experience their daily routines firsthand. To prepare for this, I packed my bags, bought steel-toed boots, and was issued fireproof coveralls. During my visits, I received a tour of the rig to see how everything came together. I was excited to head out to a live platform, as it's a part of the oil industry that you don't often see. I spent time with the engineers while they used a beta version of Cadence, asking questions and observing their work. After completing a nine-hour day shadowing one of the Field Service Engineers (FSEs), I returned to the office with a comprehensive understanding of the challenges they face.

Where to Start?

I began by setting my goals for the project. The software needed to be easy to use, allowing users to focus on their tasks. Working on a rig can be stressful, and adding a 12-hour shift seven days a week for six weeks, while dealing with complicated software, is not what I wanted for our field service engineers. My objective was to focus on the pillars of good design: usability, equity, enjoyment, and usefulness.

I started by sketching out ideas, making notes, and reviewing some of the sketches with subject matter experts (SMEs) in the office (see FIG 1B). This provided a quick way to ensure that I understood the problems that needed to be solved and that I was communicating with users effectively. The oil industry follows a strict step-by-step approach to most processes, and deviating from these steps can have catastrophic results.

Once I confirmed that I was on the right track, I began the wireframing process (see FIG 1C). The end product would consist of interactive prototypes that I could test with real users in the office, as well as present to stakeholders and my team to gather feedback.

Before implementing Cadence, the 25 apps required to operate the bottom-hole assembly (BHA) were not usable, equitable, or enjoyable. The existing process required users to collect a data point, perform some calculations by hand, enter the result into another app, and then input that final sum into yet another app. I found this workflow to be unhelpful, and it needed to change.

Usable

We aimed to create navigation that was easy to follow, requiring minimal training to bring both existing users and new recruits up to speed. However, this was challenging since we had to work within the established structure. With a team of four UX designers, we met daily to discuss our progress and ensure we were consistently using the same design patterns to complete tasks.

Equitable

One challenge in the oil industry is that field workers are predominantly male, and men have a higher incidence of color blindness. We addressed this by selecting colors accessible to those with color blindness, and we took into account factors like text size, text color, and warning screen text colors. When a prominent red warning appears, we want all users to notice it, as that typically indicates a serious issue requiring immediate attention.

Enjoyable

Cadence is the software that field service engineers (FSEs) must use, and it was crucial that it be enjoyable to operate. We considered this aspect with each feature we added. I often asked myself, "How would I feel after 11.5 hours on a Conex box in the middle of nowhere?" Would I end my shift wishing for better options to control the BHA? Would I consider quitting for a company with better software? Many workers leave for this reason; my aim was for FSEs to feel comfortable using Cadence, making it feel intuitive and reflective of the way they perform their jobs.

Useful

Perhaps the most critical area that required improvement involved ensuring that FSEs could accomplish each task with minimal cognitive effort. The team tested designs with FSEs who came into the office between deployments to provide honest feedback. They were the most straightforward group I have ever worked with when it came to software testing. When we got it right, they would let us know, and they also provided constructive suggestions for any features that needed improvement.

Final Deliverables: Auxre Prototypes.

Once I had all the requirements for a feature, I would build my wireframes and start to build interactive prototypes for each feature (Fig a).

To show a broader audience, I created a prototype to accompany the wireframes and final art. The prototype was meant to demonstrate the mechanics of how accessories would appear on the screen. To the left, you will see a short video of how it worked. The prototype was instrumental in collecting quality feedback about the interactions.