How Do Users Perceive a Design-in-Use Approach to Implementation? A Healthcare Case

. The implementation of information systems in organizational settings is a protracted process that includes the mutual adaptation of system and organization to each other after the system has gone live. We investigate a design-in-use approach to this implementation process. Rather than a centrally run implementation process with preset goals, the management in the studied hospital tasked the individual departments with exploring and embracing the possibilities afforded by a network of interconnected electronic whiteboards. The responsibility for driving this process was assigned to local super users in the departments. On the basis of interviews with 17 clinicians we find that (a) they perceive the design-in-use approach in conflicting ways, (b) the super users are more positive about the approach than the end-users, (c) standardization across departments conflicts with design in use within departments, (d) intradepartmental change is perceived more positively, (e) the design-in-use process is inextricably sociotechnical, and (f) the clinicians’ perception of design in use is more about implementing change than about preparing it or about training and support. The conflicting perceptions of the design-in-use approach, for example, include whether it gained momentum, met local needs, and made for an engaging process. We discuss the implications of our findings for a design-in-use approach to implementation.


Introduction
The implementation of a new information system in an organization temporarily disturbs work and normally leads to a productivity dip in the period following go-live [26,35].While a quick return to baseline productivity suggests a well-executed implementation process, it also incurs the risk that work practices with the new system congeal too quickly.If so, the organization will not reap the full benefit of the new system [44].To reap the full benefit it is necessary for the organization to experiment with the possibilities afforded by the system and to seize the opportunities that emerge from this experimentation [38].Such a process requires that the users are prepared to prolong the period in which work practices are fluid in order to spend time exploring what new ways of working the system affords.the users are prepared to engage in a design-in-use process.We investigate this preparedness.
The empirical setting for our investigation is the organization-wide implementation of a network of interconnected electronic whiteboards for intra-and interdepartmental coordination at a hospital.Management in the studied hospital took a design-in-use approach to implementation.Rather than a centrally run implementation process that stipulated up front how to use the whiteboard, management tasked the individual departments with exploring and embracing the possibilities afforded by the whiteboard.This design-in-use approach to implementation signaled a commitment to reaping benefit from the whiteboard, even if it meant prolonging the implementation process.However, it also meant that successful implementation became dependent on the users' preparedness to design their use of the whiteboard rather than simply use it according to preset procedures.Specifically, the group of super users was assigned a key role as drivers of the local implementation process.We interviewed 17 clinicians about their thoughts on the implementation process.On that basis we seek to answer two research questions:  How do the users perceive the design-in-use approach to implementation?To answer this question we make a content analysis of the interviewees' statements and catalog the opportunities and barriers they mention. Do the users' perceptions vary across user groups?The answer to this supplementary question consists of comparing the distribution of the content categories for super users and end-users and for physicians and nurses.
In the following we review related work, account for our method of data collection and analysis, present the results of the study, and discuss their implications.

Related Work
Research on design in use aims to capture "practices of interpretation, appropriation, assembly, tailoring and further development of computer support in what is normally regarded as deployment or use" [9, p. 125].This definition suggests that design in use is a fairly informal and largely user-driven set of practices.However, the definition also implies a permeable boundary between design in use and the more planned and management-initiated activities of system implementation.

