The Generative Role of Objects in Infrastructure Design: A Case of Designing a System for Continuity of Care

Abstract

This study explores the generative role of objects in design work. While the CSCW literature includes a range of contributions on infrastructure design and ways of accounting for diverse existing systems, practices and perspectives in design, the focus has typically been on the point of use, rather than the earlier stages of design processes. However, as more worker groups become involved in design there is a need to understand the microdynamics of collaborative design in this phase and the interplay between problem framing and exploration. We examined how the design of an information system in the health sector evolved through the instantiation and exploration of intermediary objects that become generative in the design process. The data comprised observations over 2 years from design meetings with a team of health professionals and software developers mandated to develop a system for the registration and sharing of patient information across primary care units. The analysis showed how intermediary objects formed focal points from which infrastructure design problems were framed and collectively explored. These processes required considerable negotiation and exploration within and between the interdependencies that become relevant in the design process. We identified how intermediary objects take different representational forms and become generative in two ways: By producing new or transformed objects, and by revealing layers of complexity inherent in the design problem. We discussed implications of the analysis as regards aspects of the infrastructure design that can be handled in the design team versus aspects that should be delegated to local adaptation.

1 Introduction

Design in healthcare increasingly concerns the design of systems for collaborative work, information sharing and flow among individuals and groups across locations, levels of care and care services (Fitzpatrick and Ellingsen 2013). Infrastructure design has been proposed as a way to understand design activities that go beyond designing for a local predefined context of use and take into account openness in the types and number of users, the multiplicity of agendas and purposes and the numerous and diverse existing systems and practices in multiple contexts of use (Monteiro et al. 2013). To better grasp these design processes and their challenges, research on infrastructure design has suggested that design be conceptualised as installed base cultivation (Aanestad et al. 2017), generification (Pollock and Williams 2010) and continuous design and infrastructuring (Bossen and Markussen 2010; Grisot and Vassilakopoulou 2017; Karasti et al. 2018; Pipek and Wulf 2009). These perspectives emphasise the incremental and emerging nature of infrastructures in relation to use practices and implementation strategies. Less attention has been given to the early stages of infrastructure design, when infrastructural decisions are taken before any implementation, use or scaling up takes place.

In this paper, our interest is in early-stage infrastructure design, and we explore the role of objects in processes during this time. Objects are representations and reference points for explanations and interpretations that are key to design work (Eckert and Boujut 2003; Vinck 2012). In design work, objects can be different kinds of artefacts, such as paper forms, probes, drawings, prototypes, models, screenshots as well as conceptual tools. They are useful in design because they concretise ideas, facilitate testing and probing and can be used for data gathering. In addition, objects have different functions in design, and most research has focused on how they work as boundary objects (BOs). A BO is defined as an artefact or concept with enough structure to support activities within separate social worlds and elasticity to cut across multiple social worlds (Star and Griesemer 1989). Scholars of CSCW have, for instance, examined how boundary objects are created and maintained (Bossen et al. 2014) and renegotiated (Lutters and Ackerman 2007), evolve (Pennington 2010) and are part of common information spaces (Schmidt and Bannon 1992). Understanding objects in design as BOs drives attention to the coordinative role of artefacts in practice (Lee 2007). Other studies have explored the role of objects beyond BO, such as how ideational objects of activity provide a joint purpose and direction in design work (Hyysalo 2005).

In this paper we take a less common direction in relation to the role of objects in design and focus on the generative dynamics that objects trigger and how these dynamics ‘push forward’ design while at the same time capturing the generative processes of gradual object construction. To this end, we build on research on design that has conceptualised and analysed artefacts such as drawings, models and technologies as representations that take shifting functions in an activity with the capacity to stimulate further exploration and development (Beltagui et al. 2023; Ewenstein and Whyte 2009). Visual representations and other material objects may in one sense appear as ready at hand, to be immediately employed or integrated in design processes; however, these are always partial representations of the design in progress that often change and acquire new properties as they are explored and developed. This ‘lack of completeness’ keeps these objects unfolding, as their representation never quite catches up with their empirical complexity and tends to display what is still missing and where to look further (Knorr Cetina 1997, 2001).

To examine the generative character of objects in the context of infrastructure design, we make use of the concept of intermediary objects, drawing on the work of Vinck (2012). Intermediary objects are temporary instantiations of design problems that delimit the participants’ focus and provide the framing of a specific part of the design on which to work. When applying the concept of intermediary objects to the study of infrastructure design, analytical attention is drawn to the microdynamics of how the participants in design activities identify and work on workable intermediary objects (e.g. prototypes, sketches, models, text, storyboards, interview guides or pictures). This focus can reveal important generative mechanisms in the infrastructure design process. We argue that the microdynamics of infrastructure design at the interplay between problem framing and exploration has not received much attention in CSCW research. By placing the ongoing, provisional, evolving and explorative nature of infrastructure design work in the foreground, we analyse ways in which problems and objects are framed and negotiated and act back onto the design. Thus, we aim to enhance our understanding of how infrastructure design problems are made workable through object construction and of what this work implies for participants. We address the following research questions. (1) How are intermediary objects constructed in infrastructure design? (2) In what ways are these objects generative in the design process?

To address our research questions, we conduct an empirical case study of how participants in a design team design a system that supports access to and the registration and sharing of patient information in patient handovers across city districts and primary care health services in a large municipality in Norway. In our study, the participants consist of representatives of city districts, rehabilitation centres and nursing homes and IT experts. Therefore, they bring insights from different angles when contributing to addressing infrastructure design problems. We found that intermediary objects were instantiatiated in a variety of modalities (e.g., as visual representations in the interface, narratives, written work routines and storytelling). Further, the intermediary objects are drivers in design work that embody and reveal shifting aspects of the wider infrastructural interdependencies, as they ‘branch out’ and ‘unfold’ (respectively, by producing transformed objects and revealing layers of a design problem). Our study has three contributions. First, we contribute to improving understanding of microdynamics in infrastructure design and of the nature of infrastructure design problems. Second, we conceptualise different mechanisms that make objects generative in infrastructure design. Third, by analysing the complex interdependencies of collaboration as they emerge in the design for continuity of care, we contribute to a more detailed understanding of current design challenges in this field. We discuss implications of the analysis as regards aspects of the infrastructure design that can be handled in the design team versus aspects that should be delegated to local adaptation.

The rest of the paper is structured as follows. In the following section, we review studies of infrastructure design and then present our analytical framework, based on the concept of intermediary objects. In Section 3, we describe the research methodology, which includes the empirical setting of the study and how we have performed data collection and analysis. We then present our findings in Section 4, focusing on how the design process unfolded, based on three empirical illustrations of the construction of intermediate objects. In Section 5, we discuss the generative role of objects in design work and the contributions, and in Section 6, we provide the concluding remarks.

