Doing User Involvement: Shifting Interstices and Coalescing Tensions in Care Technology

Abstract

This paper explores user involvement in company practice as a method that is both contingent and transformative. Drawing on ethnographic research in a small- to medium-sized care technology company, we trace how user involvement is enacted in diverse forms to resolve, deal with, and circumvent the frictions and tensions surrounding it. While encompassing similar types of configuration work, these varying enactments differ as they selectively enroll different actants, objectives, and procedures. We refer to these peculiar enactments as occurring in shifting interstices of coalescing tensions. In so doing, we are in conversation with literature in science and technology studies studying the socio-material constitution of users and the social role of methods. We build on and extend previous arguments revolving around the effects of methods and implicit ways of designers configuring users to draw attention to the situational character of doing user involvement. In particular, we argue that investigating shifting interstices offers novel ways of analyzing and thinking about the spatialities, temporalities, frictions, and objects involved in method practices, raising awareness of what it takes to momentarily “do” method this way, and not otherwise. We conclude by discussing conceptual and practical implications for understanding and remaking methods.

Introduction

Reaching the office door, sixth floor leaving the elevator, and with freshly disinfected hands, I ring the doorbell. The company is not particularly big, it has just one elongated floor as its office, and it has just one entrance door, glass and with the company sign on the side, that only employees seem to have a key for. From the inside, a silhouette of a person approaches. The glass is too blurry to recognize who it is. A man, in his late forties and in comfortable office wear, opens the door just halfway. His face carries a confused expression, seemingly looking at me in anticipation for an explanation. Confused, I look back at him, first not knowing what to say, then quickly contextualizing my apparently unexpected appearance: “I’m here to see Marie” ¹ —The man’s face expression lifts, nodding (just once) and blowing out a noticeably reconciling: “Ahhh.”

This brief episode presents an extract from the anonymized field notes compiled by the first author, our observer, during his two-year ethnographic fieldwork at a small- to medium-sized care company (SMCare) in Sweden. The passage describes an event that took place after extensive negotiations for access to the company. Indeed, earlier access attempts stretched over six months, including attending company-organized events and the legal settlement of a nondisclosure agreement. Despite his earlier visits, our observer was still met with noticeable skepticism that singled him out as a newcomer. Explanation was needed and delivered. There were also other, very concrete, obstacles. A frosted glass door separated inside from outside the company. The doorbell was the only discernible way for outsiders to notify someone inside to open this door. The office, in turn, had to be reached through an unassuming elevator in the corner of the larger estate that brought our observer into vicinity. In practice, as experienced by our observer, all these elements jointly formed the structures that an outsider had to navigate if he were to get in touch with what happened inside the company.

This episode sets the scene for the spatio-material situatedness of the company and for how it works to designate insiders and outsiders. It allows us to introduce the background against which our study was set to investigate the practices of “user involvement.” At the heart of our study lies an understanding of user involvement as a method in relation to other entities, including temporal and spatial dimensions. Much of science and technology studies (STS) literature in the semiotic tradition of user research in the semiotic tradition in user research (Oudshoorn and Pinch 2003; Akrich and Latour 1992) has highlighted the mutually constitutive way in which technology design and usership are intertwined, and unraveled the situational and performative dimensions of design work and the contingent nature of the relationships between users and producers. With a distinct attention to the emergent and connective aspects of design work, semiotic scholars have brought to the fore how usage is situationally enacted in design practice (Akrich 1992, 1995; Fischer, Östlund, and Peine 2020; Woolgar 1991; Mackay et al. 2000), as well as the circumstantial effects of such enactments (Oudshoorn, Rommes, and Stienstra 2004; Langstrup 2011; Aceros, Pols, and Domènech 2015). In this paper, we extend this notion of user and technology as co-constituted and situationally enacted to one specific aspect of constitution work: the method of user involvement itself. Taking SMCare as our explorative case, we ask: how does user involvement look like inside a small- to medium-sized company in a context of more or less solid boundaries separating producers from users?

While previous STS work has criticized the implied capacities of user involvement to capture user needs that is prevalent in much product development and design literature (Stewart and Williams 2005; Hyysalo 2009; Pollock, Williams, and D’Adderio 2007), our account is concerned with understanding user involvement as method in practice. What is user involvement in company practice? How is it done? And how is it that it can be done? Such an understanding allows us to see the actors and materials involved when a method is implemented in practice and empirically analyzes what is necessary to make a method such as user involvement happen in practice. We argue that these insights enable new ways of thinking about the situational character of the implementation of methods and problematize previous assumptions about user involvement as a stable method with determinate heuristics to be implemented by practitioners.

In particular, we bring our empirical material into dialogue with STS scholarship on the “social life of methods” (Law 2004; Law and Ruppert 2013). This has the advantage of allowing us to engage critically with the situatedness and contingencies we encountered in company practice, while at the same time keeping an eye on how involvement is enacted while it could be enacted otherwise (Law 2004). In this light, our study presents not merely an ethnography of user involvement but also an exploration of method—not of what the method performs or does but of the process of how the method is done itself.