Design in Use
Orlikowski [28] shows that the implementation of information systems is only a partially planned process.While part of the process can, and should, be planned in advance and executed as planned, other parts emerge in unplanned ways during use and become visible only in retrospect.These emergent parts of implementation present and deny opportunities that may be pursued in additional, opportunity-based efforts to obtain benefit from a system or may call for revising plans to avoid adverse side effects [14,29].As a result, the implementation process continues over an extended period of time; it is not restricted to the first few weeks after a system has gone live.Design-in-use research embraces this continuation by contending that golive does not mark a shift from design to use [1,5,8,10,12,16,18,19,24,41,42].Rather, design continues into use in the sense that users design, as opposed to merely adopt, their ways of working with a new system.The continued design activities are informed by the users' experiences from using the system for real work and may involve configuring the system as well as adjusting work practices.
The boundary between design in use and system implementation depends largely on the extent to which design in use proceeds as an informal process among peers or has become a more formalized process with organizationally defined roles and responsibilities.Organizational structures for deciding and coordinating which changes to pursue become increasingly needed with systems that are still more configurable and thereby make it possible to pursue a still wider range of changes [8].With increasing managerial support design in use increasingly becomes an approach to systems implementation.We distinguish three broad classes of design-in-use processes with respect to managerial support.
First, multiple studies have investigated design in use as it unfolded in situations with no formal organizational support.For example, Mackay [20] studied how customizations were shared among the users of an application package.While most users made some customizations to adapt the package to their needs and desires, a small group of users spent considerable time making customizations and became adept at it.The members of this group became the go-to persons when their colleagues had questions about customization; furthermore, the group members started to share useful customizations.Although this sharing was widespread "few of the managers were aware that customization files were being exchanged and none were aware of the extent of sharing" [20, p. 219].Thus, these design-in-use activities took place without organizational support.Relatedly, Park et al. [30] analyzed how doctors started making notes on pieces of paper when an electronic medication record required them to remember information they gathered at the bedside until they later visited the charting room to enter it in the electronic record.This apparently mundane example of design in use remained organizationally unrecognized until it was realized that the notes necessitated further design in use because they contained sensitive patient information and, therefore, had to be discarded in a safe manner.
Second, design in use has been studied in settings with organizational support for the users' tailoring activities.In several of these cases design in use started as an informal activity performed by technically minded individuals for personal purposes and only gradually received organizational recognition and support [e.g., 31,39,42].While many of these design-in-use activities have produced valued extensions to base functionality, others have salvaged the base functionality by contributing "the work to make IT work" [7, p. 296].Multiple studies find that the available organizational support for design-in-use activities tends to be inadequate.For example, Dittrich et al. [9] conclude that a better infrastructure for supporting design in use is necessary to achieve the vision declared for the studied municipal website.They base this need on the uneven availability of developer support for design-in-use activities combined with the high organizational value of the templates developed by a user who had access to support.At the same time, Spencer [39] documents user frustration with the organizational practices introduced to support design in use.The source of the frustration was that the practices were bureaucratic and prioritized long-term evolution over here-and-now changes.The kind of support emphasized by these authors is technical.In contrast, Hartswood et al. [11] point to a need for support in devising, or repairing, the work processes that surround new systems.In their study the evolving use of a speech-recognition system shifted additional workload to the secretaries, who had to handle speech-recognition errors left uncorrected by the clinicians.After the secretaries raised this problem, the ward instituted a work procedure where the secretaries returned letters with uncorrected errors to the clinicians.This procedure regulated the collaborative use of the opportunities afforded by the system and rebalanced the workload.
Third, design in use may be the planned approach to implementation.In their review of the factors critical to implementation success, Nah et al. [25] emphasize issues such as exploiting the best practices offered by the system, fitting work practices to the system to minimize the need for customizations, and championing the system to manage resistance.These issues are largely directed at realizing the benefits that were planned ahead of go-live.An exclusive focus on planned change has been criticized by Orlikowski and Hofman [29], who instead emphasize the importance of identifying and embracing emergent change.As a result, design in use is central to their approach to improvisational change management.Design in use serves the double purpose of responding to local circumstances in a manner that pursues planned ends and seizes the opportunities provided by emergent change [14].To fulfill this purpose Markus [21] stresses the importance of troubleshooting and shakedown in the period immediately after go-live; Karasti et al. [16] show the need to sustain designin-use processes for years or even decades; Yetim et al. [45] propose to extend systems with an embedded tool for collecting design-in-use ideas; and Hertzum and Simonsen [15] catalog the competences needed locally to be able to configure systems and work practices for each other.