2 Related Work

2.1 CSCW Infrastructure Design Research

We position this research in the CSCW literature on the design of information infrastructure. This body of work investigates how design processes are different from traditional design when it comes to infrastructures. By information infrastructures, we follow Monteiro et al.’s (2013) definition of infrastructures as large sociotechnical systems that support collaborative work on a large scale, meaning across diverse and distributed contexts of use. For instance, research infrastructures (or cyberinfrastructures) support the collaborative work of a distributed research collective by offering shared resources such as data repositories, standards and instruments (e.g. Karasti et al. 2010; Parmiggiani et al. 2015; Ribes 2017). Information infrastructures, which are also characterised by openness, support the collaborative work of many diverse communities and user groups across disciplines and work practices (Pollock and Williams 2010). For instance, a hospital information infrastructure supports the work of physicians from different disciplines, nurses, lab technicians and other health professionals (e.g. Bossen and Markussen 2010).

Studies have shown that the design of successful infrastructures (those that support their users’ needs in different contexts of use) should start with a small-scale approach, targeting a specific problem area and context of use, and then gradually scale up (Aanestad et al. 2017; Hanseth and Aanestad 2003). This incremental view on design implies paying attention to the initial installed base of existing systems and work practices and ‘cultivate’ its growth (Aanestad et al. 2017). However, even in the small-scale at the early stage of infrastructure design, the installed base is heterogeneous, distributed and embedded into multiple different work practices and contexts of use and necessitates accounting for multiple interests. As Pollock and Williams (2010) argued, ‘the need for such systems to cater for a wide range of current users and uses (and, given their development costs and intended longevity, potential future users and uses) makes their design and further evolution potentially challenging’ (522). One main challenge concerns how to account for and deal with the needs of diverse locals and interdependencies across work contexts. In a study of the implementation of a common laboratory system in several laboratories at the same hospital, Ellingsen and Monteiro (2006) showed how the differences between two laboratory practices (two locals) defied an attempt at standardisation across contexts because the infrastructure connected fundamentally different practices with different problem understanding, tools, analytical practices and types of results. Bossen and Markussen (2010) showed how an electronic medication module was part of an infrastructure that crossed several practice communities (clinicians on wards, accountants and pharmacies) and had the capacity to support ‘different the kinds of ordering that are inevitably at work when practices and artefacts become part of infrastructures’ (617). Thus, to account for this diversity, they suggested conceptualising the module as an ordering device enabling different kinds of orders. Piras and Zanutto (2010) studied the use of personal health records with a focus on how these records are part of an infrastructure that intersects health organisational settings and domestic environments. The study showed the differences in the abilities of doctors and lay people to enter, use and interpret the information in the records and the importance of not obscuring the value of patient practices. These studies showed that as infrastructures work across multiple and different contexts of use, it is challenging to account for their different information and communication needs and practices while also designing a shared resource. Studies have conceptualised this in terms of tension between the ‘local and the global’ in the design of the standards embedded in the infrastructure. For instance, Rolland and Monteiro (2002) showed that local needs, relative to universal ones, must always be weighted and argued that ‘design, then, amounts to tracing the costs and benefits, distribution, and voices of the associated transformations in order to work out a reasonable balance’ (98). Similarly, Edwards et al. (2009) argued that infrastructure design is about making ‘the most appropriate trade-off between a number of goals that may be more or less in conflict (e.g. between catering to specific local needs and meeting larger community goals, or between short-term and potentially evolving longer-term requirements)’ (371). One way to handle trade-offs in design is to pay attention to and differentiate between boundary factors represented within the shared artefact, and the ‘contextual contingencies form[ing] the basis for constructing localized versions of the shared application’ (Bjørn et al. 2009, 428). Such work requires detailed exploration of diverse practices. Furthermore, it requires negotiation and sorting between the functionalities and categories of a shared artefact, and its multiple relations, meanings, and contexts of use (Bjørn and Hertzum 2011; Cerna et al. 2020; Sadorge et al. 2023).

The importance of taking an incremental approach to infrastructure design has been acknowledged in CSCW research, although the focus has mostly been on the point of use, when infrastructures meet multiple distributed users, their work practices and the surroundings into which the artefacts are placed (Parmiggiani et al. 2015; Pipek and Wulf 2009). In use, tensions emerge as standards and standardisation effects become visible and can be contested in practice (Ellingsen and Monteiro 2006; Rolland and Monteiro 2002). Infrastructures are also shaped by users, who add new elements, improve parts and replace elements that do not support their work (Hanseth and Lundberg 2001). Moreover, intervention through maintenance and repair (Jackson et al. 2012) and the repurposing of components (Grisot and Vassilakopoulou 2017) shapes infrastructures. However, discussions and decisions on what to standardise and the level of standardisation take place at an earlier stage of design, when the participants in design activities make sense of and address infrastructure design problems. Such early-stage processes have received less investigation. In this paper, we pay attention to how infrastructure design problems unfold, keep branching out, become workable, and are worked upon. With this aim, we make use of the concept of intermediate objects, presented in the next section.

2.2 Intermediary Objects and their Generative Functions

Interest in approaching objects not only as tools for activities but also as carriers of generative forces emerged from studies of collaborative work and organisational processes in the 2000s (see e.g. special issues in the journals Organization (2005, vol. 12, no. 3) and Mind, Culture, and Activity (2005, vol. 12, no. 1)). This interest also manifested in studies of design work, often with an interest in analysing evolving activity systems in relation to objects of activity (Hyysalo 2005; Paavola and Miettinen 2019).

In this paper, we draw on the work of Dominique Vinck (Vinck 2012; Vinck and Jeantet 1995) and his concept of intermediary objects. Similar to the concept of BO, intermediary objects stem from an interest in understanding the heterogeneity of the social worlds of science (Vinck 2012). However, rather than aiming to understand how several social worlds collaborate through objects that take a boundary-crossing function (Lee 2007), the concept of intermediary objects makes it possible to examine how the creative–constructive processes in design work evolve through a series of temporary object instantiations (Vinck 2012). Thus, analytical attention is given to how intermediary objects are worked on in the relationship between actors and their knowledge production function (i.e. what is generated in a given situation).

Vinck (2012) argued that objects are not ‘simply reflect[ing] social relations and intentions; they also inherit something from the materiality, abilities and tools used to make them’ (103). As such, they become active and consequential contributors in the design process. Following Vinck (2012), intermediary objects can take three main functions in activity that are generative in different ways. First, intermediary objects can materialise part of the infrastructure that makes further development possible. Through this materialisation, some aspects are (temporarily) stabilised, making it possible to develop others. Second, intermediary objects can mediate collaborative sensemaking, where materiality acts as a focal point for sorting out ambiguity, potential surprises may appear and the translation of meaning can be observed in the design work. Third, intermediary objects frame actions and structure activity by defining a space for participants’ actions. This structuring can be accepted, unwanted or negotiated as new departure points arise with new object framing. Possible openings or the exclusion of further avenues for professional work (e.g. who should account for what and who controls this part of the object) can be analytically traced by following the material instantiations of intermediary objects (Vinck 2012).