In what follows, we relate to issues of socio-materiality, temporality, and spatiality, as we follow and trace the method user involvement through different enactment sites at SMCare. User involvement, we find, is enacted in diverse forms to resolve, deal with, and circumvent the frictions and tensions surrounding it. These varying enactments are both similar and dissimilar, as they encompass similar types of configuration work yet selectively enroll different actants, objectives, and procedures. They occur, as we may say, in shifting interstices of coalescing tensions that momentarily stabilize the frictions surrounding it. We conclude by relating our empirical material back to recent STS scholarship on methods and usership, positioning the idea of shifting interstices as a conceptual and practical contribution to understand the situational character of methods. While our account of SMCare is concerned with user involvement, we argue that there is interest in interrogating other areas where methods are employed, too.

Methods as Situationally Enacted

To investigate user involvement as a method enacted in practice, our research connects with STS research concerned with the “social life of methods” (Law 2004; Law and Ruppert 2013), a stream of literature focused on the performativity and practices of methods. In early work, comparing the analytical frameworks of semiotics and symbolic interactionism, Mol and Mesman (1996) illustrated how each framework came with its own mode of investigation and illustration and argued for an awareness of the “political styles” implicit in method. Following the politics active in the methods and devices applied inside infertility clinics, Cussins (1996) described the “ontological choreography” by which various heterogeneous elements were aligned to “show what made to appear by the different equipment and procedures” (p. 581). Her study drew attention to the performative role of methods in medical practice to create compatible realities that bounded bodies with treatment practices and instruments. Similarly, Mol’s (2002) praxiography in a Dutch hospital highlighted the ontological quality of medical practices to enact multiple versions of atherosclerosis, arguing that “[s]tudying methods empirically, then, generates another understanding of what they are. No formal guarantees, but specific mediators, interferences” (p. 155).

STS scholars have also highlighted that methods themselves are not easily definable or definite. Methods have been illustrated as fluid technologies (de Laet and Mol 2000; Mol and Law 1994), as both being and creating objects sometimes present, but also sometimes elusive (Law and Singleton 2005; Watson-Verran and Turnbull 1995). The notion of methods has since been extended from solid devices (Latour and Woolgar 1986 [1979]; de Laet and Mol 2000) to capture the role of experimental setups (Lezaun, Muniesa, and Vikkelsø 2013; Lezaun, Marres, and Tironi 2017) and ethnographic field sites themselves (Candea 2013). Pulling together the insights gathered on method in social science, Law (2004) and later Law and Ruppert (2013) proposed a research agenda engaged with methods as performative enactments that create both presence and absence of particular realities. In this view, methods came to be reconceptualized as “assemblages” (Law 2004: 41) that are themselves in flux, as they enact and solidify linkages between a real “out there” and the represented version of it “in here.” Against this background, Suchman (2012: 55) proposed to conceive of “configuration” as a form of “method assemblage” to acknowledge the enacted nature of the boundaries between producers and users. In this view, user involvement could be treated as a method assemblage involving various human and nonhuman actants and participants who enact particular types of objects and subjects.

Dealing more closely with the involvement of users in design, studies in the semiotic tradition of STS have mostly addressed the performative and effective aspects of design practices. Wilkie (2010, 2014), for instance, ethnographically interrogated the multitude of practices by which designers involve, enroll, and deploy users in user-centered design. Wilkie’s study brought to light the performativity of such involvement procedures in enacting a multiplicity of users (designated as distal and proximal users with regard to their temporal immediacy to a prototype), as well as the fluidity and contingency through which various versions of users are socio-materially conditioned in design practice. Other user studies in STS have shed light on how usership is created alongside installation processes (Sánchez-Criado et al. 2014; Pols and Willems 2011), the performances of inscribed socio-material relationships (Akrich 1992; Summerton 2004; Wilkie and Michael 2009), and implicit ways of configuring users (Woolgar 1991; Oudshoorn, Rommes, and Stienstra 2004).

Against this background, our research is interested in method itself as enacted in practice. It shares with these types of earlier work an interest in the practical methods by which designers involve users. At the same time, our research departs from previous STS by shifting the analytical interest away from the effects of methods, such as how multiple users are assembled in practice, toward the socio-material conditions and relational enactments of methods per se. In other words, our study seeks to unravel how certain ways of doing involvement are enabled and not others. We argue that this aspect of constitution work has largely gone unnoticed. Indeed, while much STS research has investigated the performativity and instrumentality of methods (cf. Chilvers and Kearnes 2020; Moreira 2006; López Gómez and Criado 2021), less is known about how methods are done in practice. Despite notable exceptions (e.g., de Laet and Mol 2000; Mol and Law 1994), STS of method enactments have tended to focus on the world-making effects of method (Barad 2007; Law 2004) so that the practices cultivating a method have remained largely unattended to.

Our ethnography of user involvement is positioned to engage with this discussion, by accounting for the temporalities, spatialities, and contingencies active in the making of “user involvement.” In the following sections, we outline how user involvement itself emerges as a method, what user involvement is in company practice, and how it is achieved in the context of SMCare—but we first address the performances of our own method.

Our Own Method(ology)