Perceptions of Design in Use
Users expect that their systems can be tailored to their needs, but to exploit the possibilities afforded by a system local practices must also be adapted to the system [3,4].Both components of this mutual adaptation of system and practices to each other are candidates for design in use but they may be perceived differently.Users tend to appreciate design in use -by embracing it themselves or valuing their colleagues' design-in-use efforts -when systems are adapted to local needs and it is voluntary whether to adopt the adaptations [20,42].When design in use is integral to the planned approach to implementation and, thereby, at least partially mandatory then the perception of design in use becomes dependent on the available support [1,34].For example, Åsand and Mørch [46] find that end-users mostly prefer to receive support from super users with local and domain knowledge, rather than from technical IT staff.Other studies identify a need for support from allies with the organizational power to ensure that local design-in-use solutions are spread and adopted in the organization [27,41].However, the main issue with respect to support is, probably, that the available support is often perceived as insufficient and, thereby, as constraining the possibilities for design in use [e.g., 8,11,24].Several studies report tensions that affect the users' perception of design in use negatively.For example, Karasti et al. [16] report that the users struggled to maintain a focus on evolving the system in accordance with their long-term needs because the developers who supported design in use had a shorter temporal perspective.Torkilsheyggi and Hertzum [41] report a tension between management's expectations to the design-in-use process and the goals pursued in the local design-in-use efforts.This tension was aggravated by simultaneous, but uncoordinated, evolution in management expectations and locally pursued goals.In contrast, other studies report from design-in-use processes that were positively perceived and led to recognized improvements in local practices.For example, the Norwegian rehabilitation hospital Sunnaas has implemented and evolved videoconferencing through a deliberate design-in-use process that has spanned two decades [1].This process has, among other things, introduced follow-up consultations in which the patients participate from their home via videoconference.In Germany, the POLITeam project improved the process of vote preparation [32].The improvement opportunity was, however, not planned ahead but realized "rather accidentally" [32, p. 207] after the system had been in use for several months and, then, led to a redesign of the workflow.At a Dutch hospital a new computerized physician order entry system succeeded because the nurses, unexpectedly, adopted the system to document nursing care [2].When it became apparent that the physicians -the originally intended users of the systemwould not adopt it, the system was revised to accommodate its new users and the workflow was revised by allowing the physicians to authorize orders by signing printouts from the system.
Mehandjiev et al. [22] investigated how end-user development (EUD) was perceived by EUD researchers, IT managers, and end-users.EUD comprises the tools and activities that seek to "enable non-software specialists to develop nontrivial software artefacts to support their work" [22, p. 371].It, thus, constitutes an approach to the technical component of design in use.In terms of advantages the participants perceived that EUD could speed up software development, make users more efficient in their main job tasks, make users' work more interesting, and increase the agility of organizations in responding to external market pressures.The perceived risks included that the users might not be motivated, that the learning curve might be too steep, and that the developed software might be low quality.With respect to quality, it has been found that errors are prevalent in EUD software [33] and that end-users are often overconfident in the correctness of their software [17].Mehandjiev et al. [22] propose that EUD software should be audited by professional developers to bolster quality, but they also recognize that auditing is somewhat at odds with EUD, which stimulates an informal process.Relatedly, Mørch and Andersen [24] present a process of mutual development, in which end-users and professional developers collaborate on making changes after go-live.Through this mutual process the development organization gets customer input for relevant changes and the end-users get more advanced changes than they would be able to develop on their own.

Method
This study was based on interviews.Prior to the interviews the study was approved by hospital management.The interviewees individually consented to take part.

Setting
The study setting was a hospital in Region Zealand, one of the five healthcare regions in Denmark.The hospital had 250 beds and about 35,000 annual admissions.We have been following the implementation and use of the network of electronic whiteboards at the hospital since the first whiteboards were introduced in the emergency department in 2009 [36].Because the whiteboard was a success in the emergency department [13] it was introduced on all departments in the hospital in December 2012.The overall purpose of the whiteboard was to support coordination in and among the departments by sharing information about the status and flow of the patients and by providing at-a-glance access to selected information from the electronic patient record.However, management adopted a design-in-use approach in the hospital-wide implementation of the whiteboard [41].That is, the individual department was tasked with exploring and embracing the specific possibilities afforded by the whiteboard in the department.To drive this process of configuring the whiteboard and the clinical work for each other, super users were appointed in each department.The whiteboard was accessible on all computers and permanently shown on large wall-mounted displays, see Fig. 1.It gave one row of information for each patient.This information might, for example, include time of arrival, name, room, responsible physician, status of laboratory tests, and a transfer checklist.Configuring the whiteboard for a department involved defining views that showed different subsets of the patients, choosing the fields of information to appear in each view, and facilitating the incorporation of the views in the clinicians' work practices.
A prominent example of an outcome of the design-in-use process was the reorganization of the communication between the general wards and the team of physiotherapists.This interdepartmental change started by the physiotherapists' decision to require that physiotherapy was ordered on the whiteboard to improve their possibilities for planning their work.Physiotherapy had previously been ordered on the phone or face to face.The general-ward nurses were, instead, to write the orders in the notes field on the whiteboard in their department; the team of physiotherapists would monitor the corresponding field on their whiteboard.To enforce the change the physiotherapists subsequently stopped attending the morning meetings at the general wards because the general-ward nurses continued to make face-to-face orders during these meetings.Gradually, the physiotherapists also began to provide their conclusions from completed physiotherapy as notes on the whiteboard because these notes were noticed immediately on the general wards, whereas notes in the electronic patient record were often not.