In the context of infrastructure design, the concept of intermediary objects is useful for studying design work in situ with an interest in how interdependencies and connectivities are explored and managed collaboratively. This includes the more fine-grained processes of materialisation and the capture of the generative processes of gradual object construction in collaborative design. As intermediary objects change throughout design cycles, new avenues for action are constructed, structuring the activity by framing and limiting concerns that can be addressed in the discursive space provided by the objects. Pedersen (2020) illustrated these changing dynamics in her study of designing solutions with patients for faster recovery from stroke. In the design process, the framing changed along the way as the designer (the author) and user participants (the stroke patients) interpreted and negotiated intermediary objects such as storyboards, interview guides and quotes. The framing provided by an object may lead to an exploration of a problem that reveals underlying problems or new objects. In her example, photographs were unexpectedly introduced into the negotiation space by a user participant. Thus, the negotiations were altered because the new object provided a new framing, and therefore possibilities for generating new ideas and objects (Pedersen 2020).

In CSCW research, the concept of intermediary objects was introduced in 2003 in a special issue on objects in the Journal of CSCW (Eckert and Boujut 2003). In it, Boujut and Blanco (2003), based on a case of production development in the car industry, showed how the shared framing of intermediary objects fostered the emergence of solutions and further cooperation among the participants. Other research on the role of intermediary objects has shown how such objects can, through their coordinative functions, become increasingly sophisticated in iterations whereby participants interact with the materiality (Lauff et al. 2018). Lauff et al. (2018) illustrated this in their study of a prototype that increasingly embodied factors, conversations and descions that came together over time when worked upon by engineering students designing for a sustainable health community. Also, studies have examined the role of intermediary objects in architectural design. Paavola and Miettinen (2019) analysed building information models (BIMs) as tangible intermediary objects that embody forms of human activity and knowledge. BIMs are described as three-dimensional models that can integrate multiple stakeholder concerns and design principles in advanced visualisations and simulations of building ‘behaviours’ (e.g. energy consumption), thereby allowing new forms of collaboration in the design process. Moreover, the authors discussed how the joint reflection, (re)negotiation and problem-solving of design cycles are central means for collaboration and emerging functionalities. They showed how cognitive norms and standards emerge and materialise as multiple and interdependent design aspects are combined and ordered together (Miettinen and Paavola 2018). Thus, the dynamics of translating, mediating and representing knowledge become interlinked in the medium of representation as collectively defined references and shared frames that foster cooperation and orient future choices.

Building on these insights and conceptualisations, in this paper, we use the concept of intermediary objects to analyse the explorative, fine-grained and generative knowledge processes of infrastructural design work. Specifically, we attend to how the design participants’ work on intermediary objects relates to the evolving infrastructure design. In the analysis, we show how this work proceeds through the framing and exploration of workable design problems that form connections or address interdependencies in the wider infrastructure.

3 Research Methodology

This paper is based on a longitudinal case study conducted over two years (2020–2022) where we followed the design of an information system that supported the accessing, registering and sharing of patient information/data for health professionals involved in care pathways across contexts of care.

3.1 Empirical Setting

Our empirical case study was a design project for the municipal health service of a large Norwegian city. The project was launched in 2018 as a joint initiative between four city districts with the aim of enhancing coordination and improving the quality of patient handover between care units. The project was adopted in 2020 by the city’s central health agency and embedded in its broader digitalisation agenda. A core design team (see Table 1) was established by the central health agency that consisted of an externally hired project leader (PL), a developer employed by the central health agency and 3–6 healthcare workers from different city districts and care units, referred to as implementation coordinators (ICs). These care workers were from a range of professional backgrounds and had no previous experience as designers.

Table 1. Team members, their professional backgrounds, and affiliations.

The ICs participated based on their care unit’s commitment to the project, which shifted throughout the project period as care units joined and paused their participation for different reasons (e.g. other priorities or lack of resources). In addition, the project experienced shifting conditions, from a halt in technical development due to the Covid-19 pandemic to there being greater and more concrete political ambitions for expanding the use of the information system to all city districts (see Fig. 1).

Figure 1.

Simplified timeline of the design project.

The composition of the team reflected the recognition that such design projects should not be restricted to technological design but needed to be grounded in and become consequential for the services provided. At the time of writing, the information system had been partially implemented in selected healthcare units, while further functionality was in development and additional units were planning to implement the system.

As in several other countries, the Norwegian health sector is increasingly aiming for greater integration of fragmented parts of health services to provide better ones for patients and to better limit and prevent diseases (see the white paper Meld. St. 47 to Parliament from the Ministry of Health and Care, 2008–2009). In this regard, certain responsibilities have been relocated, displacing care from secondary care (specialist healthcare, such as hospitals) to primary care (care providers in municipalities). One implication of this displacement is that patients might start their treatment in hospitals before being discharged early and then continuing their treatment in primary care. Continued care provided to patients between services has thus become central in integrating services across institutions. This was also a factor that motivated the design project, as its central aim was to coordinate tasks across institutions, make them available and facilitate the exchange of information and data in real time.

The project intended to deliver a solution that would be scaled up to all city districts, rehabilitation centres and nursing homes in the municipality. The system being developed was an information system with an interface for visualising patient data that would work on personal computers (PCs), digital whiteboards and mobile phones. The application was built on a data platform that harvested data from the main health registers, had an API that linked to the municipal patient record system and included existing standards, such as the National Early Warning Score (NEWS) for the detection of clinical deterioration in patients and the Mini Nutritional Assessment (MNA). The system was developed on a low-code development platform with a simplified app-building process that enabled non-experts to build apps. The platform also supported a continuous design approach in which parts of the app could be tested and implemented without requiring the solution to be fully developed. For the project, this meant that the design, development and implementation activities ran in parallel.

The combination of these parallel activities and the infrastructure quality of the solution, in addition to the possible transformative potential for health services, caused the design project to be rather complex. Making design problems graspable and tangible in this setting is challenging, as it requires investigating and accounting for multiple stakeholders, interests, sites, interdependencies and tensions.

3.2 Data Collection and Analysis

