Digital DOS: Closing the Loop Between the Rig and the Office

Digital DOS is Halliburton's internal end-to-end software for drilling operations. Engineers use it continuously (before, during, and after a run) to read large volumes of downhole data quickly and diagnose what is happening to a drill while it is in the hole.

I joined as a contract UX designer in 2023 and worked on the application through 2025, taking work from discovery through implementation support.

Discovery

I began with user interviews, spending time with drilling engineers and rig staff to understand how the software fit into their day.

The central finding was that the documented business process and the actual working process had diverged. The procedures had been written years earlier; the technology, the equipment, and the operating conditions had all moved on. The documentation had not.

Engineers had adapted. They had built workarounds, adjusted sequences, and developed practices that reflected what the rig actually required rather than what the manual described. New engineers were onboarded against documentation that no longer matched the work in front of them.

Nobody had gone and looked. That was the opportunity.

The data gap

The software surfaced data generically. The data engineers actually needed to analyze a drill was a subset, and it wasn't organized the way analysis required.

So they exported to Excel, the way it had always been done. On the rig, data points were printed to spreadsheets and then to paper, carried physically for review with supervisors and managers.

Paper works on a rig floor. That was not the problem.

The problem was the return path. Analysis and annotation happened on paper and stayed there. Historical data, supervisor conversations, review notes, all of it accumulated in folders on desks and never returned to the system. The office never saw it. The next engineer never saw it. Each run started without the benefit of the last.

The solution

I worked with the team to understand this workflow and the limitations of the engineers on the rig. We came to design an uploader application, along with a full system redesign, to close that loop.

Rather than trying to eliminate paper (which served a real purpose in the field), the uploader gave the field a way back in. Engineers could capture completed documentation by phone or by scanner, and the data returned to the system where it could be charted, graphed, and compared against history.

The redesign served as a method to understand the business process gap. It gave us access to more data and understanding of what was missing and where the disconnects happened.

We took the redesign and the uploader from ideation through implementation, working with engineering across requirements, workflow, interaction design, and iterative review.

Additional workstreams

• Restructuring core workflows to reflect how engineers actually worked
• Onboarding redesign
• Navigation improvements
• Internal experiences
• Design documentation and engineering handoff

Outcome

The design was implemented and the gap in the loop was closed structurally.

Adoption was a separate matter. This disconnect had occurred for years, and habit is not a design problem. It is an organizational one. Reinventing the surrounding processes to take advantage of the new capability was underway when my contract ended.

The lasting contribution is the discovery, not the interface: the documented process and the real process had drifted apart, and the work of realignment could not begin until someone went and established what the real process actually was.