Interviewees
Because we were interested in the clinicians' perception of the design-in-use process we chose interviews as our method of data collection.We interviewed 17 super users, end-users, and local managers, see Table 1.All interviewees were clinicians directly involved in the day-to-day performance of the work supported by the whiteboard.Thus, all of them had experienced the implementation process first hand.The interviewees represented eight of the hospital's ten clinical departments and mostly consisted of physicians and nurses, but other professional groups were also included.

Procedure
The interviews were conducted in the fall of 2014, one and a half years after the whiteboard was introduced in all departments at the hospital.Thus, the interviewees' perceptions of the design-in-use approach to implementation were based on substantial experience.In addition, the design-in-use process was still ongoing and thereby present to mind for the interviewees.The interviewees were identified in collaboration with the system administrator for the whiteboard.He received a description of our study with a request to interview clinicians distributed across departments, staff groups, and roles in relation to the whiteboard.
After identifying the interviewees we initially contacted them by email.To give the interviewees a sense of the interview topics, the email included the guiding questions for the interview: (a) How do you, in your department, use the whiteboard, and for what?(b) How have you worked with configuring the whiteboard and incorporating it in your workflows?(c) What do you see as the biggest challenges in getting everybody in the department to use the whiteboard?(d) To what extent do you experience that the whiteboard, in its present configuration, supports intra-and interdepartmental coordination?(e) What would it take for the whiteboard to support intra-and interdepartmental coordination better?These questions covered the implementation process and the resulting use of the whiteboard from multiple angles, thereby adding nuance to the interviewees' thoughts on the design-in-use approach to implementation.The interviews lasted an average of 52 minutes.

Data Analysis
The data analysis involved four steps.First, we transcribed the 17 interviews verbatim from the audio recordings.Second, we read through the transcripts and identified all segments in which the interviewees made expressions about how they perceived the design-in-use approach to implementation.This step resulted in the identification of 433 segments.To maintain the context of the segments we marked them up in the transcripts rather than extracted them from the transcripts.Third, we coded the segments with respect to the six classifications in Table 2.For the classifications of valence, object, stage, and scope each segment was coded with one of the classification categories or with 'other' if none of the categories matched the content of the segment.For the classifications of opportunities and barriers we chose against preset categories and, instead, descriptively annotated the segments that expressed opportunities or barriers.This process produced 143 annotations about opportunities and 224 annotations about barriers.Fourth, we established categories of opportunities and barriers in a bottom-up manner by grouping annotations with similar content.The three last steps of the data analysis were completed by the first author alone.Thus, we cannot provide measures of inter-rater agreement.
We coded the valence of the segments to get a direct indication of the extent to which the interviewees were positive or negative toward the design-in-use approach to implementation.The balance between positive and negative valence is important to any assessment of how users perceive design in use.The rationale for the object classification was the sociotechnical nature of design-in-use processes.This classification distinguished between information technology and work processes, while also allowing for their combined presence.The stage classification concerned how far the design-in-use process had progressed from preparing change, through implementing it, to training and support in a change that was already in place.At the studied hospital it was new that the super users became responsible for preparing and implementing change; they had long been tasked with training and supporting their colleagues.The scope classification distinguished between intra-and interdepartmental change.We included this classification because users might have the knowledge and network necessary to make them comfortable with devising change internal to their department but lack the knowledge, network or inclination to engage in the increased complexity of interdepartmental change.Finally, we included the classifications of opportunities and barriers to catalog the features that the users perceived as positive and negative, respectively, about the design-in-use approach.

Results
In the following we first analyze the valence, object, stage, and scope classifications, then the opportunities and barriers, and finally variations across user groups.Sections 4.1 and 4.2 address the first research question, Section 4.3 the second.