We applied an ethnographically informed approach to study the design work as it unfolded in its natural setting (Bjørn and Østerlund 2014; Randall et al. 2007). The full data corpus underlying this research consisted of meeting observations (178 h), three interviews and 74 discussions with key participants as well as project documents (e.g. meeting agendas, historical documentation, presentations, screenshots of the system and strategy documents) accessed through the project’s digital portal. The analysis in this paper is based on data collected from October 2020 to July 2021 from weekly talks with key participants and observations from design meetings (see Fig. 2). During this period, the design work was organised into regular meetings carried out once or twice per week. Due to the Covid-19 pandemic, all meetings were carried out digitally through the Microsoft Teams platform. Observations of the meetings were either video- or voice-recorded and supplemented with handwritten field notes. The meetings on the Teams screen were recorded using an external camera (invisible to the participants) due to screen recording restrictions. The first and third author participated together in most of the data collection. Written consent was collected through digital forms, and our presence was explicated when new participants joined.

Figure 2.

Timeline of the design project and data collection activities with marking of the empirical examples presented in the Findings section.

The meetings typically began with a review of the previous week’s work and ended with decisions on what should be done next. Due to the online format of the meetings, the group dynamic of the design team may have evolved differently to how it would have evolved in face-to-face meetings. Nevertheless, this was how the work proceeded over a long period of time, and we therefore followed what was an authentic activity for the participants. Our experience of the meetings was that they had been well-organised and that everyone participated actively in the discussions. We would quietly observe them by showing our faces to the camera, like the other participants, but with our microphones muted throughout the meetings. Since it became difficult to talk informally to the participants during breaks and before and after meetings, we arranged weekly informal talks with two key participants seperately on Teams (the PL [40] and the most active IC [34]) to deepen our understanding of the work carried out and to include their reflections. These discussions provided additional insights into the participants’ reflections and experiences. In addition, they provided opportunities for us to validate our preliminary interpretations and examine particularly interesting topics in a more thorough way.

The data analysis was conducted over several steps. First, we reviewed the entire data corpus and conducted an initial coding of the design problems in the meeting discussions. The identified central design problems that the team worked on showed that issues related to visualising patient information were frequent and recurrent topics under discussion. Moreover, these discussions were concerned with and tightly coupled to working practices in the health units. Twenty-four of the meetings in which these discussions were prominent were selected for a preliminary analysis, and particularly rich and significant episodes from these meetings were transcribed, which departed from the framing of the design problem (Derry et al. 2010; Jordan and Henderson 1995). Second, these discussions were analysed further to gain insight and reveal how the design team had constructed and explored a series of intermediary objects. Following Vinck’s (2012) notions, we looked for how partial problems had been framed and instantiated as a focus for joint exploration and how this framing had guided the possible routes for exploration and action. Such problem framing was observable through the ways participants formulated questions, brought up ideas in their discussions or presented a visual image as being unresolved. Special attention was given to how the problem framing had activated different infrastructural dependencies and made other actors or contexts part of the evolving problem complex. Moreover, by following the object as an analytical strategy, we examined how the initially framed intermediary objects were transformed as the participants explored them and worked to reveal their potential. Finally, we considered the outcomes of the explorative processes and how they were related to the overall design of the information system. The data excerpts and interpretations were iteratively and collaboratively analysed by the authors and discussed with colleagues in the broader research team. Next, the results from our analysis are presented through three examples (see Fig. 2) of design problems with different infrastructural concerns and challenges that the team faced in working to improve the continuity of care in the municipality.

4 Findings

The work of designing for patient information sharing across units and securing continuity in the care pathway was stretched out both spatially and temporally. Decisions on care will often be made by reflecting on past incidents and increasingly with the aim of preventing future incidents. When a patient’s follow-up is taken over by a new care unit, the ways of registering and using information in the two locations become matters of coordination. How these aspects of care work are accounted for in the design process depends on the way intermediary objects are framed and examined. Moreover, such processes are typically iterative in the sense that design problems re-emerge in different phases as temporarily agreed-upon solutions are opened up for further exploration.

We start our analysis at a point in time when the design team was attending to ways of supporting continuity in care pathways over some time. In this work, they reviewed guidelines and ways of modelling pathways from national-level and central municipality-level projects aimed at improving patient flows in the services, which occasionally were mobilised as resources in their work. Recurrent problems raised in their discussions had to do with functionalities related to responsible care units and their registration of patient information, ways of visualising patient information in the system and how to interpret and address design ambitions and priorities communicated by the steering group. Often during their discussions, the PL shared the interface or models of the information system to support their work. Figure 3 illustrates an example of the team’s efforts to organise different elements, such as categories, functionalities and visualisations, in the interface.

Figure 3.

Example of a model presented by the PL showing the Summary tab of the system’s interface.

To address recurrent problems and their relevant interdependencies, the team’s attention was alternately directed towards the information system and the services, and they engaged in different activities, such as developing and discussing flow diagrams illustrating processes of patient and work flows, testing functionalities in their respective care units and sharing these experiences in the design meetings.

Our analysis focuses on how the design process unfolded by examining these oscillations and explorations in greater detail. We present three examples of how the team constructed intermediate objects to handle problems associated with designing for information sharing and where specific infrastructural interdependencies become relevant for the design problems.

These three examples are as follows: 1) visualising patient information to support a variety of care practices, 2) standardising service routines across care units 3) digitising and visualising medical procedures developed for specialist care. As we will show, the intermediary objects branched out in a range of sub-questions when they were explored, leading to further differentiated objects that fed into the design and shaped the design process.

In the data excerpts, we use the following abbreviations: PL = project leader, IC1-6 = ICs from various healthcare units (city districts, nursing homes and rehabilitation centres) and D = developer. Throughout the analysis, italics are used to highlight (suggested) information categories displayed in the interface of the system. See full transcription legend in appendix 6..

4.1 Ordering and Displaying Current Patient Information in the Interface

To design a technology for information sharing across units and secure continuity in the care pathway, a first problem to address is to visually display the most important information for the receiving care unit. This problem is multifaceted, as it involves issues, such as what information needs to be available for the receiving unit, how it can be accessed and used to start a new phase in the care work and the implications of these considerations for the design of interfaces and functionalities.

4.1.1 Example 1

We enter the meeting as the PL is sharing her screen, showing the patient Summary tab. As the PL is asking the ICs for their opinions on the organisation and visualisation of elements in the Summary tab, she scrolls to the bottom of the summary page and stops at the lower left side of the Summary by the tab Start-up conversation executed with a red dot beneath and the word No (which can turn to green/yes) (Fig. 4):

Mm, what do you think of the way it is shown now? Now, we have the latest ADL score to the upper left, and then there is Infections. User status is in the middle. Coordination journals. Here is the new NEWS and Services. We had a discussion about Start-up conversations (.) For the time being, we have added it as a manual registration. Start-up conversation is different in primary care and rehabilitation centres (PL).

Figure 4.

Sketched illustration depicting the patient Summary tab in the interface of the information system, shared on-screen during the meeting by the PL.

