NOVOS
NOVOS
ALARM CENTER
& WELL PLAN
Alarm Fatigue Reduction & Directional Well Plan Import — Reflexive Drilling UI
THE SYSTEM
NOVOS is the oil and gas industry's only reflexive drilling system — an autonomous platform that automates repetitive drilling activities so drillers can stay focused on process consistency and safety, while operators benefit from optimized drilling programs. The system runs on dedicated hardware mounted at the rig floor, handling real-time data from sensors, guiding drillers through step-by-step procedures, and surfacing alarms that demand immediate human judgment.
This contract engagement placed me inside the NOVOS product team midstream — joining an active sprint cadence with an established design language, a growing component library, and SMEs who needed design velocity, not a slow ramp.
UI DESIGNER — CONTRACT
I was tasked with two deliverable tracks running in parallel: the NOVOS Alarm Center — a multi-state notification system that needed to cut through alert fatigue in a high-stakes drilling environment — and the Import Well Plan interface, a data-dense modal housing directional drilling survey data with complex scroll, column hierarchy, and state logic requirements.
For both tracks, my process ran from SME and engineer discovery through concept ideation, interaction spec, and final annotated documentation — including component spec sheets delivered to software developers as the authoritative implementation guide and to the training team for inclusion in the NOVOS user manual.
A key constraint: NOVOS had an established, highly specific visual language. Every component needed to inherit from and extend the existing system without breaking visual consistency.
TWO HARD PROBLEMS
Both tracks were grounded in documented field research — rig visits, video-recorded driller sessions, and SME interviews that surfaced exactly why the existing approaches weren't working.
ALARM FATIGUE
Drillers were being desensitized. False alarms from broken sensors, maintenance events, and "dumb" context-unaware triggers were firing constantly — so operators learned to dismiss them reflexively. The field documentation made the risk explicit: at the most vulnerable moments (like making a connection), alarm noise was loudest, and drillers had trained themselves to ignore it.
DATA DENSITY
The directional well plan table presented nine columns of precision survey data — Vertical Depth, Measured Depth, Inclination, Azimuth, Dogleg Rate, Build Rate, Turn Rate, and north/east positional offsets. Engineers needed to import, validate, and switch between well plans in a constrained modal without losing their place in the data. Scrolling, column hierarchy, and state logic all had to be explicitly designed.
- Finding 01False alarms desensitize. A repeating alarm from a faulty sensor teaches drillers to ignore it — including the real event when it finally occurs.
- Finding 02Consequence-triggered, not cause-triggered. One event fires multiple alarms. The driller receives noise, not diagnosis.
- Finding 03No contextual awareness. Alarms fire during normal operations — pumps off during a connection — making routine suppression a habit.
- Finding 04Undifferentiated priority. All unacknowledged active alarms look identical. Critical warnings compete visually with trivial status notices.
- Finding 05Well plan data is complex. Nine columns, ten+ survey rows, horizontal overflow, and sub-column grouping — all within a fixed modal constrained to rig-floor hardware dimensions.
METHODOLOGY
I worked directly with SMEs who provided real-world operational scenarios, which formed the basis for every design decision. Rather than building from scratch, I conducted a thorough audit of the existing NOVOS component library — cataloging text styles, color tokens, button shapes, SVG assets, and animation patterns — so every new component I designed could be assembled from familiar parts and feel native to the system.
Early concepts were presented in interactive prototypes before backlog items reached development — showing multi-state behavior in motion kept the team aligned even when implementation was two or three sprints out. For the alarm center, the SME documentation outlined five things every alarm needed to communicate: that an alarm occurred, its severity, its cause, the corrective action, and the consequences of not acting. This became the design brief. For the well plan, SMEs provided actual survey data files so I could work with real column widths and real numeric precision.
The NOVOS Dialogue with Planning Bar — the system in full operational context before the alarm overlay. The Planning Bar (left) tracks drilling activities with timestamps and depth ranges; the NOVOS Dialog (center) guides drillers through step-by-step manual procedures. Eighteen active alarms in the nav bar establish the urgency of the alarm center design challenge.
MULTI-STATE ALERT SYSTEM
The solution introduced a persistent Alarm Center Button in the NOVOS top navigation bar. The button communicated alarm status at a glance through two distinct visual states: a Warning state (amber triangle icon with count badge) indicating active unacknowledged alarms, and a Normalized state (green check icon) showing all alarms acknowledged. The hazard stripe pattern and count badge gave drillers at-a-glance awareness without leaving their active task.
Tapping the alarm button opened the NOVOS Alarm List — a right-side panel that slid over the main workspace without interrupting the current workflow. Each row displayed the alarm title, timestamp, and a plain-language description. A left-edge priority indicator strip used color to differentiate severity tiers, directly solving the "all alarms look identical" problem from the field research. The design explicitly avoided mass-acknowledge patterns that had trained drillers to dismiss everything at once.
Three persistent button states in the NOVOS nav bar — Warning Normal (amber triangle, count 18), Warning Pressed (panel open), and Normalized (green check, count 2). The hazard stripe pattern at the top edge reinforced elevated alert status without text. Count badge gave immediate situational awareness at any scroll position.
Left: Alarm center panel spacing — position (10, 24px), size (398 × 524px), with color-coded callouts for header height (23px), content zone (26px), separator (5px), and footer strip (4px). Right: Full typography system — Rexlia Book Regular for the list headline (#39B54A), Droid Sans Bold for alarm titles (14pt) and timestamps (12pt, right-aligned), Droid Sans Regular for descriptions and the "View Alarm Log" link (#769099).
Second dimension pass — annotating row-level measurements: 7px top padding, 26px content zone, 6px side margins, 35px priority indicator width, 9px bottom spacing. Each measurement was specified independently so developers could implement without ambiguity in either the QML or CSS layer.
Left: Alarm Center Button SVG breakdown — acb_normal_stroke (208 × 63px), acb_normal_fill, acb_pressed (209 × 64px), warning_sign_background (30 × 27px), warning_sign_exclamation (4 × 16px), normalized check, and vertical scroll control (w6, max h292px). Right: alarm_listing — fill and stroke (both 398 × 50px) plus the al_indicator priority strip (23 × 44px at position 3, 3). Stacking rule: upper object overlaps lower object by 1px; a 5px separator divides active from normalized sections.
The alarm list panel is built from two nested SVG layers: alarm_list_frame (outer shell, 418 × 574px) positioned off-canvas at x –418 in resting state and sliding to 0 on trigger, and alarm_list_inset (inner dark content area, 398 × 524px). Two-layer construction allows frame and content to animate and scale independently — a pattern consistent throughout the NOVOS component system.
The NOVOS Dialogue component specs — title bar (min 159 × 32px, vertical scaling), content box (min 159 × 56px), frame (min 163 × 92px), box shadow (min 164 × 94px). The activity button defined four states including "Starting" (dimmed, text color shifted) alongside label conventions: "Continue" for process continuation, "Next" for wizard sequences, "Apply" to save without closing, "Confirm" to save and close.
DIRECTIONAL DRILLING DATA INTERFACE
The Import Well Plan feature presented a significant data complexity challenge. The Planning App modal housed a tabbed navigation sidebar alongside a data-dense table displaying directional drilling survey data — up to nine columns including Vertical Depth, Measured Depth, Inclination, Azimuth, Dogleg Rate, Build Rate, Turn Rate, and north/east positional offsets — across ten or more survey rows, within a fixed modal at a minimum width of 790px.
The left sidebar navigation used three interaction states — normal (gradient), pressed, and selected (flat fill #49616B) — to communicate which section was active. The Directional Drilling section required both vertical and horizontal scroll when all nine columns were visible, controlled through purpose-built scroll components aligned to the NOVOS visual language.
The Import button communicated the full workflow through four states: dimmed (no selection), normal (ready), importing (in-progress, label change + dimming), and an imported confirmation that persisted for 6 seconds before resetting. Every interactive element was documented at the same spec-sheet level as the alarm center.
B-01342 — Directional Drilling overview, shown in full NOVOS operational context. The Planning App sits over the drilling workspace with the Planning Bar active on the left. Design notes annotate column spacing (10px from edge), center-justified column labels, right-aligned cell data, and the parIcon position indicator (lower right) that shows the user where they are in the full data set.
Left: Scroll view and interaction — the vertical scroll control appears when data rows exceed the visible area; scroll indicators and the parIcon disappear when the user has expanded the app to show all content (no bounce/sticky effect). Right: Expanded to full content view with column width rules annotated — max 30 characters per title, wrapping after 15 characters, minimum column width driven by the widest title or data value. Numeric values use space as the 1000 separator (Guideline #79549823).
Left: Default view — "Directional Drilling" selected in the sidebar, 7 columns visible (Vertical Depth through Dogleg Rate), horizontal scroll active to reveal additional columns, Graph tab visible at bottom. Right: Fully expanded — all nine columns visible including Build Rate, Turn Rate, +N/-S (ft), and +E/-W (ft); the horizontal scroll indicator and parIcon disappear once all content is visible.
The sidebar nav controlled four discrete content sections. Well Location (left) displayed GPS coordinates, elevation, location classification, and geographic identifiers in a two-column form layout. Depth-Parameter Suggestions (right) introduced a complex column hierarchy — WOB (klb) and RPM (rpm) each split into MIN / TARGET / MAX sub-columns — demonstrating the sub-column grouping rules documented in the column width spec.
Sidebar nav button states across both guideline document versions — v1.8 (left, 4 tabs including Directional Drilling) and v2 (right, 3 tabs). Three states: pressed (darkest, flat), normal (gradient fill), and selected (flat fill #49616B, assigned to "current" items throughout the NOVOS Dark Color scheme). Font: Rexlia Book, 13pt normal / 14pt pressed, Title Case, #769099 — shifting to #282828 for the active state.
Sidebar button SVG stacking — position (10, y px), minimum size (w 166, h 34px), horizontal scaling. The stack shows the visual difference between each state layer: the pressed state uses a flat dark fill while the normal state uses a gradient. Both guideline versions use the same SVG assets from App Manager (button3_normal_stroke, button3_normal_fill, button3_pressed). A 3px inter-button gap and 10px outer spacing are annotated in purple and red respectively.
Nav button label SVG specifications — iwpln_normal_stroke (260 × 40px), iwpln_normal_fill (258 × 38px), iwpln_pressed (200 × 40px), and the active border/fill pair. Label typography: Rexlia Book, 13pt normal, 14pt pressed, Title Case. Normal label color #769099 (muted); active label color #282828 (dark, high contrast against the selected background fill).
The well plan selection combo box documented across both guideline versions — four states: Initial ("Select" placeholder, down chevron), Pressed (darkened, down chevron), Dropdown open (up chevron, option list visible), and Select one option (option highlighted, up chevron active). The arrow tab flips from ∨ to ∧ on open, providing clear affordance. All components use the shared SVG assets from Combo Box.
Combo box SVG layer breakdown — combo_box_stroke (min w166 × h34px, borders 153 × 23px), combo_box_fill (min w164 × h32px), combo_box_inner_shadow (min w164 × h32px, borders 153 × 18px), combo_button_fill (min w46 × h28px), combo_button_shadow (min w50 × h30px, position –4, 0), combo_button_edge (min w46 × h28px). All scale both horizontally and vertically.
Left: Import button in context — positioned at (197, –26px) relative to the sidebar nav, sitting in the top-right corner of the left panel, min size (w 85, h 34px). Right: Four-state flow — normal (resting state, "Import" label), dimmed (no well plan selected yet — button disabled until combo box has a selection), pressed (visual depression on click), and importing ("Importing" label, button dimmed while transfer is in progress if longer than 2 seconds, then "Imported" confirmation for 6 seconds before resetting to "Import").
Import button SVG layer breakdown — stroke (85 × 32px), fill (83 × 30px at position 1, 1), shadow (85 × 32px at position 0, 2), and pressed (85 × 33px). All use the same SVGs from App Manager (button2_normal_stroke, button2_normal_fill, button2_normal_shadow, button2_normal_pressed). Label typography: Rexlia Book, 11pt, Title Case — normal state color #373738 (near-black on the chevron surface), pressed state color #939997 (lighter, ensuring readability against the dimmed button).
Data table typography and spacing. Left: Column header labels — Droid Sans Regular, 11pt, Title Case, #838589 (muted), center-aligned. Cell data values — Droid Sans Regular, 11pt, #979B9E, right-aligned within each cell. Right: Spacing rules — 36px column header row height, 40px data row height, 10px padding from end character, 1px cell spacing, 26px bottom margin, 6px side margin. Alternating row backgrounds: row1 #363634, row2 #393937. A 6px gap separates the Vertical Depth and Measured Depth column pair from the rest.
Column width rules — the full annotated 9-column table with all measurement callouts. Rules: maximum 30 characters per title; sub-column titles cannot wrap; titles wrap after 15 characters if they can; maximum 15 characters for subtitles; maximum 30 characters for titles with sub-columns. Column width is always the minimum allowed by the widest title or data value — tighter data allows narrower columns. Color-coded annotations mark: header height (36px, green), cell height (40px, purple), padding (10px, red), spacing (1px, blue), bottom margin (26px, orange), side margin (6px, orange), and the 6px Vertical/Measured Depth separator (pink).
Directional Drilling outer frame SVG — the same asset as app_manager_frame, reused from the NOVOS component library. Left: Vertical scaling mode — borders for BorderImage marked in red at top and bottom. Right: Horizontal scaling mode — minimum width constraint of 790px, the hard floor for the Import Well Plan modal on rig-floor hardware.
Import Well Plan frame SVG from v2 guidelines — same vertical and horizontal scaling rules as the Directional Drilling frame, confirming component reuse across both features. The 790px minimum width constraint is enforced at both the frame and insetFrame level.
The insetFrame SVG sits inside the outer frame at position (10, 10px) and provides the dark content area background. v1.8 spec: min w 760, h 438px (BorderImage borders 746 × 440px). v2 spec: min w 760, h 454px (BorderImage borders 746 × 440px). The height difference reflects a layout adjustment between guideline versions. Both scale horizontally only.
DataCol background SVG — the dark area that holds the data table columns. v1.8 (left): position (197, –26px), min w 481, h 34px, horizontal scaling. v2 (right): position (288, 20px), min w 481, h 444px — updated to a full-height panel background rather than a single-row strip, reflecting a structural refinement between versions.
Left: dataCol_header SVG — the teal header strip that runs across the top of the data column area, position (5, 5px), min w 470, h 33px, horizontal scaling. Right: dataCol_header_title — the section title text element ("Details Description [10H 00]" format), RexliaBk-Regular, 14pt, Title Case, color #282828, position (20, 11px), left-aligned, top-aligned. Amount of text is variable based on the selected well plan name.
Horizontal and vertical scroll control SVG specs — Hscrollcontrol: max w 383, h 6px, horizontal scaling (BorderImage border w=94px). HscrollTrack: w 468, h 34px, horizontal. Vscrollcontrol: w 6, max h 292px, vertical scaling (BorderImage border h=94px). VscrollTrack: w 34, h 326px, vertical. Note that the scroll track SVGs are shared from the Import Well Plan guidelines — a deliberate system-level reuse decision.
Left: Scroll track position diagram — color-coded annotations mark horizontal track area (w 383px, blue), vertical track area (h 292px, blue), and the control element dimensions: width 4px (purple), height 25px (red), widths 6px and 8px with height 8px (green/cyan). Right: The parIcon position indicator mini-map — three-layer construction (Bk background, Stroke outer, Fill active indicator) each at max 31 × 16px. The "active" fill element moves dynamically to show the user's current viewport position within the full data set on both X and Y axes.
The "Graph" switch button at the bottom of the data column — uses the same SVGs as the switch button from the Planning Bar (switch_button_stroke, fill, shadow, highlight). Specs: stroke (2 × 27px, no scaling), fill (40 × 27px), shadow (36 × 31px at –4, 0), highlight (40 × 21px at 2, 0). Label: Droid Sans Regular, 11pt, Title Case, #696B6B, center+middle aligned. The Graph view was marked as "moved to Future Development — not implementing Graph view right now" in the v1.9 annotation, reflecting accurate documentation of a descoped feature.
SPEC-FIRST DELIVERY
Both tracks required production-grade spec sheets beyond annotated Figma frames. The NOVOS development environment used a specific asset pipeline — SVG sprites with BorderImage scaling rules, pixel-exact position coordinates, and named component identifiers tied to the engineering codebase. Every component needed to follow this convention precisely.
The documentation covered: SVG asset names and source files, component dimensions at every scale point, font specifications including family, size, case, alignment, and color hex, scaling behavior (horizontal, vertical, or both), and BorderImage border definitions marked in red on each asset diagram. This level of specificity meant developers could implement without a design review cycle — the spec sheet was the source of truth. Both tracks went through two rounds of guideline documents (v1.8 and v2) as the specs were refined through engineering review.
On a system as operationally critical as NOVOS, ambiguity in the spec is a safety risk. A misimplemented alarm button that looks similar but behaves differently in a warning state could contribute to exactly the kind of alarm fatigue the design was trying to solve. Complete, unambiguous documentation wasn't a formality — it was part of the safety discipline of the product.