Perception of the Design-in-Use Approach to Implementation
Table 3 shows the distribution of the clinicians' 433 comments across the categories of the valence, object, stage, and scope classifications.With respect to valence the clinicians made a substantial number of positive comments about the design-in-use approach to implementation as well as a substantial number of negative comments.The positive comments included: "I think it is wildly visionary to roll out [the whiteboard] across the entire hospital", "It is super fast to configure the whiteboard", and "It has changed our work processes … In all sorts of ways."In contrast, the negative comments included: "We do not need to design an IT system, we need to get an IT system", "It is cumbersome and slow to get anything done and approved", and "There were all those possibilities for tailoring it yourself and every department was allowed to do that.It ended in a mess."Overall, there were slightly more negative (48%) than positive (40%) comments, and few neutral (12%).The low number of neutral comments might, in part, reflect that several of our interview questions asked the clinicians about their views on the design-in-use process, rather than merely asked them to describe it.However, it also reflected that the clinicians had opinions about many aspects of the process and therefore mostly talked about it in non-neutral terms.With respect to the object classification it was evident that the clinicians' perception of the design-in-use process revolved around the whiteboard technology: 40% of the comments concerned the technology and another 42% the combination of technology and work processes.Only 18% of the comments were exclusively about work processes.That is, the clinicians tended to think of the changes in terms of the whiteboard because it triggered the changes or made them possible.For example, the physiotherapists' improved possibilities for planning their work was thought of in terms of the decision to use of the whiteboard for ordering physiotherapy because the improved planning possibilities was contingent on this use of the whiteboard.
Notably, the categories of the object classification contained different proportions of negative comments.While 57% of the comments about technology were negative, only 40% of the comments about the combination of technology and work processes were negative.Comments about the technology tended to concern its limitations, while comments about the combination of technology and work processes more often were about how the design-in-use process led to constructive use of the whiteboard.
The stage classification showed that the clinicians mostly perceived the design-inuse process as implementing change (53%).Implementing change was the stage at which the design-in-use process influenced the clinical work directly by requiring the clinicians to change their ways of working.That is, implementing change involved the super users, who were driving the change, as well as the end-users, who were to adopt it.In contrast, the stages of preparing change (33%) and training and support (13%) were somewhat removed from the clinical work.As much as 60% (86 of 143) of the comments about preparing change were negative.For example, one end-user stated that "We do not need more information on the whiteboard", thereby indicating that preparing change was superfluous.The proportion of negative comments was lower for implementing change (43%) and for training and support (36%).
With respect to the scope classification the design-in-use process was fairly evenly distributed across intradepartmental (39%), interdepartmental (31%), and combined (30%) change.Intradepartmental changes involved fewer clinicians with better opportunities for informally discussing design-in-use ideas because they routinely met during their shifts.Conversely, interdepartmental changes were more organizationally complex to achieve but resulted in some of the most valued changes.For example, the coordination of when patients were ready for surgery became more transparent after the ready-for-surgery checklist was moved to the whiteboard.A super user explained: There are seven things that must be satisfied: Is the patient wearing a wristband [with a barcode]?Is the patient fasting?Has a surgeon been down to see the patient?You can follow the progress.And when they have seven out of seven [checklist items ticked off] then they can be picked up.I think it works well.
By moving the checklist from paper to the whiteboard the patients' progress toward satisfying all seven checklist items was no longer just available to the general ward that filled out the checklist but also to the surgical ward that was to receive the patient.This improved the possibilities for planning at the surgical ward.The relative simplicity of intradepartmental change was reflected in a high proportion of positive comments (49%), whereas the higher complexity of the changes that involved both intra-and interdepartmental change resulted in 69% negative comments.