By asking the design team ‘What do you think of the way it is shown now?’ while pointing to the lack of clarity regarding the information status of start-up conversations, two interrelated problems are opened up: how information at patients’ arrivals can be registered in the system and what kind of routines¹ for registration exist when new patients are transferred to a health unit. As a result of previous discussions among the team, the start-up conversation has been temporarily stabilised as a vital information item for manual registration in the patient summary. Thus, the visual manifestation of the design team’s previous discussions in the interface is functioning as an intermediary object for them, as the PL indicates that they are aware that this is not resolved. As shown in the exchange below, differences in how such conversations are conducted and what functions they serve need to be further explored along with suggestions for displaying categories and registration opportunities in the system, which generate a further differentiation of this intermediary object:

IC1	No, I was thinking if we could make it a bit rounder and call it a type of mapping conversation or assessment conversation and not to lock it too much towards start-up, which is a bit diffuse. We have start-up after we have had both start-up, and then we have start-up after homecoming from the rehabilitation centre. What we do is assess or map because you might come in conflict with the project ‘Continuity of Patient Care’. In this project, there is start-up and assessment, and that is six conversations you need to work through before you have completed that care pathway. That is maybe the way to do it, but we could have done it with a date and a bit rounder of a title
PL	Mm. But aren’t you saying that in ‘Continuity of Patient Care’ [the project], different kinds of conversations have been identified? That there may be a difference between a start-up conversation and an assessment conversation?
IC1	It is not only that. It is three different functions that are supposed to account for three different start-up conversations, so it is quite complex if you are to cover this entire logic. I’m thinking that if you have done a mapping or assessment and the last date for that assessment, then you know the last date and who executed it

In this exchange between one of the ICs and the PL, further distinctions are made about the types of conversations and their functions relative to time. To handle this complexity as a design problem, outcomes from a parallel project called ‘Continuity of Patient Care’ is mobilised as an authoritative procedure. In turn, a suggestion for differentiating categories of conversations to cover more of the tasks related to a patient’s arrival and a date for when a mapping or evaluation took place could conceivably lead to a design decision. What happens, however, is that the intermediate object branches out yet again as new questions arise, leading to an exploration of potential variations in routines across health units. PL asks to what degree start-up conversations are ‘well-defined’ and how arrivals are handled in rehabilitation centres. One of the ICs replies with the following:

At the rehabilitation centre, we engage in start-up conversations, and then we have network meetings simply when it is needed. Often, it is to establish the type of goal for the patients for the stay. For the patient and relatives, as far as they have the opportunity and primary care as far as they have the opportunity to join. Maybe one should have another type of arrangement for this, where maybe you can choose what kind of conversations you have executed and a date. Like for the service users in the city district [Primary Care], a start-up conversation or a mapping conversation (IC2).

This description of the rehabilitation centre confirms the differentiation of the types of conversations and brings the focus back to how these conversations can be registered and shown in the information system. This allows PL to reinstantiate a version of the intermediary object they started with; design solutions for information registration at transfer and arrivals:

We are back to, is this a task, or is it an appointment? Making a variable for start-up conversations is a quick fix. Maybe gradually we can do like you [IC3] in [City District 1] started with, and which you have started to look at in [City District 2], right? IC3 has started to look at what happens when one comes home (…) It is important for institutions, at least for rehabilitation centres, to follow up on their service users in their overviews very concretely; have we done what we have to do this far after the service user arrives? (PL)

While the above in part concludes their discussion and what should happen next, another differentiation is made between tasks and appointments. This leads to another version of the intermediary object being instantiated, which had to do with the status of patient information upon arrival and how it should be followed up. Tasks and appointments have in earlier design meetings been approved as standardised categories for delegating responsibilities for information registration, with different scopes of action. As these distinctions are brought into the discussion, the envisioned design solutions become more concrete and linked to an imagined workflow. PL verbalises a potential stepwise flow that could be visualised in the system in using tasks:

Okay, imagine, now we are here, now we get a new service user, then one makes a task that is called an assessment visit and conveys it to IC4, and then she executes it and checks off the task [as completed]. Then there exists a task that is called an assessment visit that has a date for when it was checked off, and inasmuch as who checks it off. Mmmmm and as IC4 says, right, how can they quickly see (.) But where do you want to see it IC4? ((laughs)) (PL).

At this point, they temporarily cease the discussion regarding the start-up conversation while the PL verbalises the work and visualisation flow of receiving a new patient at the care unit, creating a New service user task and assigning the task to a health care personnel (HCP), who in turn execute the task and mark the task as completed. The PL then reinstantiate the object they started out with, with the question of how to visualise this information for HCPs to quickly orient themselves. This leads the D to suggest a visualisation of the tasks in a timeline with executed tasks, a task owner and a task type. As this solution is accepted, IC1 reminds the team again of the need to standardise and integrate different concepts across units by not making distinct and very different ‘things’ across units.

4.1.2 Summary

In this example, the team worked on part of the larger infrastructure that had to do with the design of a solution for visualising patient information upon patient handovers. This visual framing of an intermediary object provided a tangible, focal point for the team to start exploring what key information should be displayed to get an overview of a newly arrived patient. However, rather than generating a solution to this problem, the intermediary object branched out in many directions by generating questions about registering information at arrival in the system and in the services; variations in the types of conversations and the diverse functions they serve; and differences in routines across participating health units. The team needed to pursue these instantiations and explore their possibilities before they could again attend to the interface issue and temporarily decide on a design solution. In this example, the evolving differentiation of conceptual categories to be displayed on the interface formed an important generative mechanism. These categories, denoting types of conversations, tasks and appointments, mobilised back and forth explorations between the interface and its envisioned use in the services, which spurred further object construction. As such, the explorations served to reveal interdependencies between the categorisation of information in the system and the care practices in the service units and to connect instances of practice across time and space. We note that (1) while the initial problem framing concerned the design to promote information sharing at a certain moment in the care pathway (during patient handovers), the object unfolded to open up other temporal and spatial lines of exploration. In this way, these explorations are connected to other parts of the larger problem complex: the system and its interlinked components. Furthermore, (2) the work on the intermediate object made it possible for the team to temporarily stabilise aspects of the design, which then fed into the larger evolving infrastructure.

4.2 Exploring and Standardising Service Routines

A second design problem was related to the need for standardised routines for generating and registering information. This problem incorporated issues about ways to register information in different units, how and what information can be shared between units, what changes need to be made in the health services to be able to share information between units and the implications of these considerations for the design of registration opportunities, interfaces and functionalities.

4.2.1 Example 2

