Designing Fault Handovers to Be Traceable

Summary

During a shift handover in a control room, a small detail often decides whether a message is read correctly: where does it come from, and how old is it? This report describes a task model of a fault handover, compares two interface variants in words, and examines both in a cognitive walkthrough based on process cards. Variant B shows the origin and age of every message in the overview; variant A shows them only in a detail view. The result is an expert judgement on the visibility of critical information and a list of open risks, not a usage measurement. This report is a demonstration and not scientific evidence.

Research question

The research question of project P07 is: how can an interface make incomplete state visible without suggesting a certainty for action that does not exist? Three sub-questions follow.

1. What information does the incoming operator need in order to classify a message as current, outdated or unconfirmed?
2. Is that information visible in the two variants at the point where the respective decision is made?
3. Which misinterpretations remain possible even when the information is visible, and must therefore be documented as open risks?

Structure

Task model of the handover

The task model (see U11) breaks the handover into six steps: capture open faults, determine the origin of a message, estimate its age, classify it as current or outdated, continue or reassess the outgoing shift’s open action, and document the handover. For each step, the model records what the person must know in order to carry it out on reasoned grounds.

Variant A: status list

The overview shows a short text and a coloured status marker for each message. Timestamp and source appear only once the message is opened. Whether a message was last updated automatically or passed on by hand can be recognised only in the detail view. The list is compact and suited to a quick overview.

Variant B: list with origin and age

Each row additionally carries a text label for the origin (“sensor”, “entered manually”, “passed on from previous shift”) and an age in minutes or hours. Messages older than an agreed threshold carry the text “not current” and a symbol, not merely a different colour. Messages without confirmation appear under a separate heading, “Not confirmed”. The rows are longer, so the overview becomes denser.

Walkthrough procedure

The procedure follows the cognitive walkthrough of Wharton et al. (see background literature). For each step of each process card, the questions are whether the actor will try to achieve the right effect, notice the correct action, associate it with that effect and see that progress is being made. Here the questions are narrowed to the visibility of origin and age. Two staff members of the research area carry out the assessment together; task analysis is the responsibility of Dr Miriam Falk.

Assumptions

• The process cards, messages, times and thresholds are freely constructed. They do not come from any real control room.
• The actor is a skilled person who is not familiar with the specific plant and takes over during a shift change.
• The fault cases (for example a message that was not refreshed after a connection loss) are conceptual and taken over from the failure models of P01.
• The description of the variants does not replace a working prototype. What is judged is what the description specifies.
• There are no participants, no observations and no timing or error data.

Illustrative examination

The table shows an extract for the process card K-3, “Pressure drop at an example pumping station”. The entries are an expert judgement based on the description of the variants, not empirical usage data.

On this inspection, variant B brings the information needed for steps 2 and 3 into the overview, whereas variant A does not. At the same time, the walkthrough shows that B too provides no certainty for action: a visible age says nothing about whether the state has changed in the meantime.

Limitations

Open risks

• Ages and thresholds can suggest certainty if they are not explained.
• Variant B raises information density; whether other details are overlooked as a result is a question the walkthrough cannot answer.
• The assessment depends on the assumptions of the experts involved about the actor.
• The process cards cover only a few conceptual fault cases.

Expert inspection and a possible user study

A walkthrough is an expert inspection. It can uncover weaknesses in a design, but it cannot show how people actually act. A later user study with tasks and observation would be a separate undertaking with its own planning. It was neither carried out nor promised in this project. This also applies to the use of the Interaction Studio: it offers task logs for demonstrations, but no recorded participants.

There was no study in a real control room. The results are not a safety-critical operating approval and must not be read as one.

Conclusion

Completed in the scenario is an annotated comparison of two interface variants. By the expert judgement, variant B makes the critical information visible earlier; it does not, however, answer the question of how reliable a message is. A conceivable next step would be to turn the open risks in the table into a test plan for an independent user study. Whether and when that happens remains open.