The empirical material we present is from fieldwork undertaken as part of a project about design methodologies of digital technologies for older people. The first author conducted fieldwork at SMCare, a small- to medium-sized company in Sweden that develops different types of digital care technologies. At that time, the company employed about twenty people as main staff, with an additional and fluctuating number of external consultants employed for various complementary tasks such as software engineering. Within Sweden, the company was a fairly major player for the provision of products and services to the care sector. Its main concern was developing software for the care sector, such as smart care systems involving alarm systems, sensor monitoring, and video meetings. Following a series of corporate acquisitions, SMCare also inherited an array of care technologies such as devices for issuing alarms, assistive eating devices, and mobile care robots.

SMCare’s main competitors were other small- to medium-sized corporations active in the national care sector. What was peculiar to this sector is a layered procurement process, in which municipalities constituted the main (paying) clients of SMCare; care professionals were the primary adopters working at municipal facilities and utilizing the procured services; and care recipients the intended end beneficiaries. SMCare’s main objective here was to compete for care-related tenders issued by municipalities in the national context, by most suitably qualifying for such tenders. What constituted as “qualifying” was ultimately at the discretion of the municipality issuing the individual tender. Interestingly, the company formulated the consideration of user needs as one of its core values by including it on posters and wallpapers inside the offices.

The ethnographic fieldwork took place between October 2019 and June 2021 and consisted of regular physical and virtual visits. Virtual visits were not originally planned, but became necessary due to the COVID-19 pandemic. Our ethnography hence represents a repurposed, multisited strategic ethnography (Pollock and Williams 2010) occurring both in social and digital space (Pink 2013), with the aim of tracing different enactments of user involvement within the company. On all occasions, our observer kept onsite field notes in a jotted style and developed them after the end of each visit into lengthier descriptions of the observed events. During the fieldwork, we engaged in ongoing reflection on the analytical meaning of the experienced events, simultaneously engaging with continued fieldwork and corresponding literature.

Ongoing Tensions: Solutions and Risks

As presented in the introduction, our observer encountered the deliberate and solid way in which boundaries were present for outsiders, symbolized by the very structures our observer encountered: the locked glass door makes apparent the spatial and material distance between users and producers in the company. As we shall see, this distance to users mattered inside the company. In our observations of the developers and company staff, there appeared to have been a general sense of uncertainty about users, by virtue of their perceived and recognizable absence. Such uncertainty was, in turn, what apparently motivated a desire for having closer contact with users:

Jeremiel goes on the explain that he plans the meeting with the sales and communications team members for next week, and that he is also thinking of involving Andrew. Andrew, he explains, would be relevant to include: “He knows the definitions of how to engage with the customers…how we should communicate.”

Marie: “I find it really important to ask the users early what to use and why…because else we end up with something they say they don’t need….”

Returning to the topic of usability, Marie mentions she would really love to “go there and test it there”—with there, she means the care homes and places where the platform will be put to use. “Lily recommended a TV show…called ‘four-years-old at the old age home’…which is really good, she says, for us to watch…so we know how it looks inside the care homes…so that we know how it looks like for our elderly users.”

As these brief snippets from our observer’s field notes show, customers were barely understood from within the company. Some form of definition was needed to achieve communication. The spatial distance highlighted above seemingly elicited a normative importance, or social expectation, of having some type of user engagement. User involvement, in this understanding, became positioned as a potential solution to learn about user needs, with its promise to clarify and fill possible knowledge gaps. But as we observed in the company, these were not its only promises. User involvement featured also in enactments designed to improve productivity and the quality of software development, as the following episode from a presentation at a company team event illustrates:

Curious, I slowly walk behind the others into the meeting room, which is now densely filled with fourteen people…. “Who of you knows about Agile…agile software development,…or has worked with it before?” Nicholas asks into the round. Everyone in the room shakes their heads. “Good!” He says excitedly, “So I begin with the basics…if we want…if we are serious about the transformation from a pure hardware company to a software company…a software services company…I believe…we should move to become agile.” He switches the picture on his computer, which is displayed at a large curved TV mounted to the wall. The picture shows two different lines, one consisting in large triangles, and one in smaller ones. “In the normal waterfall model, you develop and bring the product to the market over a long time…two years.” He points at the large triangles. “In contrast, with agile software development, we work in small iterations…which we immediately employ…and we get fast feedback from the customer…about how it is used.” He points at the shorter triangles and continues to elaborate for a while. He concludes the slide with: “We need to be innovative…we need to respond to what the customers really need…from competitor-driven to customer-driven…It is a culture…a mindset!” he emphasizes. The others in the room nod, seemingly agreeing.

In the team event, the presentation was made by a representative from the development team to convince other team members of this apparently new approach. Our account makes visible how, in these practices, the method of user involvement was enacted in a positive fashion. Most notably, user involvement became integral to the desired move toward a more “agile” approach to software development. In this newly aspired development approach, in contrast to the “normal” development approach, interaction with the customer was sought more frequently and much earlier. User involvement, in turn, became enacted as an innovative approach, a way to speed up productivity, all in line with what the customer desired. It became part of a new company culture or mindset.

While these practices elicited positive enactments of user involvement, other practices in the company seemed to have featured contradictory versions of the method. In these versions, user involvement was practiced as a risk, a potential embarrassment of the company’s reputation. This is epitomized by the following passage taken from a discussion between development, and sales and customer support staff.

Colette: “So…overall…. Do you think we should show the customers?”

Aubrey: “I don’t think it is ready just yet…for example, the user friendliness….”

Nathan: “…And we do not know what is the priority for the customers….”