The PL has regular meetings with the steering group, where she reports and discusses concerns and the progress of the design project, which, in turn, enables the steering group to make decisions and prioritise tasks in the time to come. One long-term aim of the project owners has been that the system should serve as a standardisation tool to secure equal care services across city districts and care units. This aim has been discussed recurrently in both the steering group meetings and the design meetings. At this point the design project has reached a phase where the initial functionalities are being tested out by health services, leading the design team to the practical design problem of the degree to which they should standardise the information routines across the services. What has made it even more challenging for the design team is the ambition to standardise not only for participating units but also for other future participating units as the technology is scaled. IC1 reflected on standards in a weekly talk:

What is nice with standards (.) is that, if you make too weird solutions or too narrow solutions, you are not able to implement it in the entire municipality. It is too bad if this becomes a tiny project in some city districts. The aim [for the project] must be to target all 15 city districts and then to get the university hospital to join. That is the hardest part ((laughs)) (IC1).

These design concerns also came up in the design meetings. In one meeting, at a time when a limited version of the system was being tested in one city district, PL displays a PowerPoint slide with the heading Experiences thus far – low capacity centrally and locally affects the pace of further development and implementation. This slide is displayed for 35 min, as it features profound issues regarding how to proceed with the design process. One of the issues raised by the PL is the expectations of the steering group that routines need to be standardised, which frames the discussion for the team. Next, a way forward in the design process is explicated, as the PL instructs the ICs to ‘start writing down routines’, share the routines with the design team, get input from others and adjust thereafter to be able to standardise routines and functionalities across services.

While the PL reminds them and makes clear to follow this procedure from now on, one city district has already written and shared their routine. IC6 from a rehabilitation centre looked at the city district’s routine and report back that the routine is not directly transferable to them, as they work in different ways. While the written routine function as a reference for comparing specific procedures across services, the team engages in a meta-level discussion in large parts of the meeting on how to standardise. This allows the team to construct multiple intermediary objects, starting with the form of routines:

(…) I have as an aim, and you can surely come with objections, that the routines must be as short and concise as possible (…) I know that if you are standing out there [delivering care] and the document is three pages long, you don’t cope (…) Too long procedures are a nightmare when you are out there and are supposed to work (IC1).

One concern regarding the form of the routine is turned into a workable problem as it become related to experiences of HCPs in their frontline work. IC1 argues that routines should be short, as long routines are a nightmare to relate to during work. The form of the routine is acknowledged as a relevant concern. The intermediary object branches out, as the PL differentiate between the types of routines:

Maybe one could imagine that (.) if one gets far enough, one reaches a type of functional user guideline; this is how you execute NEWS. That should not vary. However, when and in which larger processes one should execute it, it is very different (PL).

As differences between types of routines are articulated, the team explores these further by moving between executing NEWS and relating NEWS to the wider work process. This leads them to explore similarities and differences between types of care units and who needs to team up to standardise service routines:

It is nice if, for procedures that are similar, such as assessments like MNA [Mini Nutritional Assessment], we are able to get them as similar as possible. I think that some of the processual routines may have to be different. It is important that we [City District 2] and City District 1, at least the city districts, that primary care can agree on something, so we don’t get ten different [routines] ((laughs)). I think that at the moment, we are about to create routines where we meet each other, like, for instance, in the transfer from primary care to long-term care [nursing homes], or short-term care [rehabilitation centres], we have to figure it out together. I think that it is important that we have a shared understanding ((laughs shortly)) of what happens in the long term, what happens in city districts and how to use [the system] in that junction. So, there are many sub-categories of types of routines that require different work (IC1).

In this process, a slightly different problem surfaces: another standardisation strategy must be developed to facilitate patient information sharing in the transfer between non-similar units. This challenge spurs the PL to remind the team of the main message from the steering group:

[Rehabilitation centre 1] and eventually [Rehabilitation centre 2], you have to consider the other rehabilitation centres when you write up your routine, and [IC5 from nursing homes], you have to think of all the nursing homes when you write up your routine (PL).

Through this statement, she adds complexity to the design work. Standardising routines for the care units represented in the design team is not sufficient; the team must also account for the needs and characteristics of non-participating units in the municipality.

As the design team has explored different manifestations of the intermediary object in greater detail, they are able to differentiate between layers of the routines and how these relate to their opportunities to make decisions. The PL sorts and distinguishes what she calls the three dimensions in their design work and the interdependencies of these dimensions in the wider healthcare system. The three dimensions relate to medical knowledge, the technical solution in the interface and the work routines in the services:

There are three dimensions here. If we start with the medical procedure for registering vital measures, this is a professional procedure for which we have national guidelines (…). The health directorate works a lot with this, and the measures need to be fully standardised. Next, you have how to click on the solution, which one can make sure that explanations for how to use the different categories are embedded in the solution. Then, the third relates to the working process. There can be greater variations. Maybe you can think along these three dimensions (PL).

By way of these differentiations, it becomes clearer how the team can delimit their responsibilities based on the need to incorporate and account for working routines in the design. The design solutions they implement should be fully in line with established medical procedures for vital health measures, and the interface must integrate functionalities from the patient journal system. The service routines could be more flexible; however, to cater to this variation, the team needs to try out and share experiences from the development of routines in their various home units. Based on these insights, the PL rounds off the discussion by suggesting a way to use the design meetings to progress with this work:

I want you to use these meetings to present what you are working on, even if it is work in progress. You can add questions and trade-offs you consider (…). [Do we have] an idea of how to progress with this? I think we need to take our time with this before we start up with new functionalities (PL).

Even though some of these standardisation issues surfaced later in the design process, the team reached a temporary solution on how to proceed with the standardisation work (through writing, presenting and adjusting routines), which enabled them to move on in the design process.

4.2.2 Summary

This example shows, first, how an intermediary object was preliminarily instantiated as a concern regarding the standardisation of routines. This framing of the object, which was introduced as a demand from the project’s steering group, provided a focal point for the design team to start exploring what such standardisation might imply. This rather demanding requirement became more tangible as the team started to discuss how the routines are used in HCPs’ daily work, which generated questions about the form of a routine. From discussions about the routine’s form, the object further branched out into new and differentiated objects, such as multiple types of routines; what kind of care units can be standardised with each other, what can be kept different and what does this imply in terms of design considerations?

In line with the former example, the ongoing differentiation of the intermediary object formed a generative mechanism in the design work. However, in this case, the starting point was the services and the experienced variation in how work is done, from which the intermediary object branched out in a dynamic between concerns for standardisation and flexibility. Rather than reaching a temporary design solution, the outcome of these explorations was an agreed-upon need and a working plan for how to take these design problems forward.

4.3 Digitising and Displaying Medical Measures

