I never imagined I'd be working in the energy sector. But once I was on the job at Halliburton, joined by a motley crew of ex-game developers and artists, it became a genuinely interesting one: a mix of science, engineering, and innovative solutions, all in service of one goal, making the software easier to use so that communication and safety improved with it.
To understand the problem, we went where the work happens. We visited oilfield rig sites in East Texas, the Permian Basin, and Louisiana, interviewing oilfield workers about how they used the software of the day: their pain points, their wishes, and the ways software can make a real difference when safety issues need to be communicated visually.
A common refrain: the current software was archaic and hard to use, "like Windows 3.1." Unless you were deeply familiar with both the software and the subject matter, it was hard to understand, and that made communicating safety issues, or even financial choices, more difficult than it needed to be.
As a designer I had no idea what our programming team could actually pull off. But the challenge sent them on a voluntary expedition to find out. A few days later, one of the devs came back to show me a basic well visual, rendering in Unity, built from actual well-logging numbers.
The mandate that emerged from our field research, and from our after-hours prototype, was to take the legacy well-completion software oilfield teams relied on and rebuild the experience around clarity. The tool, CyberstringSL, needed to accomplish several things simultaneously.
Turn well-logging numbers into a live 3D well visual so that operational choices, safety issues, and financial trade-offs can be seen and shared, not deciphered.
Make safety conditions legible to everyone in the room, not just the specialist who has spent years inside the legacy tool.
Let users explore variable conditions, equipment configurations, and costs interactively, instead of reading them off static tables.
Support the presenter: an engineer explaining a completion plan to a customer, a crew, or a decision-maker should be able to communicate it clearly the first time.
As UX Designer I owned the translation layer: devising how legacy software information became usable UI elements sitting on top of a 3D well model I imported into Unity. My toolkit spanned 3D Studio Max for modeling, Adobe Illustrator and Fireworks for UI assets, Photoshop for texture and visual work, and the Unity game engine as the runtime itself.
We interviewed oilfield workers at rig sites in East Texas, the Permian Basin, and Louisiana, in the conditions they actually operate in. We documented how they used the existing software, where it fought them, and where a visual answer would have changed a conversation about safety or cost.
A joke about plugging well-logger numbers into a game engine became a voluntary expedition. Within days we had a basic well visual rendering in Unity from real well-logging data. We built the prototype after hours, just to see if we could.
I devised how the legacy software's information would become usable UI elements layered over the 3D model: equipment, variable conditions, and costs surfaced as legible, interactive overlays instead of dense numeric tables.
Our department director did not want us to pursue this option: unproven technology, too slow, too expensive, a distraction from legacy upgrades. Then we showed him the working prototype. He quickly shifted his mind.
We ran a beta with several offshore rigs in the Gulf of Mexico, plus sites in Angola and Tunisia. Feedback was overwhelmingly positive; we made adjustments based on the technical notes that came back, then rolled it out wide.
After the beta, CyberstringSL was widely adopted by Halliburton contractors from Brunei to Oklahoma. The end result was a much more modern experience, by 2010 standards well ahead of its space, that let oilfield users explore variable conditions, equipment, and costs, and communicate all of it clearly and visually to their audience. Better communicated decisions, made safer.
It was no longer just a tool used out of necessity. People were genuinely excited to use it: functional, and uniquely modern in that space at the time. It helped improve Halliburton's safety record and was instrumental in landing and retaining contracts.
I like to highlight this case study because it showcases an innovative solution to a legacy software problem that found real success. Here's what it taught me.
We went on-site and listened to users in the conditions they operate in. Every design decision that mattered traces back to something we heard standing on a rig site, not something we assumed from a desk in Houston.
The Unity idea started as a throwaway line. An unusual team, ex-game developers in the energy sector, meant an unusual solution was actually within reach. Diverse backgrounds aren't a nice-to-have; they're where the leaps come from.
Leadership said no to the idea, then said yes to the working prototype. A few after-hours evenings of proof did what no pitch deck could have.
The tool stopped being something people had to use and became a spectacle they wanted to show off. That excitement carried real business weight: safer communication, and contracts landed and retained.