Marie: “I think we should clear first so we have a bit higher level which we can show the customers….”

Aubrey: “Precisely…we want a good experience for the customers.”

Lily: “It is not yet ready for the customers but do not give up…”

Colette hence moves on to add in the recommendations: “It could negatively influence our customer brand if we do not give a well-worked impression.”

In this consultative practice, customer relations and development staff jointly came to the agreement that the technology was not yet to be shown to customers. User involvement, rather than being a value or promise, was done away as an endeavor too risky to pursue, potentially damaging the “customer brand.” In addition, this contrastive version of user involvement became embodied into an action-point on a computer document, made obdurate and present to act in future practices (Latour 1987). And indeed, in many other company practices that we observed, we found resemblances of this enactment of user involvement as a risk.

At one point, Andrew adds: “But you should never ask the customers what they want…because…they will never pay for what they want…they will say I want a carpark…and a summerhouse…and a whole set of other things…but I only want to pay for the carpark.” Marie intervenes: “I think it’s always good to ask the user…”

Andrew: “Don’t understand me wrong. What the customers say…their feedback is very valuable…but asking an individual in the beginning…unless they pay for it…If you ask [Bianca], you would make one car for [Bianca]…but we do not only want to make the car for one [Bianca], but for many [Biancas] and many others…”

In many company practices, user involvement encountered skepticism about the validity and meaningfulness of user statements. So, the versions of user involvement we observed in some company practices seemed to stand in stark contradiction to the versions of user involvement we observed in others. In some enactments, early user involvement was a virtue, and in others, it was an irrationality. Sometimes a promising solution, and sometimes a risk too high to take.

Shifting Interstices of Coalescing Tensions: The Case of Functionality Tests

How did these seemingly opposing versions, of solutions and of risks, come to coexist? In the literature, the downsides to user involvement, as much as the benefits, have been extensively discussed, both in management contexts (Kujala 2003) and in STS research (Oudshoorn, Rommes, and Stienstra 2004). Beyond recognizing these tensions, our findings illustrate empirically how, in company reality, these tensions are actively dealt with in practice. As Mol (2002) highlighted, things do not exist independently of one another; they hang together, they are partially connected (Haraway 1991; Strathern 2005 [1991]). ² Similarly, in our observations, different versions of user involvement did not remain apart from one another. Rather, in company practice, they were brought into alignment. One example we encountered quite frequently is the case of functionality tests. These tests had the very straightforward purpose of enrolling test users to do work on the technical aspects of the care platform:

Jeremiel then resumes his presentation. Having just joined, I have difficulty following. I cannot help but throw my question into the round: “What is a staging environment?” Nicholas does me the favor and elaborates that it is an environment they need for the functionality test. …Marie joins in and elaborates that it is on their platform, their system, and that it is meant for some people they recruited to test the functionality virtually: “…and it’s iterative, so if we find…bugs then we can…make a new staging environment…and do the test with the students again.” Students? I ask what their background is, and Marie replies: “One…she has just a high school background…and there is another one who is studying…but I will give them a list of bugs to go through and check.”

Students—not care professionals or potential care users—were enrolled in the task of working on the bugs and improving the functionality. Instantaneously, the frictions outlined before appear to be balanced out: involving students as test users nicely circumvented the risk of having to involve people that may come from the group of possibly judgmental clients. And it maintained the benefits of involving test users to improve the quality of the technology. We may thus say that, in company practice, risks and promises of user involvement—two seemingly competing versions of user involvement—coalesced into new versions. In this new version, user involvement became an adventure that was doable once it could be controlled. The staging environment mentioned above played an active role in this:

with the staging environment…we can find the bugs…and the testers don’t mess with the core…that Charles and the other developers are working on,” Jeremiel elaborates.

The staging environment functioned as a virtual control device: it helped to apprehend the potential risks of irrational test users “messing” with the technology, by allowing for a special environment for test users next to, and separately from, the “core” environment. The solution offered by involving users (improving technology and finding bugs) coalesced with the risk of users potentially behaving irrationally in the staging environment. Hence, we may say, in company practice, the staging environment formed an interstice in which particular enactments of user involvement were possible; an interstice where its tensions temporarily came together. We choose the term “interstice” because it alludes to how coalescing tensions produce particular scenarios of user involvement—and also to the socio-material and temporal facets that instantiate such intermediate spaces. As we argue in these pages, our empirical material illustrates how particular versions of user involvement emerge only momentarily in specific spaces occasioned by the contingencies of specific socio-material assemblies.

In our ethnographic account, there are two interesting observations with regard to interstices. First, staging environments were not stable—they evolved. As developers continued their work, they made new staging environments. And second, the staging environment was by far not the only interstice of coalescing tensions in which user involvement occurred. For example, other interstices were provided by test cases and user stories. In software engineering, test cases are created and executed to determine specific sets of actions and to check if particular system features function as desired; user stories are designed to describe the expected experiences of these system features from the point of view of an envisioned end user:

“You will work in a test plan which is called regression…” Marie says, and I can hear her click and I can see her screen shared: a webpage, which neatly provides an overview of a list of different test cases with different headlines. “Do you see it?” Marie asks into the round. Her mouse is circling around one test plan—that with the name regression. Some testers reply that they do. She then clicks on it and a new screen window pops up showing an abundance of different test cases. “Almost all test cases end up here,” she explains. “When one has tested through regression…that means that all is green, that all is tested and works. I have worked since May (six months ago) to write test cases…which are connected to user stories.”

