The peculiar project whose users didn't exist — yet
Halliburton is a company of companies. Founded over 100 years ago, it has grown through acquisition and division to provide an enormous breadth of oilfield services. In many cases, the acquired subsidiaries maintained some unique brand identity; in nearly all, they brought their own bespoke tools and software.
Working with or within Halliburton meant interfacing with a perplexing variety of software UI and interaction patterns, most of which were assembled by petrophysicists and developers with scant concern for usability. It was at best a missed opportunity to position themselves as digitally sophisticated; it posed at worst a risk of potentially catastrophic mistakes.
The Unified Drilling Advisory System (UDAS) was a structural concept that coordinated the different legacy business units (and their unique software products) into a single, modern interaction framework and design system.
The benefits of this 'super system' would be manifold:
The potential return on investment was almost incalculable. The design and development effort to touch hundreds of software systems was estimated in decades. But before all that, it had to get budgeted.
While bold in theory, UDAS was a yet unfunded mandate that relied on the support and engagement of otherwise independent business units. These subsidiaries were in some cases only weakly connected by the Halliburton brand, and many competed for funding, serving different end users and running their own software development and IT organizations.
Over the course of a three month sales process, I worked with our Accenture account leads to plan, estimate, and pitch three separate engagements under the UDAS umbrella: the Automated Drilling Advisory System, a robust discovery and definition project; the Directional Drilling Advisor / Drilling Automation Platform, a more strategically positioned project; and DecisionSpace Real Time 365, an internal marketing effort that built around a detailed proof of concept.
Tying the program together was a broader product strategy effort that articulated the theoretical and practical approach to achieving the UDAS vision and laying out the concrete steps required to achieve it.
One of the most intellectually exciting challenges of this project was determining how to design for and satisfy a user who doesn’t yet exist.
Decades of wild swings in commodity prices and changing worker sentiment had manifested in massive 'experience troughs' in Halliburton's talent market. Not only were fewer workers interested in the oil industry purely due to cultural shifts, but those who were did join the workforce had little to no industry context or experience; the bulk of the institutional knowledge cultivated in oilfield services was aging out in a gray tsunami.
Along with that gray wave, the universally low bar of oilfield software expectations was going with it — the new generation of workers had grown up with iPhones, Google, Uber. The UDAS vision would need to look better, feel better, and be dramatically easier to use. And if (when) it was, the job roles and responsibilities associated with its users would look very different.
The upshot of all this was that we couldn’t simply focus on the specific users in front of us; the software itself may make many of them redundant. In order to design for a user who technically didn't exist yet, we had to look beyond demographic or psychographic insights to more basic needs and behaviors: a typical two-dimensional user persona would be out of date the moment it was put to paper. We needed something 'universal'.
What emerged from this challenge was a new research synthesis methodology — conceptually related to Tony Ulwick's 'Outcome Driven Innovation' — called Modes and Mindsets.
I go into more detail here about the approach itself (and its benefits over traditional persona documentation), but in brief: Modes are categories of observed actions and needs; Mindsets are observed behaviors. Taken together — in the deliberate absence of a persona's character portrait details — the two elements create a modular experience framework that serve both generative and evaluative goals. By assembling and reassembling Mode and Mindset pairs, we can craft conceptual “how might we” statements while also evaluating the effectiveness of our prototypes.
Forming the conceptual research and product strategy foundation, the first and most robust of the three UDAS projects was the Automated Drilling Advisory System.
Specially formulated drilling fluids are the lifeblood of the most oilfield operations, and their provision and management is one of Halliburton’s traditional businesses. Unlike some other roles and functions, fluids engineers are present for the duration of the drilling job, and the fluids themselves are involved in nearly all operations: drilling in and drawing out the drill equipment, clearing waste, maintaining the integrity of the well, monitoring drill operation and geological formations, communicating with drill assemblies, and so on. Being as fluids engineers were required to communicate and coordinate with all other well site roles, it was a natural starting point.
At the conceptual center of ADAS was the shared rig timeline: a real time feed of information and communication between different users and their analytic tools. This view of job activities would provide a single source of truth, illustrating all actions taken (both on rig and remotely) across all roles, and all measurement / environmental data reports and any system recommended interventions. Each entry on the timeline served as a threaded dialogue point where different users or roles could ask questions, coordinate responses, or reconcile disagreements on how to progress. The whole system provided a persistent document on rig activity that facilitated onboarding and offboarding different shift teams and a historically accurate audit trail.
ADAS also introduced the multi well view, allowing supervisors to safely monitor up to eight wells simultaneously, in the same interface — significantly improving worker productivity. As both a learning and quality enhancement tool, the system would provide automated recommendations when an intervention or remedial action was required. To support workflow, instant simulations of different intervention types were available; those with less experience could better understand the effect and rationale for system recommendations, while those with more experience could quickly explore their own ideas and validate or tweak the automated suggestions.
The Directional Drilling Advisor and the Drilling Automation Platform represented two ends of a spectrum: at one end sat the directional driller, a highly skilled, compensated, and experienced worker — often in a remote operation center; at the other end, on the rig itself, sat the driller — typically a lower skilled operator whose job was essentially to execute mechanically whatever plans the remote directional driller provided.
Being offsite, the directional drillers rely entirely on data and communication coming from on-rig. Complicating the human element of this process is sometimes conflicting recommendations coming from different subspecialists (based on their unique incentives): one advocating higher drill speed to meet a job deadline; another cautioning to slow speed to reduce wear on the equipment. Directional drillers and their counterparts must coordinate and reconcile different data and recommendations in order to provide consistent information to the on-rig driller to act upon.
Building on the modular, unified UI of ADAS, DDA selectively personalized individual data components within a shared view, according to a user’s specific needs. This shared view facilitated more consistent and smoother cross-project alignment without sacrificing the kinds of role-specific data some users required. In turn, the DAP communicated those reconciled instructions to the drill operator clearly and concisely.
Under the best of circumstances, every role in the drilling project will be a Halliburton employee (what is known as a “red rig”), all of whom can at minimum agree that they are supporting their employer. More often, though, Halliburton will represent only a fraction of the workers in a given project; their colleagues range from smaller contractors, to clients, to outright industry competitors. And each brings their own software and monitoring tools.
DecisionSpace Real Time 365 was the “public facing” view of UDAS - a data visualization and communication tool that served as a psychological center for all contractors and customers working a job. As such, it had to flex and adapt to the different roles involved (depending on the complexity of a drilling operation, some specialist users wouldn’t be involved at all) and Halliburton’s contractual obligations. Depending on the customer, the job, and the contract, various data visualization and simulation tools could be turned on or off — in some cases, these data or features would be provided by outside vendors but within the single common interface; in others, features may be provided to the Halliburton contingent on a job, but no other collaborators.
From the program perspective, DSRT365 represented the most visible and highest profile illustration of the UDAS vision to date, and would serve as the proof of concept used to secure the significant next tranche of internal funding. It needed to not only wow, but also to preemptively address any potential critical feedback — to explicitly prove its value.
As a sales tool, the DSRT365 timeline was the shortest of the three UDAS projects; without the luxury of to invest in the same level of embedded ethnographic research of ADAS and DDA/DAP, we instead drew heavily from our previous research insights and complemented that with an intensive cycle of RITE — presenting rough prototype stimulus to research participants (often via teleconference) and collaborating with them to refine the concepts. During these sessions, we would capture specific feedback that could be directly addressed in our presentation material.
Our final deliverable was a shareable InVision prototype and sales presentation that walked through the structure and features of the tool in narrative form: over the course of a single week, from different user perspectives.
Following that successful delivery, a subset of the team and I spent three weeks breaking the ADAS vision into a combination of agile epics, user stories, and acceptance criteria. In parallel, I worked with the technology and product leads on our Accenture account teams to plan and estimate the initial phase of the ADAS delivery effort. You can read more about the built product here.
