Decision support · Product strategy

Collaborative Operations Dashboard.

Turning fragmented drilling signals into a shared operational view of what needs attention, why it matters, and what happens next.

Working prototype · Stakeholder review
PlanningEngineeringAutomationReportingOperations
Shared sensemaking layer
Priority exceptionContext · confidence · next action
Upcoming decisionOwner · timing · supporting workflow
Public-safe reconstruction. Names, metrics, operational data, and product interfaces are fictionalized.
Role
Head of UX; strategy, research, and prototype direction
Team
Head of UX plus one senior designer
Foundation
Agency research and validated proof of concept
Status
Development team formed; approval pending

The business context

The environment was data-rich—and context-poor.

Remote supervisors did not need another source of raw data. They needed a shared place to connect what was planned, what was happening, what had changed, and what decision should follow.

Signals lived across planning, engineering, automation, visualization, reporting, and communication systems. Supervisors manually reconstructed the story of a well while distributed disciplines interpreted risk and trade-offs differently.

The opportunity was a customer-facing entry point and internal collaboration surface that connected existing tools without pretending to replace the specialized systems where engineering and execution occurred.

The design problem was sensemaking and alignment—not dashboard configuration.

Validated opportunity

Protect finite attention and elevate judgment.

An external research and proof-of-concept phase established the need for rapid portfolio awareness, explainable automation, proactive risk visibility, structured decisions, and concise after-action reporting. I was a primary stakeholder, meeting weekly with the agency and guiding the research direction.

The concept had to support two modes: passive awareness of what changed and what needs attention, and interactive investigation into why it happened and which options exist.

  • Attract: understand status in minutes and explain automation behavior.
  • Reward: surface meaningful risks and move from signal to shared decision.
  • Retain: create recurring value through portfolio scanning and after-action learning.

What I did

Extended the concept into a coherent operating journey.

  1. Advanced the validated foundation.I used AI-assisted design and development to explore alternatives as a working Angular prototype, supported by one senior designer.
  2. Created three attention levels.A concise command brief, portfolio command center, and dense comparison view serve different supervisory needs.
  3. Connected the full service lifecycle.Pre-well readiness, active execution, and post-well learning became one continuous service narrative.
  4. Linked status to action.Exceptions, milestones, and recommendations route users toward the appropriate workflow instead of ending at a dashboard.
  5. Made confidence visible.Source freshness, access restrictions, governance status, required outputs, and next actions are part of the experience.

Selected interface work

From portfolio signal to the next decision.

The interface is deliberately curated rather than configurable. It gives time-poor supervisors a concise operational brief, makes exceptions explainable, and lets them move into the appropriate workflow without losing context.

Representative reconstruction with fictional branding, wells, metrics, locations, sources, and operational details.

Outcome

A broader, navigable operations prototype.

The work advanced a validated customer-facing concept into a connected Angular prototype spanning portfolio awareness, planning, active execution, and post-well closeout.

3Connected lifecycle stages: pre-well, execution, post-well
3Levels of entry for different attention budgets
1Shared layer linking summary information to existing workflows
ReadyDevelopment team formed and awaiting approval

The prototype is under stakeholder review. Evaluation has so far been limited to stakeholder sessions; new customer validation and production outcomes are not claimed. Current decisions focus on the right initial entry experience and the supporting data available at deeper levels.

What I would do differently

Set the MVP boundary before comparing directions.

I would create more interaction with the product team at the outset and establish explicit first-release boundaries earlier. That would make alternative directions easier to compare and give stakeholders a firmer basis for approval.

Return to flagshipTranslating Tecton for Sperry