Both test cases and user stories were written by designers to articulate, and prescribe, the different procedures to be conducted by the testers. Particular frames of action and test behavior scenarios were “inscribed” (Akrich 1992) into test cases and user stories. In this way, the promises of user involvement were actively worked toward, to achieve contributions by users that were perceived as meaningful to the overall technology development endeavor by the designers. And the risks of users misbehaving were controlled through clear instructions and guidelines; undesired contributions by users, comments other than those relating to functionality, implicitly filtered out. Tensions between risks and benefits of user involvement coalesced in the user stories and test cases implemented in the regression plan. And because test cases and user stories differed from one to another, each test case configured the test procedure, hence providing a different interstice of coalescing benefits and risks—leading, in practice, to a different involvement of testers:

Marie opens one test plan, which is called: “If the status is properly changed when it is clicked.” As she clicks on it, several sub-steps appear numbered from 1, 2 to 6. Step by step, Marie goes through the substeps, calm and without much distraction. I read that the first step asks the tester to “log in to the mobile and check the presence sign (green circle that is filled).” Marie reports how she is doing just that. Underneath, I read: “expected result: status of the user when login is available (icon is green).” Marie explains how the expected result did happen, and that now she has to tick a tiny button to the right of the expected result, to indicate that the expected result did indeed happen….

“And then we also have the progress report…” she navigates to the left side of the page, clicking at a different category. A new page opens showing a graph. I can see mostly a gray large square, with a bit of red and green colored areas on the top. Marie explains to tester Daniel: “Gray is untested…green passed and red failed…we have a lot to go through.” Indeed, I think to myself, as underneath it stands: 516 test points.

The section above shows how one developer described one test case to the testers, a particular procedure for testers to go through, organized with several substeps and possible reporting mechanisms in case the test failed. The steps described in detail here were very particular to the case of testing a status change of the user. Other test cases naturally outlined different procedures. The second snippet further emphasizes this, showing that the testers were tied to a progress report containing more than 500 such detailed test cases and user stories. While similar in their prescriptive nature, the test cases also distinguished among each other as can be seen from another test example below.

“Was there something here?” Marie opens one subcategory called “test the delete option.” “That was mine…there are not so many steps described here…about what to do,…and no expected results.” Marie and the tester discuss which steps he’d desire to be described in more detail, and Marie herself edits the steps of the test scenario, adding additional ones before and after. Step by step, she follows the instructions, switching back and forth between test case organizing webpage and application platform, seemingly looking for similarities, matching, contrasting and cross-checking until she decides to add or rectify a step in the test case.

This section illustrates that the individual test cases were—like the staging environment—not stable, but changing. Throughout the process of “regression testing,” new test cases were added, and old ones were modified. The regression plan was permanently worked on; skipped, refined, and adjusted when needed. Hence, we may say, the interstices of coalescing tensions we witnessed were shifting. And the enactments of user involvement varied along with them. This can be seen at the example above, where the test cases were altered. Along with them changed the prescribed and conducted actions by the test users involved.

The functionality tests seemed to include plenty of such interstices where its tensions could be momentarily stabilized, brought together. For example, in the last passage, we can discern at least two interstices: the test case and the feedback-and-supervision procedure itself. In this feedback procedure, the tester participated in providing feedback about the apparent incompleteness of one test case description. In so doing, he remained within the confines of the overall supervision practice, but his experiences were processed and implemented by the developers—so as long as they fed into the prevailing paradigm of the procedure. In other words, feedback-and-supervision procedures, too, worked as interstices of coalescing risks and benefits. And they, too, were shifting:

As I join the meeting, Marie and the testers are already discussing. I can see that testers Michael, Martin, and Bobbie have joined the meeting. Everybody’s video is switched off, and the main window is filled with Marie sharing her screen, displaying the webpage organizing test cases…. One tester remarks that it could be tested to add users, and to try calls. “Very good,” Marie says and adds descriptions to the suggested test steps. “I think you can also put to decrease and increase the meeting window…” Marie again praises the suggestion, adding it. This goes back and forth for a bit, until after another suggestion, Marie remarks: “I think we don’t have to put all unusual alterations, just the common ones…” The testers agree in silence.

Here several testers jointly worked to provide feedback to add new test cases. And we see that only some comments by the testers were included as valuable improvements by the developer, while others were dismissed as unnecessary. This feedback procedure was apparently similar to the previous one, serving to ensure continued control over the test user’s behavior, implicitly addressing the risk of irrational actions while enabling the developers to elicit the type of feedback considered useful. But it was also slightly different, because different testers were involved, new test cases were established, and the developer reacted differently to different types of comments. In other words, just as test cases, staging environments, and user stories, feedback-and-supervision procedures, as well, formed interstices that were shifting.

Every individual involvement session seemed to depend on the creation of one or more shifting interstices that combined benefits with risk to make user involvement temporarily feasible in practice. Next to feedback-and-supervision procedures, another example are practices of guidance and instruction:

Mare moves her mouse to a different webpage, now showing a table titled “possible bugs.” Starting with the first column, Jeremiel says to the students: “If you number bugs…it’s also important that…. If you see several things going wrong, don’t report them as one! Separate them even if they occur in one single test case…. The reason is that after that, if we solve something or test again, and we see A and B work now and C still occurs…then how do we call that? Is the bug now solved? Try to think of that!” The two students nod and Marie writes a note on the whiteboard to remember Jeremiel’s comment: “separate bugs.” Having finished her note, she returns to her seat, turning to the two young testers: “It’s tricky to make a good bug. If we do not make the bug we never get the system working.”

In these practices, developers actively instructed the testers about the desired actions, foregrounding the centrality of finding and making a “good” bug. Again, this instruction apparently served to circumvent the risk of potentially receiving “bad” bugs from the testers—that is, to preempt possible undesired actions by the test users. At the same time, it seemed to tailor user involvement such that it was likely for the developers to obtain the results that they desired. Instruction sessions, akin to feedback-and-supervision sessions, formed interstices of coalescing tensions to render user involvement feasible in practice given its coexisting frictions. And they were also shifting because different instructions were made in different instruction sessions, different instructors participated, and different testers were instructed:

“…and this here deals with video I believe…? Can you describe…?” Marie clicks on one sub-category name, opening another pop-up window. A tester, Michael, responds: “What happened was that…on the tablet…when I switched off the camera and then on again…there was an extra video…as if it was an additional participant…then I noticed it’s the same bug as [tester Daniel]’s bug.”

“Great…which number?”

“12096”…

“Superb…I will then be looking at this.…Ok, so can you [tester Bobbie] write a bug here, and you [tester Martin] write one here?”

So, in practice, user involvement was enacted in varying forms, at shifting interstices of coalescing tensions between its benefits and risks. We refer to these varying enactments of user involvement as occurring in shifting interstices because they were fragile, temporary, and only partially connected. A landing spot constantly transforming. Every enactment of user involvement we encountered in the company was different and similar at the same time, made possible only through the momentary stabilization of risks and benefits. They were different, as interstices were shifting. And they were similar, as they were at the center of coalescing risks and benefits. The concept of interstices sensitizes us to the contingencies of specific scenarios, specifically in relation to the type of socio-material arrangements that have to form for any version of user involvement to occur.

Staging environments, user stories, test cases, instructions, guidelines, structured feedback, and continued supervision; in Woolgar’s (1991) sense, our different interstices could be considered part of objects configuring the test users. They could be seen as additional texts for the users to read, to achieve a “correct” interpretation of the technology, with the ironic consequence that assumptions embedded in the technology remain unquestioned by the test users. Our findings support this view. Only that our account makes visible how these varying interstices emerged as a compromise, a coalescing of coexisting tensions of the method itself. They were part of broader practices than configuring the user—they were necessary to bring together, and momentarily resolve, the ongoing conflict between benefits and risks occurring in the hinterland of user involvement.

Shifting Interstices of Coalescing Tensions: The Case of Sales Representatives

Implicit in this discussion of functionality tests is the enrollment of user representatives. Enrolling students as test users itself formed an interstice in which varying procedures of user involvement could occur despite the coexisting tensions surrounding it. In different enactments, these interstices prevented direct customer contact while achieving improvements of technical functionality. But enrolling students was not the only resource for the interstices that we observed. Another example is the case of sales representatives, employees of the company.

Three of us are here physically. Colette quickly connects her laptop with a TV screen mounted at the wall facing us in the elongated meeting room. I can see three moving faces on the screen; Lily, Aubrey, Nathan, who are part of the company customer relations and demonstration team. Colette seems to chair the meeting, beginning to elaborate: “This meeting is informal…it is to get your opinion and how you feel using the app…as much development has been done without customer contacts

These notes describe the beginning of a session where internal user representatives were enrolled from the sales and customer support departments to evaluate the overall impression more from a “customer perspective.” The inclusion of mediators or customer experts has been highlighted previously in the literature as powerful “implicit user representation techniques” (Akrich 1995). Our ethnographic account makes it clear that this procedure, too, formed interstices between ongoing tensions surrounding user involvement. In the enrollment of internal sales staff, we see the risks and benefits of user involvement coalescing again: at the session described above, internal customer relations staff were positioned as closer to the customers than software development staff. Their involvement was enacted as a partial solution to bridge the spatial and material distance between users and producers to tailor the product more to the putative users’ needs. At the same time, their involvement was also enacted to circumvent the risk of involving customers directly, so involving only internal staff continued to prevent potential damages to the company’s reputation.

Lily: “I felt it was not entirely intuitive…”

Nathan replies: “it’s a bit unclear what one should fill in…I needed help for adding the personal security number for the staff…sometimes you cannot add the number.”

Aubrey adds: “like this you are forced to create an account without personal number.”

Colette again moves to the part in her own web version of the platform. “Mh” she says and tries to add the personal security number. … “So…we can say…it works…but just closely [sic],” Colette concludes and moves to the document with the bullet points, selecting that it works.

Marie hesitates for a moment: “Can we add a column for that it worked only closely?”

Colette laughs and agrees, and adds another column in the document, now allowing for the possibility that there are things that work but could require improvement.

We discuss if the design is simple and intuitive, for which Aubrey and Lily jointly reply: “It’s okay.”