A third design problem had to do with how vital medical information should be displayed to enhance the monitoring of patients over time. As illustrated in Fig. 3, this information included regular measures of the patient’s health condition related to standardised medical terms and procedures (e.g., NEWS and ADL scores). While these procedures are often standardised, they may not have been presented in a digital format or in an interface as developed in the context of the design project. Hence, considerations about how such information can be digitised, how it should be visualised and what it means to incorporate medical procedures from hospital settings into primary care became problems of design. The example that follows here shows how one such medical procedure and measurement, called NEWS, was proposed to be incorporated in the design through the instantiation of a series of intermediary objects.

4.3.1 Example 3

NEWS is a medical procedure to measure and register vital information about patients’ conditions. This information is therefore important to display in a clear manner in the patient overview. The visualisation of NEWS into the system was reflected upon by IC1 in a weekly talk, in which she said that ‘we were not supposed to change NEWS but make it digital’. Even though NEWS is an established procedure, it was not straightforward for the team to visualise it in the interface. IC1 had reached out to a major hospital and central agencies for quality assurance to consult them on the digitalisation of NEWS and expressed in this regard that there were many strong opinions in the field regarding NEWS and that ‘We have to make sure that what we deliver has high quality for it to reach as broadly as we want’.

From a design perspective, the challenges that IC1 reflected on included practical design issues that the team had to work upon and resolve. In one of the design meetings, ICs from two city districts are wrapping up a discussion on how to standardise NEWS routines (e.g., execute NEWS on Days 1 and 3 of patient arrival) and the challenges of following the routine. Next, the developer turns their attention to the interface by asking, ‘What’s the best way to visualise [NEWS]’? As the team was not able to find a digitalised model of how to visualise NEWS, they start investigating how services are using NEWS to provide information to D for her efforts to visualise NEWS:

D	If I could get some screenshots of how [NEWS] is visualised and some insights into how it is used, what do you look for first and what is less important? That would be nice for me
PL	As I understand it, based on the entire score, the compiled score is the trigger for the follow-up. That compiled score is the one that indicates, from a professional point of view, how ill the service user is (…). As I remember it, one part is about the frequency of care. The other part is more about what D may be looking for, what do you look for (.) Do you just look at what it is that causes an increased NEWS [score]?
((Quiet for five seconds))
IC1	If I had seen a patient with a NEWS of three, I would have explored why. Is it a collection of several [sub-]scores that produce a score of three? Or is it only one score that produces a three? (…) This way, I think that showing the NEWS must be very relevant in the overview and then have the opportunity to quickly be able to see why. What scores produce an increased NEWS [the compiled score]…? At least, that is my opinion

In this excerpt, D instantiates an intermediary object by first asking what HCPs ‘look for initially’ when using NEWS. As the intermediary object now is framed by Ds question, the PL elaborates on the compiled NEWS score, indicating how severe a patient’s condition is according to the NEWS and a suggested observation frequency for HCPs towards the patient. By doing so, the object is transformed into a question about what NEWS signifies in medical terms. After the general indications of a medical condition are established as a fact, the PL turns to IC1 for information about other kinds of inquiries that the HCPs would perform based on a given NEWS score. In this way the intermediate object generate further distinction as IC1 differentiate, first, between the examination of single or multiple sub-scores causing a heightened overall NEWS, and next, if the individual patient historically has a high score as a default. In addition, IC1 adds further complexity by underscoring the need for HCPs to take into account the clinical observations of the patient, regardless of the score.

Even though concerns relating to the visualisation of NEWS and ways of implementing it as part of the system resurfaces later in the design process, the team has now reached a temporary conclusion, as D have acquired enough insight into the use of NEWS in healthcare services to proceed in developing a design solution for visualising vital patient information.

4.3.2 Summary

This example shows how a concern regarding visualising information served as an initial intermediary object in the design of a solution for displaying vital patient information over time. This framing of the object provided a tangible, focal point for the design team to start exploring what vital information should be displayed for HCPs to get an overview of a patient’s history. What we illustrated next is how this intermediary object branched out by generating questions about how vital information is registered in other units and how this information can be interpreted and acted upon. The generative mechanism in this example was the various interpretations of the NEWS as a procedure and the measurement of the patient’s medical condition. Even though the object construction in this example also evolved through explorative moves between the needs of the HCPs and the digital visualisation of information in the interface, these explorations were anchored in efforts to make sense of NEWS in medical terms and its consequences for care practices. In this way, the intermediary objects served to link the design work to the biomedical dimensions of care, through which interdependencies in a wider network of medical knowledge and the various actors authorised to define and warrant such knowledge were revealed and attended to.

5 Discussion

The aim of this study was to explore how infrastructure design problems are made workable through object construction and what this work implies for the participants. More specifically, we set out to examine how intermediary objects are constructed in design work and in what ways these objects are generative in the design process. We presented and analysed three examples from the design meetings in which design problems were framed and worked on. The examples relate to different infrastructural challenges: visualising patient information in ways that support a variety of care practices, standardising service routines across care units, and digitising and visualising medical procedures and critical measures. The findings are summarised in Table 2:

Table 2. Summary of analysis.

The analysis showed how the design work evolved through a series of object explorations related to partial design problems. Each of the three discussions commenced with the instantiation of an intermediary object, which was modified and gave rise to further explorations. This dynamic took place in the intersection of the material representations of the objects and the team’s ways of opening up infrastructural design problems for further examination and development. In the following, we discuss the generative mechanisms at play by addressing the way intermediary objects were instantiated and framed in different representational forms (RQ1) and the different mechanisms that made these objects generative in the design process (RQ2).

As summarised in Table 2, the intermediary objects were instantiated in a variety of modalities. While often starting from a visual representation in the interface, narratives and storytelling were prominent in the team’s efforts to examine the object and its infrastructural relations. Through these shifts in modalities, other spaces and timeframes for explorative work were opened. By shifting between visualisations in the interface, tentative models on the shared screen, narratives from the field and written work routines, the team was able to mobilise existing and envisioned work practices in their process of examining design problems and their possible solutions. Moreover, these movements made it possible to connect the infrastructure design to the procedural character of continuity in care and thereby manage various interdependencies.

As pointed to in other studies on infrastructure design in health care, interdependencies across work contexts are unveiled as the design process evolves, and generate a need to simultaneously explore the envisioned use of the information system in various user contexts and the way the technological and visual design can support work in these contexts (Ellingsen and Monteiro 2006; Bossen and Markussen 2010). While our analysis confirms this insight, we also demonstrate how this process rests on the instantiation of intermediary objects in different modalities for the design problems to become workable. The three examples showed how the instantiation of intermediary objects revealed but also emerged from different infrastructural challenges, which contributed to the further design dynamics. In example 2, the problem of standardising routines was brought in as an expectation from the steering group, linked to this group’s visions for the information system as a standardising tool in the services. In contrast, example 3 showed how an intermediary object was instantiated with reference to established biomedical knowledge and expertise in specialist health care and further differentiated through explorations in envisioned contexts of primary care. In these processes, the design participants needed to decode, explore and take advantage of knowledge in different forms and modalities. Interestingly, this included capacities to observe gaps in the knowledge system, such as the lack of a digital way of representing NEWS in example 3. Identifying and framing design problems are, therefore, not straightforward but require skilful practice and negotiation of epistemic and social concerns (Markauskaite and Goodyear 2017).

