Y5.03.1Context-sensitive electronic proceduredesignresearch

Electronic procedures can adapt dynamically to current state

Aliases: electronic work instruction · context-aware procedure · computerized procedure system

What it is

A context-sensitive electronic procedure uses equipment configuration, sensed state, operator authority, and completed work to present the applicable branch, parameters, and cautions. It is not a PDF replica; procedural logic is connected to operational data. A simple test tells the two apart: open the same document on two units in different configurations. If the content is identical, it is just paper gone digital; if the content differs because of the equipment's actual state, it is a genuinely context-sensitive procedure.

Why it happens

Paper requires the operator to actively map field conditions to a branch — reading "if the valve is closed, skip to step 12" means the operator must first verify the valve state, then perform the jump themselves. Electronic logic can compute that mapping, populate the relevant object and parameters automatically, and retain position, removing the cognitive burden of searching and transcribing. The cost of removing that burden is that the paths not selected no longer sit in front of the operator's eyes — the branches and cautions that were not chosen become invisible, easier to forget existed, and harder to catch when the system's judgment turns out to be wrong. A deeper risk is amplification: on paper, one bad sensor reading misleads a single judgment, and the operator still has to actively carry out the following steps; in an electronic procedure, the same bad reading can trigger an entire branch to unfold automatically, turning a single data fault into a chain of guidance the system has effectively "endorsed." The safety value of dynamic adaptation ultimately rests on three things: whether the underlying state data is reliable, whether the rule revision matches the equipment's actual configuration, and whether the operator can see why the system chose this path over another — that last point is the one most often dropped, because showing a result takes less screen space than showing the reasoning behind it.

Studying it

Simulation can compare paper, static electronic (a plain digital document with no branch logic), and context-sensitive procedures under varying branch complexity, injected data faults, and interruption. Measure navigation time, branch errors, anomaly detection rate, and reliance on system judgment — not just speed. Two behaviors matter more than average completion time: whether participants actually check values the system populated automatically (versus trusting and skipping past them), and whether the system and operator together choose a safe exit when state sources conflict — say, two sensors disagreeing — rather than arbitrarily picking one source and continuing. Whether participants can later explain why a given step was skipped by the system is a direct indicator of whether context-sensitivity has slid into an opaque black box.

Where it stops holding

Automatic branching needs timely, reliable machine-readable state; any field condition not covered by a sensor, requiring someone to physically verify it on site, still has to trigger its branch through human judgment — the electronic system cannot make that call on a person's behalf. Hiding inapplicable steps reduces overview of the whole flow, and diagnostic troubleshooting, training a new operator, or a post-incident review often need exactly that full logic tree rather than only the currently selected branch, so hiding by default needs a clear, actively reachable way to expand the rest. No matter how capable it is, an electronic procedure is not a substitute for a physical interlock — an interlock prevents a hazardous state at the hardware level, while a procedure only recommends what to do next — and a system's recommended action should never be presented on screen as though it already carries safety authorization; those are two entirely different sources of responsibility.

Applying it

  • Next to each dynamic branch, show the specific state data that triggered it, that data's timestamp, and the rule revision currently in effect, with a clear entry point for viewing every unselected path.
  • Require human verification before any consequential action on values or object identities the system populated automatically, and visually flag unknown, conflicting, or stale data sources distinctly from confirmed normal data — never render them the same way.
  • Retain step-level completion progress, the rationale text for every manual override of the system's judgment, and a full state snapshot at each branch decision, to support resumption after interruption and full post-incident reconstruction.
  • Run exercises with deliberately injected bad sensor readings, simulated communication loss, and temporary configuration changes to verify that the system actively shifts into a conservative mode the operator can understand and anticipate, instead of silently continuing to give guidance based on untrustworthy data.

Related

  • Same group: Y5.03.2 Screens constrain overview browsing · Y5.03.3 A paper fallback is needed when the system fails
  • Nearby: Y3.11 Hierarchical displays and navigation · Y5.01 Operating procedures
  • Search terms: electronic procedure · context-sensitive procedure · computerized procedure system

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/Y5.03.1