“But it’s not client ready,” Lily quickly adds, “the design is not intuitive enough yet.” Colette and Marie nod.

In practice, staff from the customer relations department functioned as user representatives, precisely because their enrollment offered an apparently suitable balance between conflicting risks and solutions. As can be seen from these episodes of an involvement procedure, the sales staff projected themselves into use, acting as legitimate representatives to speak on behalf of the customers. Their statements on whether the usage felt intuitive were apparently taken seriously in these sessions and translated into action points for the development team. In addition, they were enacted as sufficiently close to the customers, and their assessments of user friendliness were taken at face value.

The comparison between the case of functionality tests and the case of sales representatives makes tangible how user involvement was enacted in varying interstices that were dynamic and shifting: enrolling both students and company staff as proxies for users occurred throughout the period of our observations. We observed how developers constantly switched between different procedures involving sales representatives and test users. But each of them was enacted in its own distinct fashion, resolving the tensions surrounding user involvement slightly differently. Sales representatives offered a different interstice than student test users and stabilized the tensions surrounding user involvement in their own distinctive ways. Test users were enrolled as distant from customers, but close enough to the technology to test its features. Sales representatives were enrolled as remote from technology, but closer to customers.

Despite these differences, their enrollment procedures also seemed to enact similarities and indeed similar types of interstices. As with functionality tests, sales representatives were enrolled through structured supervision-and-feedback sessions. And as with functionality tests, sessions with sales staff can be seen as interstices of coalescing tensions: serving to maintain control of potentially adverse actions by the enrolled sales representatives, while also seeking to elicit knowledge about customer perspectives.

Jeremiel shares with us that he re-structured and assessed the feedback from Nathan and Lily, from sales and customer support, and that he also asked Nicholas and Andrew, from development and management. “…because…what they feel is important,” explains Jeremiel. Sharing his screen, which shows a table with plenty of rows, Jeremiel further elaborates that he has ranked the different types of feedback according to three levels “to understand, based on the list, what is most important from Nathan and Lily’s perspectives…. Since they also represent a user.” Jeremiel also highlights he will send his list of priorities to Colette, adding: “Much of what Nathan and Lily have highlighted they would probably not have done if they had a user manual. Many comments we can fix, but many others we need to include into the user manual.”

By structuring and organizing the feedback from the sales representatives in this way, the developers actively worked toward ensuring that the decision of what to implement remained at their discretion. In this way, feedback could be reordered, prioritized, or dismissed into “user manuals.” Ranking feedback in this way implicitly positioned some comments as inferior to others, while hiding the underlying logic of this very ranking. In other words, the structured feedback session appeared to function as an additional interstice of coalescing tensions between risks and benefits of user involvement: The benefit of implementing something new about customer experience from sales representatives was effectively weighed in with the risk of arbitrariness, the risk that not all that sales representatives have to say was relevant. These structured feedback evaluation sessions ultimately helped to subjugate the inputs by sales representatives to the overall interest of developers, as the following passage illustrates:

We talk about what the main issues are that surfaced, based on his assessment of the feedback. To one of my questions about the main points he took from consulting the sales and support personnel, Jeremiel replies, scrolling through his table, that there were different tasks, and lists, for example some required fields were not indicated. He soon switches away from the table with tasks, to display another webpage, which reads “test cases.” He elaborates: “We created a user story…. There also was a bug…[Marie,] can you take a look…because I just want to bring up the bug. Because I was not sure…the bug you reported….”

As Jeremiel opens the platform, Marie replies: “Yeah please do…I tried to create a consumer without an identity number.”

As this snippet shows, the priorities in the feedback from sales representatives quickly gave way to the development team’s priority: to resolve bugs. In this practice, any potentially other forms of feedback assessments were rendered irrelevant. The interstice of coalescing benefits and risks filtered out whatever was considered momentarily superfluous to the development team. This type of mechanism appears very similar to the one we encountered in the case of functionality tests, just that with test users, comments were assessed verbally, while with sales representatives, they were ranked and evaluated both verbally, and on documents. Hence, the feedback procedures we observed were constantly shifting, transforming, not just inside cases, also between cases. In every enactment, they were dissimilar, yet similar.

Whether in functionality tests or while consulting sales representatives, interstices such as structured feedback evaluation sessions, enrolling sales representatives, test users, user stories, and so forth helped to coalesce risks of potentially undesired contributions with the benefits of those deemed useful. While working to balance out such frictions, these interstices were not stable, but shifting: different from enactment to enactment, and resembling elements of one another at the same time. And it was only in these shifting interstices that user involvement was practiced, rendered feasible. For without the momentary stabilization of the persistent tensions surrounding the method of user involvement, between conflicting risks and benefits, how could practices of user involvement have been possible at all?

User Involvement in Practice