Table 2 also displays variation in the generative mechanisms and roles taken by the intermediary objects. All the three examples in the analysis show how the intermediary object is differentiated in the team’s discussion, leading to new object instantiations and explorations as the design work evolves. This process oscillates between the material instantiations of new objects (e.g. through a shift in representational forms) and the problem space formed by the new instantiation. Furthermore, the examples have in common that the intermediary objects become generative through their ways of adding complexity to the design problem, for instance by revealing differences in work routines between service contexts.

These generative dynamics resemble what is described in other contexts of design work. For instance, Lee (2007) showed that participants are ‘discovering, making, testing, developing, and arguing over practices and how to instantiate those practices into intermediary artifacts and end products’ (335), and Pennington (2010) argued that negotiations generate increasingly specified objects that may change both problem framing and collaboration. However, our analysis goes further to detail the very ways in which the objects perform their generative role. A main distinction here is what we, with reference to Knorr Cetina’s work, have termed as the objects’ capacities to ‘branch out’ and ‘unfold’ (Knorr Cetina 2001; see also Ewenstein and Whyte 2009). The mechanism of ‘branching out’ relates to how an intermediary object produces ‘offshoots’ that form new and transformed versions of the object with a different problem framing and space for action. These offshoots will often incorporate different infrastructural challenges, thereby being generative not only for the first design problem at hand but also for the evolving infrastructure design. In contrast, the mechanism of ‘unfolding’ relates to the intermediary objects’ inherent complexity and how it gradually displays layers of design problems when the participants try to reveal it. In our analysis this was most prominent in the third example, where the biomedical constellation of knowledge and procedures incorporated in NEWS ‘spring forth’ and provide new action spaces as the design team try to reveal its complexity. These mechanisms emerge in activity as interactional accomplishments between the design team, material representations and infrastructural challenges. The mechanisms may also alternate and nourish each other. However, for the design participants the generative capacities of the objects imply different challenges. To make productive use of the opportunities to branch out, capacities to envision and engage with other contexts and practices in the services are needed. Following the unfolding object will often require capacities for in-depth engagement with specialised knowledge and the way this is developed over time.

Based on these findings and insights, our study makes three contributions. First, we contribute to improving the understanding of micro dynamics in infrastructure design and of the nature of infrastructure design problems. Previous research has highlighted the need to incrementally ‘cultivate’ the growth of the installed base, beginning with specific problem areas and subsequently scaling up (Aanestad et al. 2017; Hanseth and Aanestad 2003). A differentiated incremental approach of design participants examining design problems is demonstrated through the object-driven dynamics, as the cultivation of the installed base, even on a smaller scale, is distributed and embedded in multiple work practices and contexts of use. Furthermore, as work practices have been shown to be challenging to understand and account for in design (Bjørn and Hertzum 2011), our study provides a detailed description of how the framing of intermediary objects emerge from healthcare professionals’ exploration and how these objects are dynamic in their way of mediating contextual contingencies. Second, we conceptualise different mechanisms that make objects generative in infrastructure design. While Lee (2007) and Pennington (2010) went beyond the coordinative functioning of objects to illustrate negotiations of practices into intermediary artefacts, we confirm these objectual understandings and take them a step further. In combining the concept of intermediary objects (Vinck 2012) with object notions on epistemic generativity (Knorr Cetina 2001) we bring object perspectives applied in other fields and domains (cf. Ewenstein and Whyte 2009; Paavola and Miettinen 2019) into infrastructural literature and display the various objectual dynamics on a micro level. Third, we contribute by analysing the complex interdependencies of collaboration as they emerge in the design for continuity of care, and we contribute a more detailed understanding of current design challenges in this field. Dealing with the infrastructural complexities demands representatives from different health units. In a design team, they contribute with explorative capacities of looking into different types of challenges, for instance by mobilising, sorting out and deciding on the relation between the design and contextual contingencies (e.g., concerns for standardisation and flexibility in example 2) and by incorporating medical knowledge and procedures from other care levels (e.g. NEWS from specialist care in example 3). Furthermore, demanding challenges that they face relate to understanding existing routines and foreseeing possible new ways of reconfiguring and organising work to improve continuity of care, including distributing future tasks and assigning responsibilities to their colleagues.

6 Conclusion

This study was motivated by the need to enhance our understanding of the generative role of objects in design work. The backdrop for our interest was the recognition of the challenges and complexities related to designing for collaborative work in healthcare, when interdependencies between multiple practices, contexts, professional groups and interests need to be accounted for in design work. We argued that by studying more fine-grained processes and messier sides of collaborative design work, a better understanding of how such interdependencies are framed and negotiated can emerge.

By focusing on object construction in the design of a patient information system, we showed how intermediary objects formed focal points from which design problems related to information sharing between care units were framed and collectively explored. The process of framing and instantiating intermediary objects are not straight-forward but require considerable negotiation and exploration within and between interdependencies that become relevant in design process. By connecting and disconnecting interdependencies, intermediary objects instantiated in a variety of modalities (e.g., as visual representations in the interface, narratives, written work routines and storytelling) are drivers that embody and reveal shifting aspects of the wider infrastructural interdependencies through their generative capacities to ‘branch out’ and ‘unfold’.

The approach we propose is increasingly important in a time period when design projects typically grow in complexity, and include multiple disciplines/expert considerations, purposes and ambitions. The technology under development in our empirical case is one example of a complex technological project, as it is supposed to coordinate tasks across a range of different contexts to support care pathways, sparking multiple questions across units, contexts, practices and professional groups. Our insights are important for understanding design as evolving processes through the way objects continously branch out and unfold. These insights also have implications for how to support design processes with shifting configurations of participants.

The explorations and inquiries that participants become involved in must be acknowledged, not primarily for arriving at solutions, but as part of generative mechanisms that is making such work evolve. Further research should explore in more detail how intermediary objects are framed, explored and work back on the design process in different contexts. Object framing is critical in this regard of exploring different relevant branches when working on materializing partial problems. We argue that more focus should be given to these constructive capacities of objects and actors in design processes, to recognise such work as going beyond a solutionism-oriented approach.

Appendix 1 Transcription legend

Italic = interface related manifestations or suggestions.

[] = added clarifying information and anonymizations.

(()) = non-verbal activity.

(.) = short pause.

(…) = parts of the transcriptions are left out.

• The oral tone of the conversations is kept in the transcripts but washed for better readability.

• The excerpts are translated from Norwegian to English.