Understanding the Domain

Rig Life!

To truly understand the domain of the petroleum and natural gas industry, you must leave the office and dive into the environment. I needed to talk to the users, to see what their daily hustle was like. I wanted to see what exactly the various jobs entail. So bags were packed, steel toes where bought, and fireproof coveralls were issued.

During my visits, I got a tour of the rig to see how it all comes together. I was excited to head out to a live platform since it’s a part of the oil industry you don't often see. I sat with the engineers while they used a beta version of Cadence and asked questions and observed. I completed my 9 hour day shadowing one of the FSE's and returned to the office with a holistic understanding of the challenges that the FSE's face.

Where to start?

As I have done in the past, I set my goals for this project. The software is easy to use and allows the user to focus on their job. A rig can be stressful, and adding in a 12-hour shift seven days a week for six weeks and fighting the software isn't what you want your Field Service engineers doing. I wanted to focus on the pillars of good design that are: useable, equitable, enjoyable, and useful.

I put pen to paper to sketch out ideas, make notes and review some of the sketches with the SMEs in the office. This was a quick way to make sure I had an understanding of the problem that needed to be solved, as well as make sure that I was communicating with the users in a way that made sense to them. The oil industry has a step-by-step way of doing most things. Those steps are not deviated from as the results can be catastrophic.

Once I knew I was on the right track, I would start the wireframing process. The end product would be interactive prototypes that would be used to test the feature with real users in the office, as well as show it to stakeholders and my team to get feedback.

Prior to Cadence, the 25 apps that were needed to operate the BHA were NOT useable, equitable, or enjoyable. Having to take a data point, do some math by hand, then put that number into another app to perform a calculation, and then take that sum and enter it into another app isn't really useful, in my opinion. The UX designers task was to change that.

Useable: We wanted to have a navigation that was easy to follow and would need minimal training to bring an existing user or a new recruit up to speed when I started on this project that was in place. The challenge there was to work within that structure. With 4 UX designers, this meant meeting daily to discuss what we were working on and to make sure that we where all were using the same patterns to complete tasks.

Equitable: One of the challenges that the oil industry faces is that the field workers are mostly men. Men have a higher percentage of color blindness. We would address this by using colors that people who are color blind could see. We took into account text sizes, text color, warning screen text colors, ext. When the big red warning comes up we wanted that to be seen by everyone since that is generally a bad thing and could mean it's time to run.

Enjoyable: Cadance is the software that the FSEs (field service engineers) have to use. To me, this means it needs to be enjoyable to use. We considered this with every feature we added. The question I asked myself is " How would I feel after 11.5 hrs on a Conex box in the middle of nowhere?" Would I end my shift thinking that I wish there was another option to control the BHA? Would I quit and find another oil company with better software? Leaving to go to another company was a common reason for workers quitting. My goal was for the FSEs not to give using Cadance a second thought. It should feel natural and reflect how they do their jobs.

Useful: Perhaps the biggest area that needed to be improved. Examining every section and action, an FSE would undertake and ensuring they could accomplish it with a Minumun amount of cognitive effort. The team would test out designs with FSEs, who would come into the home office between deployments to give us feedback. They were the most honest group I have ever tested software with. When we got it right, they would let us know. When we got it wrong, they would also let us know and offer suggestions for improving that feature.

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. See the left-hand sidebar for an example

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.