Previous STS accounts of usership have highlighted the emergent ways in which users are enacted in practice (Sánchez-Criado et al. 2014; Pols and Willems 2011). They have also thrown into sharp relief the configurational work implicit in many design practices (Oudshoorn, Rommes, and Stienstra 2004; Woolgar 1991; Mackay et al. 2000). Our notion of shifting interstices pulls these previous conceptions together to allow for an understanding of the situational nature of user involvement. It combines the notion of a palpable core—that is, elements of configuration work, practices of scripting, and power imbalances—with the one of transformative relationality, including fleeting tensions, transient risks, ephemeral settings, or perishable objects. Interstices are spaces that open up in-between some “things.” By acknowledging that each enactment of user involvement requires such a space, we can systematically and reflexively identify the things around it. And further, by acknowledging that such spaces are never stable but shifting, we can identify the elements that allow for user involvement to occur, while tracing them as they shift, disassemble, and reassemble in various enactments. For enactments differ from sites to sites, they still resemble elements of what can be considered to be “user involvement,” hence being partially connected (Strathern 2005 [1991]; Haraway 1991).

Barad’s (2007, 2003) onto-epistemological account of the relationality of phenomena is relevant in the context of our empirical account of user involvement. Barad (2007) argued that a phenomenon is inseparable from the method designed to understand that very phenomenon. In this conceptualization, objects do not have any a priori defined agentic capacities and properties; they only obtain them in practice for a moment. This temporary closure of ontological uncertainty has been termed by Barad (2007) an “agential cut” (p. 175), recognizing that different cuts may enact very different phenomena over time and space.

Akin to Barad’s notion of agentic cuts, our account of shifting interstices draws attention to the contingent, momentary yet transitionary nature by which a method can be done in practice. We may, too, see in our account the emergent and effective properties of various enactment practices that draw the boundaries of different actants and people involved, as highlighted by Barad’s notion of “intra-actions.” We would like to argue, though, that conceiving of “shifting interstices” for method practices also offers a contribution to previous conceptualizations of method in practice, which have interrogated how methods interfere and “make” social realities (e.g., Lezaun, Marres, and Tironi 2017; Law and Ruppert 2013; Barad 2007). In particular, the concept allows us to draw attention to the link between the temporality and socio-materiality of different ways of doing method. In other words, aside from studying the social effects of method, investigating shifting interstices may offer a starting point to become attuned to the particularities and intricacies by which methods create realities in any given moment (Law 2004). In this vein, the concept of shifting interstices highlights the ever-shifting socio-material conditions that are active and required for different method enactments, thereby raising awareness of what it took to make things this way, and not otherwise.

Next to this theoretical contribution, there is also a rather practical motivation for such a shift in theorizing methods: understanding the situational arrangements that allow for a particular way of doing a method such as user involvement may be important to know how to intervene. Like STS scholarship that has gradually exposed the implicit and sometimes undesired performances of methods (Cussins 1996; Lezaun, Muniesa, and Vikkelsø 2013; Law and Ruppert 2013; López Gómez and Criado 2021), we, too, see a growing interest in reconfiguring (Barad 2007) or remaking (Chilvers and Kearnes 2020) existing method practices. This, we argue, can most appropriately be done if we understand the shifting interstices that make a particular method feasible in the first place. For our case, both user involvement and participation have enjoyed continuous advocacy, frequently with a focus on offering specific heuristics that suggest a rather linear relationship between input, method, and outcomes (e.g., Simonsen and Robertson 2013; Kujala 2003; Hartwick and Barki 1994). Often, studies aim to map barriers and outcomes or seek to offer procedural guidance on the implementation steps to follow in order to achieve certain outcomes (e.g., Spinuzzi 2005; Bano and Zowghi 2015). In such a representation, user involvement is imagined as a process external to the people, practices and materials present in a design or company setting.

Reflecting on our account of user involvement, it seems difficult to extract straightforward definitions of inputs, practices, and outputs. Rather, our account appears to illustrate user involvement as a fluid method (Mol and Law 1994; de Laet and Mol 2000), a participatory assemblage (Suchman 2012; Law 2004) that is co-constituted by intricate socio-material arrangements. In turn, this crucially suggests that offering ever more intricate implementation advice on design or involvement procedures without thoroughly considering these arrangements may not be sufficient to achieve satisfactory outcomes. In other words, our account highlights that the socio-material arrangements of method settings warrant further attention—rather than improvement of inputs or procedures. In this context, tracing shifting interstices may offer novel ways of analyzing and thinking about current method practices. It will allow us to think about the fleeting materials, tensions, and frictions that continuously make up spaces of possibility where methods can and need to happen. These spaces of possibility form the locales where interventions, ultimately, could be made.

So, what is user involvement in company practice? Contrary to our expectations, our results indicate that different material alignments with underlying competing tensions prevented more direct forms of user-oriented design. Looking at practices empirically, we perceive it as a varying method, differently enacted from moment to moment. That it is possible at all to “do” user involvement depends on active practical work—by the software, tablets, laptops, staff, office rooms, narratives, imaginaries, and people involved—as well as by the nature of the relationships between them, both internally and externally. And with these elements differently aligned from setting to setting, from time to time, the method “user involvement” takes different shapes in different instantiations. All of these instantiations remain discernible as user involvement, because the actants involved are coordinated in similar arrangements of specific spaces that open up for its enactment. This is what the idea of “shifting interstices” may capture: that any enactment of a method is dependent on a range of factors, and, because the relationships among them is dynamic, so, too, is user involvement as a method always vulnerable and transitory. If we accept this observation as a premise, new questions arise: what would ethical user involvement entail? What is a reasonable way to involve people, and for what purpose? Is it “good” at all to do so in the care sector? But these are different questions.