Notification Hub
Redesigning Safety-Critical Alerts for Industrial Drilling HMI
Role: Lead UX Researcher
Project: SmartROS Automation Platform — Nabors Industries
Timeline: May – June 2026
Methods: Qualitative interviews, concept testing, stakeholder synthesis
“I would actually take a picture with the rig phone so I had a picture of the alarms before I could try to fix the situation — because once you acknowledge them, they’re gone.”
— Trainer / former driller
THE SITUATION
The notification system on Nabors’ drilling HMI screens had grown organically across multiple products. Each had its own visual style, interaction pattern, and behaviour. There was no shared standard.
The consequences were not theoretical. Drillers were overwhelmed by notification volume and had learned to clear alerts without reading them — including critical ones. A confirmed safety incident had been reported where a notification covering a critical control button caused an unintended operational trigger.
The goal was not to redesign for aesthetics. It was to understand how operators actually experience the notification system, where it was failing them, and what principles should guide a unified redesign.
MY ROLE
I led the end-to-end research programme for the Notification Hub project — from research strategy and participant recruitment through interviews, synthesis, and design direction. Visual design and prototyping were owned by the design team. My deliverable was the research foundation the design was built on.
RESEARCH APPROACH
11 participants. 2 months. Two distinct groups.
I structured the research to capture both the technical and operational perspectives — because a notification system lives at the intersection of both.
Group 1 — Technical stakeholders (5 participants)
Product managers, automation engineers, systems leads, and ISA standards specialists. These participants understood the system architecture and business constraints.
Group 2 — Field participants (6 participants)
Trainers with 8–15 years of experience and former drillers with direct HMI seat time. These participants understood what it actually feels like to sit in the driller’s seat when something goes wrong.
Both groups were interviewed independently. Findings that appeared in both groups without prompting were treated as settled. Discrepancies between groups shaped the design decisions still being refined.
WHAT WE FOUND
01 — Drillers dismiss before they read
Notification volume had trained operators to clear alerts reflexively. Critical and routine notifications received identical treatment. This is not a behaviour problem — it is a design failure with documented safety consequences.
02 — Once gone, it’s gone
No persistent notification history existed. Operators developed their own workarounds — one trainer photographed alarm screens with a rig phone before acknowledging faults. The workaround confirmed the gap better than any survey could.
03 — Every extra click costs operational focus
Field participants described needing notification history without leaving their operational screen. On a drilling HMI, navigation is not neutral — context loss during active operations is a real risk. Two access formats are being prototyped and validated based on this finding.
04 — Grouped notifications reduce noise without losing information
When multiple alerts fire from the same root cause, showing them individually multiplies cognitive load without adding value. Participants endorsed grouping immediately when shown the concept — no explanation needed.
05 — Drillers think in operations, not severity tiers
The mental model is binary: can I keep drilling, or do I have to pick up? Severity classification built around technical alarm levels maps to no one’s actual decision-making. The design direction follows the operator’s question, not the engineer’s taxonomy.
06 — Notifications must never reach critical controls
A real incident — not hypothetical — was reported where a notification covering a critical button caused an unintended operational trigger. A defined notification-free safety zone around critical controls is now a hard design requirement, not a preference.
07 — Some lockouts are correct by design
Experienced field participants specifically defended two lockout pop-ups: stall protection and lower well control valve procedures. In both cases the driller’s instinct in that moment is the wrong action. The lockout forces the correct procedure. Not everything that interrupts is bad design.
08 — Snooze is valid — but needs a memory
Drillers regularly operate through known conditions. Temporary deferral is a legitimate need. The risk: snooze without contextual return creates false closure. The design requires snoozed notifications to return with visible context confirming the condition has not resolved.
09 — Shift handover is an operations conversation, not a notifications one
Every field participant described handover around active equipment issues and critical alarms — never routine notifications. This finding eliminated an entire assumed feature from scope and saved significant design and engineering time.
10 — Post-reboot: critical only, everything else in the hub
After a system restart, operators want to confirm settings and get back on bottom — not process a flood of queued alerts. Critical items surface on screen. Everything else waits in the hub with a count badge.
FROM RESEARCH TO DESIGN DIRECTION
Each finding translated directly into a design requirement. These were not recommendations — they were constraints the design team worked within.
| Finding | Design Direction |
|---|---|
| Drillers dismiss before reading | Hub acts as persistent log. Nothing disappears permanently. |
| No notification history | Dismissed notifications held and retrievable at all times. |
| Navigation friction | Hub accessible without leaving operational screen. Two formats prototyped. |
| Grouped notifications | Related alerts grouped under root cause with count. Individual items visible on expansion. |
| Operational severity model | Visual hierarchy built around can-I-keep-drilling, not technical alarm levels. |
| Notifications over controls | Notification-free safety zone defined around critical controls on every screen. |
| Justified lockouts | Stall protection and LWCV lockouts maintained. Both require logging for accountability. |
| Snooze without false closure | Snoozed notifications return with visible context. Condition status always shown. |
| Handover scope | No dedicated notification handover mechanism needed for general case. |
| Post-reboot flood | Critical items on screen. All others held in hub with count badge. |
WHAT THIS UNLOCKED
The research settled ten design decisions that had previously been assumptions. More importantly it eliminated one — the shift handover notification mechanism — before design or engineering time was spent on it.
Three workstreams are now in progress based directly on this research:
Notification classification audit — a structured review of every existing notification in the system, classifying type, severity, colour, behaviour, and snooze eligibility.
Design specification — a unified notification design language covering colour coding, interaction patterns, placement rules, hub drawer, grouping behaviour, snooze, and lockout standards.
Prototype validation — a second round of sessions with field participants using interactive prototypes, including current drillers recommended during the initial research sessions.
WHAT WE LEARNED
Drilling HMI design sits at the intersection of two very different worldviews — the engineer who builds the system and the operator who uses it under pressure, in noise, with their hands already busy. The biggest research insight was not a finding — it was a methodology one. Interviewing both groups separately before comparing responses revealed where the assumptions lived. Engineers assumed drillers wanted more information. Drillers wanted less, faster, and never on top of a button they needed to press.
The rig phone photograph was the moment the research found its center. One workaround, described independently by multiple participants, said everything about the gap between what the system provided and what operators actually needed.
TOOLS & METHODS
Qualitative interviews — Figma (research documentation) — FigJam (synthesis and affinity mapping) — Stakeholder readouts and design reviews
All participant identities have been anonymised. Research conducted May – June 2026 as part of the SmartROS Notification Hub standardisation project at Nabors Industries.
Sole Houston | Research-Led UX Design 