The timer finished; the condition did not
A laboratory operator reaches a preparation step in a digital protocol. The application starts a timer and marks the step complete when it reaches zero. The method, however, also requires an observation before proceeding. The timer has measured elapsed time; it has not established that the material is ready.
A line-by-line conversion from a document can miss that distinction. The screen contains the same words, but its behavior gives the countdown more authority than the method intended.
Consider a representative research laboratory digitizing an existing sample-preparation workflow. The scenario is illustrative and contains no experimental parameters or recommendations for a particular assay. The laboratory's method owner determines the scientific conditions. The product team's task is to represent those conditions faithfully, including cases where the operator must wait, record an exception, or stop.
The first design decision is to separate an instruction from evidence that it was carried out. A checkbox may be enough for some acknowledgments. Other steps need a recorded observation or a prerequisite satisfied elsewhere in the workflow.
Separate the method from the run
The protocol describes intended work. A run records a particular execution, with its actual inputs, people, observations, and timing. Editing the protocol should not rewrite what an operator saw during an earlier run.
The W3C PROV Data Model distinguishes an activity from a plan associated with it and from the agent responsible for the activity. It treats plans as entities whose provenance can also be recorded. That offers a useful conceptual separation, without prescribing a laboratory interface or a particular execution engine.
For this product, starting a run captures the protocol version and applicable settings. The operator can open the instructions for that version even after a newer method is published. A method revision and an execution note remain different records: one changes what future work is intended to do; the other explains what happened in a particular run.
This does not require a complex graph interface. A readable run header, stable version reference, and linked event history may be enough. The distinction needs to exist in the data even when the presentation stays simple.
Make prerequisites visible before they block the work
Suppose a later step requires both completion of preparation and confirmation that the selected equipment is ready. In the original checklist, the operator discovers the equipment requirement only after completing preparation. The application has followed the document order while hiding a dependency that matters earlier.
The revised start view identifies the prerequisites that can be checked in advance. It names unresolved items and where their evidence comes from. A readiness value read from another system should show when it was obtained and how it applies to the selected equipment. An operator's acknowledgment should be labeled as such rather than presented as an instrument measurement.
Some conditions may need to be checked again at the point of use. A successful start check does not establish that equipment remains available throughout the run. The method owner and product team need to decide which prerequisites are durable and which can become stale.
Keep explanations close to blocked actions. “Confirm equipment readiness before continuing” is actionable if the operator can see the relevant record and has a permitted way to resolve the condition. A disabled button with no reason merely moves the problem into a support conversation.
Let elapsed time remain elapsed time
In the representative preparation step, reaching the required duration changes the state to “Observation required.” It does not automatically mark the material ready. The operator records the specified observation, and the workflow evaluates the next allowed action using the method's defined rule.
The interface should distinguish the time the operator started the step from the time they entered a completion record. If someone records the event later, keep both the reported event time and the entry time where the workflow needs them. A correction should explain what was corrected rather than quietly move a timestamp.
Refreshing the page should not restart the timer. The application can reconstruct elapsed time from a persisted start event and its timing rules. A browser countdown is a display of that state, not the only record of it. If a device runs offline, the team must define how timing is recorded and how conflicting events are reconciled after reconnection.
A “Pause” control also needs a precise meaning. Pausing the interface does not necessarily pause the physical process. Where the method has no valid pause condition, the screen should offer the actual choices available, such as recording an interruption and requesting review, rather than implying that time can be suspended.
Branch on recorded evidence
A conditional step needs more than a yes-or-no prompt. The run should retain the observation that selected the branch, the applicable rule, and the action taken. If the observation is unavailable, the product needs an explicit unresolved state instead of treating an empty answer as “No.”
For this case, one observation allows continuation and another requires review. The operator sees the consequence before submitting the observation. They do not need to inspect an entire flowchart, but they should understand why the following step is different from the one they expected.
Avoid turning every sentence into a mandatory field. If a value does not affect execution, interpretation, or a justified recordkeeping need, making the operator enter it may add work without improving the run record. A free-text note can remain useful for an unexpected condition that the structured fields do not anticipate.
The choice between a guided workflow and a simpler document is real. For a stable, short method with few dependencies, a versioned protocol and a modest execution record may be sufficient. More structured logic earns its maintenance cost when branches, shared equipment, timing, or handoffs repeatedly affect the next action.
A repeat is another attempt
After an interruption, the operator may need to repeat a step. Unchecking the original box and checking it again destroys the distinction between the first attempt and the repeat.
In the proposed interface, “Record another attempt” preserves the earlier event and links the new one to it. The run records the reason and identifies which attempt supplies the result used downstream. Where a repeat is not permitted by the method, the product routes the operator to the appropriate review instead of inventing a recovery procedure.
This is particularly useful when a colleague takes over. The next operator needs to know which material is being used, what has already happened to it, and what remains unresolved. A progress percentage cannot convey those facts.
Keep interrupted, repeated, and completed states distinct in summaries. Completion may still include an approved deviation; representing the history accurately is more useful than making every finished run look identical.
Keep updates from moving underneath an active run
A protocol title alone is a weak reference when the method changes. The protocols.io API documentation explicitly distinguishes retrieving a specific version using a version suffix from requesting the latest version. That is a concrete example of why “the protocol” and “the version used here” need different references.
For this product, publishing a new version makes it available for new runs. An active run retains its existing instructions unless an authorized transition is explicitly recorded. If a newly identified issue means the old version should no longer be followed, the team needs a deliberate hold and review process. Silent replacement would obscure what the operator had already done under the earlier instructions.
Before rollout, test the timer finishing without the required observation, a missing prerequisite, a refresh during a step, a repeated attempt, and a protocol update during an active run. Ask a second operator to explain the next permitted action in each case from the record alone.
The protocol interface is ready when it can support an unfinished or interrupted run as clearly as a perfect one. The next step should follow from the method and the recorded state, not from whichever box happens to appear next on the screen.
Sources consulted
W3C — PROV-DM: The PROV Data Model (2013)
protocols.io — API documentation: protocol retrieval and versions