Melissa ShiEnterprise operations · UX design · User research
Operations Information Hub
Bringing more than 30 fragmented field tools into one operator-centered workflow.
Problem
Operators moved between siloed tools and manually transferred data to complete daily surveillance and optimization work.
Solution
A tablet-first hub organized information around operator responsibilities and connected data with the actions needed to complete the work.
Impact snapshot
From a fragmented toolset to one operational foundation
The MVP reduced the effort required to find operational data and was markedly easier to learn than earlier tools, which operators said often took weeks to become comfortable using.
Design context
The visible problem was too many tools
A single workflow could span several applications. Data stayed isolated, operators transferred it manually, and unreliable field connectivity made already slow software harder to use.
Duplicated capabilities
Several tools served the same purpose, increasing the number of systems operators had to remember.
Disconnected data
Multi-step workflows crossed tools that did not share information, forcing manual transfer.
Field constraints
Spotty site connectivity limited the usefulness of tools designed without the field environment in mind.
Poor software experience
Slow loading, short login sessions, and tedious processes took time from surveillance and optimization.
Pivotal decision
Build stakeholder belief through research-backed visioning
Operations leaders doubted whether the project could deliver a useful product. My manager and I needed to make the opportunity credible while proving that the design team understood the work.
How could design make an abstract platform vision tangible before development began?
Paint the future before defining the interface
I developed storyboards around operators' day-to-day work. I created the illustrations used in the first framing session to align the project team around a shared outcome.
Make the future tangible
I created low-fi mockup of a central operations information hub based on existing knowledge, making the idea tangible and easier to grasp for business stakeholders to win their buy-in.
Ground the vision in seven operator interviews
I led the interview and and data analysis of operators and uncovered 4 pain points and challenges that futher complicated the problem. All resonated strongly with business stakeholders.
- Unnecessary tool & workflow complications
- Data isolation in multi-step-multi-tool workflows
- Unstable technical infrastructure caused spotted internect connection
- Tramatizing past software experiences
Turn findings into an end-to-end experience
Collaborated with colleague to craft initial mockups based on research findings which not only validated requirements, but also bridged the communication gap between business and IT teams by providing a concrete way to discuss the same workflow.
“I haven't been this happy since my first child was born. I have been dreaming of this for the last 10 years.”
The prototype turned skepticism into active support and created the trust needed for continued research and design work.
Pivotal decision
Design around the operator, not the source systems
Centralizing information was not enough. The hub needed to reflect how operators thought about the field and let them complete work without recreating the same tool switching in a new shell.
Test how operators locate information
Our first concepts organized data by task, type, or hybrid. Second concepts tested whether operators had a data centric or entity centric mindset. Testing revealed that:
- Operators had a run (a collection of pads) centric mindset, and
- Desired the ability to see critical data in context more than discoverability
Redefine what a single pane of glass meant
Product team wanted a read-only experience initially, requiring operators to open source tools for actions. Through testing we learned that this was the same interruption they already faced. We used that evidence to advocate for write-back wherever APIs made it possible.
Unify action items and terminology
Instead of preserving each source system's terminology, I worked with SME to standardize the language and explored a common task model for operators to go through their tasks effectively.
Design for context, consistency, and efficiency
We defined the foundational architecture of the tool as removing source-based separation and present all tasks and data as a united front. The final task page design
- Organizes tasks by type, and
- Uses slide out panel to maximize real-estate and preserve context
The resulting architecture supported both pad and run views, kept critical data together in context, and moved the product from passive aggregation toward workflow completion.
Pivotal decision
Expand the right scope through field observation
A two-week contextual inquiry into well operation revealed an inefficiency that had become invisible through habit: operators recorded digital test results again on paper because historical results were not available to them.
Redundant workd
Well teset results need to be recorded digitally, yet operators had to record them first on paper because digital devices are forbidden on pads.
Error-prone
Results could be missed, entered on the wrong day, or associated with the wrong test.
Hard to interpret
A paper table made historical trends difficult to recognize when assessing test quality.
Use design to make an unplanned opportunity visible
I proposed expanding MVP scope to add digitizing well test record book so operators could easily visualize well performance, reducing repetition and enabling better decisions.
I aligned product team and business stakeholders on the proposed solution, and successfully expanded MVP scope so the solution would be truly transformative for the business and the operators.
Refine the concept with operators and stakeholders
- Differentiated test types with color-blind-friendly colors
- Added selectable production data for easy show/hide
- Included a table view for on-the-go scannability
- Differentiated acceptance status for easy identification of undesired test results
- Povided tooltips for precise values
The evidence moved well-test history visualization into the release-one roadmap. Operators valued having historical results available in context and being able to spot problematic wells more easily, lowering the risk of making wrong test acceptance decisions.
Results and reflection
Design changed both the product and the team's confidence
Stakeholder confidence
Research-backed prototypes re-established business confidence and sustained support for the work.
Operator-centered architecture
Navigation followed pad- and run-centric thinking instead of mirroring source systems.
End-to-end workflows
User evidence influenced support for write-back when source APIs allowed it.
Lower learning burden
Most operators reported needing only about a 30-minute walkthrough for learning the Hub.
Higher-value MVP
Field observation brought historical well-test visualization into the release-one roadmap.
My biggest takeaway was that stated requirements captured only part of the opportunity. The pivotal moves came from making the future concrete, testing the product model early, and observing the work closely enough to notice the problems users had stopped mentioning.
Keep exploring