Opportunities and Barriers
The clinicians experienced 15 different opportunities in the design-in-use process and 16 different barriers to it, see Tables 4 and 5.A key finding from the analysis of opportunities and barriers was that the clinicians disagreed substantially.For example, 18 comments described how the design-in-use process gained momentum from early successes and external events (Opportunity 1, Table 4) but, at the same time, 20 comments stated that the design-in-use process lacked momentum (Barrier 4, Table 5).In total, 54% of the 143 opportunity comments (Opportunities 1, 2, 5, 7, 9, 11, 13, 15) were contradicted by 57% of the 224 barrier comments (Barriers 4, 11, 14, 8, 6, 1, 2, 7).That is, about half of the opportunities and barriers were contested by clinicians who held opposing views.This amount of disagreement about the pros and cons of the design-in-use process might constitute a meta-level barrier.Four of the opportunities captured what might be considered generic design-in-use qualities: (a) design-in-use approach allowed for meeting local needs, (b) gradual realization and incorporation of needs and possibilities, (c) design-in-use approach made for a proactive and engaging process, and possibly (d) gaining momentum from early successes and external events.In addition, two opportunities emphasized the important facilitating conditions that the super users championed the design-in-use process and that the process achieved a good balance between benefit and data entry.The remaining opportunities were specific to the whiteboard and the local use context, including the opportunities for better coordination, overview, and standardization.
Seizing such opportunities was central to the design-in-use process.For example, it was unanticipated that the clinicians began printing the whiteboard to have it at hand at all times and to obtain a copy for personal annotation.A nurse expressed the value of this seemingly unsophisticated change in the use of the whiteboard: "It was at that point I said: Now we are approaching something useful."In one department the accidental feature that the printout extended over two pages became a clear-cut way of assigning responsibility for the patients to the physicians on duty: We do it in the way that one [physician] takes the first page of patientsbecause the printout is on two pages -and the other physician takes the patients on the second page.That helps a lot.The most frequently mentioned barrier was that it was a misunderstanding to believe that the clinicians wanted to engage in design in use.A physician end-user explained that his interest was to treat patients, an interest he considered common to the physicians: "We have our focus on the patients.The IT systems we use are those we have to use.It is not that IT interests us."From this point of view the design-in-use process was an unwelcome distraction because it took time away from the patients.The second-most frequently mentioned barrier was specific to the whiteboard and the local context.This barrier emphasized the lack of integration between the whiteboard and other clinical systems.Thus, using the whiteboard for new purposes tended to involve duplication of work.The last of the top-three barriers was the experience that the design-in-use process had been rushed, top-down, and oriented toward administrative issues: "They want to extract some numbers, to be able to see how often we tick off this or that, whether we have ticked it off, what we use."That is, the design-in-use approach had not been presented and performed in a manner that had made this end-user feel part of the process; rather the process was perceived as driven by concerns for quality assessment rather than clinical utility.The remaining barriers included lack of momentum (which meant that too little happened or it happened too slowly), lack of time (because other activities demanded resources and attention), lack of direction (which created uncertainty about what kinds of changes to pursue), lack of knowledge (among the super users who were to drive the design-in-use process), and lack of standardization (which restricted the possibilities for interdepartmental use of the whiteboard).A further barrier with respect to standardization was that the standards that were implemented to facilitate interdepartmental whiteboard use restricted the possibilities for tailoring the whiteboard to intradepartmental needs.These restrictions were extra frustrating because the need for standardization was only realized gradually; thus, some early intradepartmental changes had to be rolled back to comply with standards that were introduced later to facilitate interdepartmental use: We end up doing everything twice.It was hugely frustrating that we had set it all up the way we wanted -we thought that now it is perfect for me -only to realize that this doesn't work [interdepartmentally].That's a bummer.Then we had to change a lot of it.And that is worse than the initial sense of freedom.

Variation Across User Groups
To investigate variation across user groups we selected the roles and professional groups with at least three representatives among the interviewees.For roles this selection led to comparing the ten super users with the five end-users; for professional groups it led to comparing the six physicians with the six nurses.Table 6 shows the results.Overall, the comments were somewhat differently distributed for super users versus end-users and similarly distributed for physicians versus nurses.Two differences should be noted.First, the super users were more positive and less negative than the end-users (see Table 6).Either the clinicians who were more positive about the design-in-use approach became super users or the super users' larger involvement in this process made them more positive.This difference underlined the barrier that the design-in-use process was dependent on the few clinicians who were committed to the process (Barrier 15, Table 5).These few committed clinicians were in the group of super users.Second, the super users focused more on intradepartmental change, whereas the end-users focused more on interdepartmental change (see Table 6).Intradepartmental change was the super users' immediate responsibility and it was, probably, easier for them to accomplish because they had their primary knowledge and network in their department.In contrast, interdepartmental change involved negotiation and alignment with other departments.While the super users as a group appeared somewhat reluctant to engage this increased complexity, the end-users focused on the interdepartmental changes because they were the most evident outcomes of the design-in-use process.Several end-users had some difficulty giving examples of outcomes other than the interdepartmental changes of using the whiteboard for ordering physiotherapy and for coordinating when patients were ready for surgery.

Discussion
Design in use will only happen if motivated users make it happen.Thus, the clinicians' perception of the design-in-use approach is both an outcome of the implementation process and a key input to it.If they perceive the approach negatively, it is unlikely to succeed.If it succeeds, they are likely to perceive it positively.

