{'fraction_non_alphanumeric': 0.018429135585783237, 'fraction_numerical': 0.0, 'mean_word_length': 4.953002610966058, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Human Error Recontextualised

The design of interactive systems for use in complex dynamic domains often leads to new technology that is introduced into evolving and ongoing operational practice. It could be said that in this new technology system builders design primarily for data availability, not necessarily operability. Operability is taken to be the responsibility of the operator: it is (s)he who must find the right data at the right time. On the basis of their knowledge of the domain and the practitioner population, designers make (and have to make) assumptions about how a human is going to perform in relation to their system; how they are going to find the right data at the right time and act correctly in response. Such assumptions are sometimes more and sometimes less well-informed. For example, a designer may assume that the practitioner will know where to look in the display layout, given a certain system state, or that training will take care of a particular knowledge requirement. Once systems are fielded, however, it often turns out that some of these operability assumptions are unwarranted. Practitioners may in fact not know where to look, or they may not call the right piece of knowledge to mind in that context. The problem is that current human error assessment techniques do not systematically support a designer in evaluating the validity of assumptions about human performance. This problem is perhaps illustrated by the huge gulf between the terms used to describe human performance issues before, during and after a design is fielded. For instance, in the design phase many human error techniques may analyse task descriptions for “errors of omission”. Yet the practitioner caught up in an evolving problem situation may indicate that “he couldn’t keep track of what the system was doing”. Similarly, analysts of mishaps post-hoc will rarely use the terms of predictive techniques and speak instead about such things as “a lack of situation awareness”. What these differences in terminology point to is that current human error evaluation techniques may fall short in how they capture the operational context and the practitioner’s cognition that lies behind the creation of interaction failures. We look at these shortfalls in turn below.