Unified Data Platform for Engineering Workflows
Role
UX Researcher · Architecture & Discovery
Year
2026
01 — The Executive Summary
The client is a global leader in energy services, operating across dozens of countries. Their drilling engineering teams are responsible for designing and executing complex well programs, decisions that directly affect safety, cost, and efficiency for oil and gas operators worldwide.
The business goal was clear: build a centralised, cloud-based platform that would let engineers query historical data, run analyses, and make better decisions faster. My role was to translate this technical ambition into a human-centered system design, grounded in how engineers actually work.
02 — Context & Constraints
This was a highly specialized domain with deeply technical users. Engineers worked across multiple tools, data sources, and regional systems—each with its own structure and limitations.
A few constraints shaped the work early on:
Most existing tools were not designed to work together
Data existed in both structured and unstructured formats
Workflows varied slightly across teams and regions
There was an expectation to support future scalability, including advanced analytics.
Drilling engineering is a world built on high-stakes precision. I had to get comfortable being the 'outsider.' By embracing my lack of technical expertise as a superpower, I was able to approach their complex workflows with a 'beginner’s mind,' uncovering frustrations that the experts had simply learned to live with.
03 — Problem Framing
The stated problem was "we need a database."
However, early conversations revealed a different reality:
Engineers weren’t struggling because of missing tools—they were constrained by fragmented systems that made even basic tasks unnecessarily time-consuming.
A large portion of their work involved preparing data rather than using it.
"At least half of my day is spent copying, cleaning, and reformatting data, before I've done any actual engineering."
Core issues identified:
Data locked in isolated systems
Heavy manual effort to prepare and format data
Limited visibility across teams
Knowledge from past work not easily reusable
Reframed problem:
Design a system that reduces operational overhead and allows engineers to focus on analysis, decision-making, and learning.
03 — What I Learned
As I spent time with engineers and reviewed their workflows, a few consistent patterns emerged—not just in what they said, but in how they worked.
The Pattern (What I Saw) | The UX Mandate (The insight I got) |
|---|---|
Engineers spent a significant amount of time copying, cleaning, and restructuring data before it could be used. | Any design improvement had to prove it could reduce this administrative overhead. |
If they couldn’t verify where data came from or how it was processed, they wouldn’t rely on it. | The system needed to provide clear "trailheads" (data lineage) so engineers could verify and trust the information they were seeing. |
Raw data wasn’t enough—engineers constantly interpreted it based on conditions, history, and specific use cases. | The system had to support flexible ways of querying and exploring data. |
Teams often solved similar problems independently due to limited visibility into each other’s work. | Saw an opportunity to transform a siloed tool into a collaborative platform. |
Engineers trust in their professional judgment. When tools feel "prescriptive", telling them what to do rather than helping them decide, they create instant friction and resistance. | The system needs to act as a high-powered assistant that offers drafts and insights, always leaving the final decision and "the pen" in the hands of the human expert. |
One stakeholder conversation I'm proud of: The engineering lead initially wanted the AI features as the headline of Phase 1. I pushed back — citing research showing that engineers would dismiss the platform entirely if they didn't trust the underlying data first. We agreed to position AI as a Phase 1 architectural requirement (so the data model would support it) but a Phase 3 user-facing feature. That sequencing decision likely saved the project from a credibility problem at launch.
04 — How That Shaped the Solution
Workflow architecture:
These insights led to a shift in how the platform was defined:
From a database → workflow-centered system
From manual preparation → automated structuring
From opaque data → traceable and verifiable data flows
From static access → flexible querying and exploration
From isolated work → connected, reusable knowledge
From prescriptive tools → assistive systems
05 — Solution
The final outcome was a workflow-centered platform designed to unify fragmented data and reduce manual effort across engineering tasks.
At a high level, the system is structured around three core layers:
A Workflow-Centered Experience
The platform aligns with how engineers move from data gathering to analysis and output—supporting both step-by-step workflows and targeted access to specific tasks.
A Unified Data Layer
Data from multiple sources is aggregated, structured, and made traceable—reducing manual preparation while maintaining trust.
A Shared Knowledge System
Work across teams is connected through shared structures, enabling reuse of past insights and reducing duplication.
Guiding Principles:
Data is always traceable and verifiable
The system supports workflows, not just storage
The user remains in control of decisions
05 — Outcome and Impact
While the product was not shipped during my time on the project, the work established a strong foundation for future development.
Defined a clear system architecture and product direction
Reduced ambiguity across engineering and product teams
Enabled downstream design and development to move forward with clarity
Influenced prioritization and sequencing of key features
06 — Reflection
What worked
Focusing on real workflows rather than stated needs was critical. Observing how engineers worked surfaced issues that had become normalized and were not explicitly articulated.
What I’d improve
I would introduce earlier validation of system structure with users—particularly around information architecture—to reduce iteration later.
Key learning
Working in a highly specialized domain required building enough context to ask meaningful questions without assuming expertise. Over time, this became an advantage—approaching the system without inherited assumptions helped uncover inefficiencies that others had stopped noticing.
Scope of Work