5.1
How Do Users Perceive a Design-in-Use Approach to Implementation?
At the studied hospital the clinicians have one and a half years of experience with the design-in-use approach to the implementation of the whiteboard.That is, their perception of the approach has had time to form and settle.In summary, we find that:  The clinicians perceive the design-in-use approach to implementation in conflicting ways.In addition to many positive as well as many negative comments, the clinicians disagree about the associated opportunities and barriers. The super users are more positive about the approach than the end-users.As a consequence the super users serve as champions for the system, and the design-inuse approach is highly dependent on these few, committed people. Intradepartmental change is perceived more positively, probably because it is easier to achieve.The super users focus more on intradepartmental change, the end-users more on interdepartmental change, which is possibly more valuable. Standardization across departments conflicts with design in use within departments.While the clinicians acknowledge the need for standardization, the conflict affects their perception of the design-in-use approach negatively. The design-in-use approach is inextricably sociotechnical but the clinicians perceive the technology -the whiteboard -as more prominent than the work process.Less than one in five comments are exclusively about the work process. The clinicians' perception of design in use is more about implementing change than about preparing it or about training and support.That is, the approach becomes salient to the clinicians when its results start to influence their work.
 While the super users and end-users perceive the design-in-use approach somewhat differently, the physicians and nurses perceive it similarly.Thus, the clinicians' perception of the approach varies with their role in it, not with their primary task.
The clinicians' conflicting perceptions of the design-in-use approach have multiple and interrelated sources.One of these sources is the scope of the design-in-use activities.We propose that the clinicians probably perceive intradepartmental change more positively because it is easier to achieve and therefore proceeds more smoothly.In contrast, interdepartmental change is more organizationally complex, extends beyond the super users' immediate network, and requires the development and adoption of standards that reduce the clinicians' freedom in configuring the whiteboard for intradepartmental needs.This argument accords with Sanchez and Mahoney [37], who emphasize that changes internal to organizational components are much simpler than changes that cut across component boundaries because intracomponent changes can be handled locally whereas inter-component changes require organization-wide learning and decisions.That said, the potential benefit of intercomponent changes is larger because they may introduce structural improvements.The ordering of physiotherapy provides an example.However, the standardization involved in pursuing interdepartmental changes is a source of frustration and exemplifies the generally recognized friction between global and local concerns in the evolution of an infrastructure [40].While this study shows that the clinicians' appreciation of design in use interrelates with the scope of the pursued changes, further work is needed to spell out these interrelations in detail.
Another source of the clinicians' perceptions of the design-in-use approach is its blending of technical and work-process change.The technology -the whiteboardfeatures prominently in the clinicians' perception of the design-in-use approach but in contrast to Mehandjiev et al. [22] without worrying about the technical quality of the configurations.The absence of this worry may suggest that the clinicians are overconfident in the quality of their configurations [17] or that it is simple to configure the whiteboard.In either case, the perceived simplicity of configuring the whiteboard is an important contextual factor because it means that the super users have more time available for revising the work processes associated with the whiteboard.The design-in-use process is at least as much about revising work processes as it is about technical configuration.This sociotechnical outlook probably reflects that the whiteboard as such is of negligible interest to the clinicians, who instead perceive the whiteboard as the driver of changes that improve their work processes or, in other clinicians' opinion, largely fail to improve them.It reinforces the sociotechnical outlook that the design-in-use activities occur during use; traditional design (i.e., design before use) may be more prone to a predominantly technical outlook.The qualities of design in use, as opposed to design before use, are also highlighted by the finding that the clinicians' perception of the design-in-use approach is more about implementing change than about preparing it or about training and support.Truex et al. [43] argue that it is when a design starts to affect users in their daily work that the design becomes salient to them and they become motivated to influence it.That is, the clinicians are more likely to realize the implications of the whiteboard after they have started to use it and they are more likely to be able and motivated to voice their needs and concerns after they have started to use it.
A further source of the clinicians' perceptions of the design-in-use approach is whether they expect to receive a finalized system or are prepared to engage in design in use.Many clinicians expect and prefer to receive a system that has already been configured for their needs and, thus, is ready for use.However, some clinicians are prepared to continue the design of the system and associated work practices on the basis of their experiences from starting to use the system.The latter group appears to engage in design in use because they like it, find it useful, and believe they will be good at it [6].When previous design-in-use studies distinguish between different groups of people it has mostly been to investigate collaborations and tensions between users and developers [8], between users and management [41], and between super users and technical IT support [46].It has not been to investigate how different user groups may disagree about whether design in use is an appealing process.
We find that the distinction between super users and end-users explains some of the difference in the clinicians' perception of the design-in-use process but that the distinction between physicians and nurses does not.The clinicians' conflicting perceptions of the design-in-use approach makes it a critical decision who are selected as super users to drive the process but it also adds to the super users' task by extending it with a role of championing the whiteboard.To champion the whiteboard the super users must be able to influence their colleagues' attitudes and behavior.They must also be prepared to employ an outgoing and advocating approach rather than merely to provide opportunities that their colleagues may adopt or bypass as they see fit.Management could have supported the super users in this championing role but, instead, adopted a rather hands-off approach, which made it easier for the disinclined clinicians to remain uncommitted to the design-in-use process.

