“Remain Faithful to the Earth!”*: Reporting Experiences of Artifact-Centered Design in Healthcare

Likewise, ontologies are increasingly used to model concepts and relationships in human domains and how software components can collaborate to support such domains.

Technology in working order. Studies of work, interaction, and technology (Eds: Button G), Routledge, London, 1993, cited in Goorman and Berg (2001).

Suggestively, Orlikowski and Iacono (2001) define the IT artifacts as “those bundles of material and cultural properties packaged in some socially recognizable form such as hardware and/or software” [p. 121].

Quite confusingly, in much literature especially from the Information Systems field (e.g., design research (Hevner et al. 2004)) also formal representations and models are denoted as artifacts (so that artifact-centered approaches are likened to rationalistic, top–down ones, cf. e.g. (Pentland and Feldman 2008)). To this respect, the artifacts we refer to are the material (but not necessarily tangible, as noted by Schmidt (2010, p. 283)), inscribed, symbolic, socially recognizable (Orlikowski and Iacono 2001) objects that actors use to perform and articulate their work, like, e.g., their documents and records.

We are then not referring to the general meaning that “bottom–up” has in strategies that are mentioned in methodologies of either relational schemas drafting, model integration or procedural programming; in these contexts strategies are called bottom–up in that they, respectively, integrate small portions of a conceptual model into a bigger/more abstract one, or support the construction of complex software applications from smaller modules (as it is common in Object-Oriented programming).

This has also to do with what Goguen (1992) denoted as a post-modern approach to requirement elicitation and with the reason why I defend the expression “artifact-centered” notwithstanding the double-cut paradox of centering something on artifacts instead of users or work itself.

In a protocol analysis, users are invited to use their habitual artifacts in individual sessions and, while simulating some usual work task, to concurrently speak aloud to explain what they do. It is noteworthy to say that, differently from the earlier proponents of these talk-aloud protocols, we do not consider these methods as a structured way to get “a direct verbalization of specific cognitive processes” (Ericsson and Simon 1993, p. 16) or to delve into the more or less tacit reasons why artifacts are used the way they are. Rather, we agree with Goguen and Linde (1993) that protocol analysis cannot be taken as a model of human problem solving and that its value, especially in the ambit of an artifact analysis, comes mainly from the opportunity to artificially “slow down” the use of an artifact. In this way, analysts can be facilitated in seeing passages of usage that an external observer could just miss, or neglect. Moreover, in so doing analysts can also get a clue of what passages are considered the most important by the users themselves, and of what conventions are at play while they make use of the content that the artifact represents and conveys.

For instance, situatedness of action and context, sociality of work, accountability and orderliness of the social world (Goguen 1996).

Interestingly, a reviewer noted that an artifact-centered approach tends to focus more on the design of structures than to the design of interactions. This is a very subtle point in that this approach is imbued with the feeling that designers cannot but design just structures, and that the interactions that are mediated by these structures will simply follow, even in unpredicted and unintended ways, once a technology is appropriated by the users, as they adopt it and adapt themselves to its capabilities (Orlikowski 2000). This is a point that is thoroughly discussed and argued in the rich literature about the structurational models of technology design. Yet, the reviewer’s suggestion reminds me of some seminal ideas coming from the field of Design Research that an artifact is “structurally coupled” with its environment, much similar as its users are, according to Maturana and Varela (1992), on the basis of both their physical nature and their ontogenesis (i.e. personal memories, previous social interactions and experiences). And, to some extent, it also reminds me of the “law of requisite variety”, first formulated by Ashby in 1956 speaking of his first homeostats (Pickering 2004), where the problem of the design of sufficiently flexible and complex structures can be rephrased in the following terms: a system can support something else (another system or an actor) only to the extent that it has sufficient internal variety that can couple the variety of the other system.

Discussing this conditional pattern would make it necessary to dwell on the details of rule-based programming (or on the specific artifact logic of partitioning) and would be out of the scope of this paper.