Implications
We see four implications of the study for a design-in-use approach to implementation.First, a design-in-use approach to implementation is dependent on a limited number of positively inclined users.It is unadvisable to adopt a design-in-use approach unless such users can be identified ahead of the implementation process.These users cannot be presumed to have all the competences necessary to accomplish design in use.Targeted support is necessary.Second, design-in-use activities with a wide scope are perceived more negatively.Thus, a design-in-use approach may be best suited for intradepartmental change.While appreciated intradepartmental change can be accomplished through design-in-use processes that proceed bottom-up, interdepartmental change requires more coordination, more formality, and probably a collaboration more similar to mutual development [24].Third, some users expect to receive a finalized system.These users will experience a design-in-use approach to implementation as unprofessional and they will be reluctant to take time away from their primary tasks to contribute to design-in-use activities.Organizations can work to change their attitude, can task those who engage in design-in-use activities with the additional task of championing the system, or can risk underutilizing the system.
Fourth, in order for design in use to happen the system must be used.Thus, to get the design-in-use approach going management must ensure system use.This requires clarity about the purposes for which the system must, as a minimum, be used.

Limitations
Three limitations should be remembered in interpreting the results of this study.First, the study is restricted to one hospital and one design-in-use process.The results cannot be presumed to generalize to all design-in-use approaches to implementation.On the contrary, design in use is a situated process through which a particular system and a particular use context are adapted to each other.Second, while the interviewees span six professional groups, we acknowledge that the majority of the interviewees are physicians or nurses.For example, there is only one secretary among the interviewees even though secretaries are involved in the clinical work [23] and in the use of the studied whiteboard.In addition, we interviewed more super users than endusers but at the hospital there are many more end-users than super users.The rationale for including many super users in the sample was their central role in the design-inuse activities.Third, our sample of interviewees is too small to enable statistical analyses of whether the users' perception of the design-in-use approach differs across professional groups or between super users and end-users.We would welcome a large-scale survey of how different user groups perceive design-in-use processes.The present study provides categories and findings for informing such a survey.

Conclusion
The clinicians at the studied hospital hold conflicting views about the design-in-use approach to the implementation of the network of interconnected electronic whiteboards.While some clinicians, especially the super users, welcome the approach and find that it allows for meeting gradually realized local needs, other clinicians expect new systems to be fully configured prior to go-live.The conflicting perceptions show that a design-in-use approach to implementation is not a panacea.Rather, it requires careful communication, targeted support, and may be better suited for intradepartmental than interdepartmental change.

Table 3 .
Perception of the design-in-use approach to implementation, N = 433 comments.

Table 5 .
Barriers, N = 224.Lack of standardization restricts the interdepartmental use of the whiteboard 15 7. Physicians have been peripheral to the design-in-use process 14 8.The need for training and support has been underestimated 14 9. Limitations inherent in the whiteboard technology and their physical location 13 10.Process has lacked direction, which should have been provided top-down 12 11.Little local need for the changes that can be made by design in use of whiteboard 12 12.Implementation of work processes lags behind implemented whiteboard facilities 12 13.Standardization across departments conflicts with design in use within departments 9 14.Replacing phone calls with whiteboard-mediated coordination is not non-loss 7 15.Design-in-use approach is dependent on the few committed people 7 16.Super users lack required knowledge 6

Table 6 .
Variation across user groups.