Design and development of an innovative system does not end with delivery and installation of the software product. Nor is innovation facilitated by system maintenance focused on “bug fixes.” Rather it requires recognizing how users innovate around system dysfunctionalities. It requires designers to go “native,” as if they were an applied anthropologist, and understand how the users interpret and appropriate the system for good or ill. In this way innovative systems are able to evolve post-implementation through a design and use cycle we call the “Innovation Evolution Cycle.” This is not about rapid prototyping, but rather about ongoing cooperative interaction between designers and users as equal contributors in driving innovation. This is more than just user-centered design [for example, Beyer1] or an agile method—it continues beyond implementation throughout the useful life of the system. It takes as a premise that the users’ work environment is dynamic and constantly changing and thus innovative systems must continually evolve with changing work practices.
This novel approach to systems design and development requires a radical shift in the interaction of users (both operational end users and managers) and system developers (business analysts, systems analysts, project managers and designers). To this end, we present an illustrative case demonstrating the potential for innovation through evolution. Our goal is not to provide a methodology, but rather to identify the foundational concepts necessary for any methodology or systematic efforts for evolving innovations.
We begin by exploring technology in use: how users apply or “appropriate” the features and functions of a system. We then present a classification of different types of appropriations, the Appropriation Matrix, as a prelude to explaining their role in the Innovation-Evolution Cycle. Finally, we illustrate application of the Appropriation Matrix in the context of a reservation system at a large accommodation chain.
Understanding Technology in Use
From a functional perspective, systems provide “structures,” sets of features for performing some task or process with the system. Although there is structure, there is also substantial choice about how a system is used. Moreover, use is a social process that is not solely determined by design. As DeSanctis and Poole3 note:
people actively select how technology structures are used…. [they]may choose to: (a) directly use the structures; (b) relate the structures to other structures (such as structures in the task or environment); (c) constrain or interpret the structures as they are used; or (d) make judgments about the structures (such as to affirm or negate their usefulness).
DeSanctis and Poole coined the term “Appropriation” to describe the behaviors evidencing choices about how users apply the structural features and functionality of a system. Appropriations can be functional, and thus yield organizational benefits. They can also be dysfunctional and thus circumvent the organizational benefits offered by a system, or even be contrary to an organization’s goals. Orthogonally, appropriations can be “faithful” to the designers’ intentions. Alternatively, they can be “unfaithful, ” resulting in usage practices not even contemplated by the designers. Importantly, unfaithful appropriations are not bad per se: indeed they may be innovative.2 Over time usage practices evolve as the social and commercial context of use changes. Thus, the manner in which a system is appropriated is not fixed, but evolving over time.
The Appropriation Matrix
We classify appropriations along two dimensions: faithful/unfaithful and functional/dysfunctional. Table 1 shows the four quadrants of the Appropriation Matrix.
Conformant Use appropriations are those that are both faithful and functional. In such situations, users are efficiently and effectively using the features of the system as the designers intended. On the one hand, Conformant Use is a favorable outcome: a melding of successful design and stable usage patterns. From an innovation perspective however, Conformant Use implies a lack of stimulus for innovation (for example, recognition of problems or opportunities) and thus design and use may have stagnated. The key question and task facing designers and users in situations of conformant use are thus:
Question: Is this conformant use a satisfactory equilibrium or stagnate use?
Task: The search for a stimulus for innovation.
User Innovation arises when unfaithful appropriations are functional: they have positive organizational performance benefits. This may be the successful result of efforts to work around a design flaw (or a system outdated due to change in the environment). Alternatively, it may represent user insight derived from their immersion in the context of use (i.e. understanding from the “coalface” or “factory floor”). Clearly, these innovations need to be recognized and communicated to the designers to facilitate cooperative interaction and further innovation with the system. Of course this does not preclude developer led innovation. The key question and task facing designers and users in situations of user innovation are thus:
Question: How can this user innovation be incorporated into the current system?
Task: The search for innovations (by users and subsequently by designers).
When a user does not use the system as intended and the performance outcomes are undesirable, we label the appropriation Circumvention. Such unfaithful dysfunctional appropriations can be reflective of different conceptualizations of the task between designers and users, possibly due to a lack of effective communication of the purpose and functionality of the system. Shared task conceptualizations and effective communication are a key aspect of the cooperative interaction we see as the essential ingredient to innovation evolution. The key questions and task facing designers and users in situations of circumvention are thus:
Questions: Why did users circumvent the system? Why did developers design the system the way they did?
Task: Develop a shared task conceptualization.
An appropriation that is faithful but dysfunctional is labeled developer Domination. In part, this is an issue of flawed or dysfunctional design. However, the fact that users have not innovated around the dysfunctionality is also a matter of concern. The flavor of cooperative interaction has been lost as users merely take the system as given. They follow the lead of developers, rather than engaging cooperatively with them to evolve the system to a more functional product. The key questions and task facing designers and users in situations of Domination are thus:
Questions: Why did users appropriate faithfully when the system is dysfunctional? Why is the design dysfunctional?
Task: Develop an open dialogue between users and developers to discover dysfunctionalities.
The Innovation Evolution Cycle
Figure 1 shows The Innovation Evolution Cycle. The “ideal” situation is to be continually cycling through from Conformant Use to User Innovation and back to Conformant Use (as the innovations are incorporated into a revised design and system). This is the pattern for user led innovations. In a similar vein, there is a cycle between Developer Innovation and Conformant Use for Developer led innovations. These two cycles form what we term the “ideal” design and use cycle. The key to these two cycles of innovation is cooperative interaction.
Cooperative interaction is more than just effective communication and feedback to develop a system that meets jointly understood goals. It is a shared commitment to innovation, an ongoing collaboration in team spirit, and integration of the goals of users, designers and the organization. Cooperative interaction enables reflection and develops shared conceptualizations of both operational level tasks and big picture processes and purposes. It is a relationship characterized by equality and longevity: as long as innovation is the goal, the interaction continues. It is thus much more than simple user feedback and software maintenance. Figure 1 shows the Innovation Evolution Cycle incorporating both user led and developer led innovation. It also illustrates where the cycle can go awry (leading to states of domination or circumvention). Such situations result from a lack of cooperative interaction. Importantly, cooperative interaction should span the entire useful life of an innovative system. Innovations evolve over extended periods of cooperative interaction.
User led innovation is triggered by efforts to maintain consistency between the purposes of the system and the changing work environment. Inconsistencies lead to innovation through design flaw workarounds and coalface insights, which in turn require cooperative interaction to translate into systems. Without commitment to innovation and shared conceptualization of processes and goals (across users, designers and the organization as a whole), coalface insights and workarounds may ultimately prove dysfunctional (for example, the innovative workaround may be only locally beneficial, and may have dysfunctional impacts on the activities of other users). Only with cooperative interaction is any innovation properly incorporated back into the system for the broader benefit of all users and the organization as a whole. In turn, this leads to a greater degree of shared conceptualization of processes and goals, and a virtuous cycle of cooperative interaction is engendered. Developer led innovation is triggered by technical and competitive pressures (e.g. observation of developments in competing systems), by the insight gained from cooperative interaction with users and the resulting shared conceptualization of processes and goals. More formally, developer led innovation is informed by the nature of technical support requests, and direct user feedback (both positive and negative).
Introducing reflection and user empowerment to situations of Domination can enable a return to the ideal design and use cycle—cooperative interaction becomes possible again. Reflection permits the dysfunctionality to be recognized. Empowerment enables users to communicate this effectively to the designers or to innovate around it. For example, this could be achieved through the development of appropriate practices in Service Support under the Information Technology Infrastructure Library (ITIL; www.itil.co.uk).
Moving from Circumvention to Conformant Use suggests a need for greater restrictiveness4,5 to be introduced through system controls, training and user incentive schemes. The purpose of this restrictiveness is clear to effectively communicate the goals of the system—thus prompting the development of shared conceptualization of the task that is essential for cooperative interaction. Of course greater restrictiveness limits the opportunity for users to innovate, so care must be taken in balancing the trade-offs between restrictiveness and flexibility. Clearly, this requires an appropriate cultural environment if the desired level of cooperative interaction is to thrive.
Illustrative Case: Omega’s Reservation System
Detailed below is analysis of a reservation system at a large franchised accommodation chain (hereafter called Omega), that illustrates an application of the Appropriation Matrix and potential for cooperative interaction. Our analysis concentrates on use of a transaction processing system, because it is a core business system, with its use characteristically routine, highly structured and less flexible (for example, compared with say a business intelligence system). Consequently, any evidence of innovation or variability in usage practices provides a compelling argument for our approach. Furthermore, the system is well established, having been in use for over 10 years, and in its eighth release version. Until recently, designers and users of this system have had very little interaction: that is, cooperative interaction has been almost non-existent. Our goal is to provide evidence of the potential for evolving innovations in a situation where cooperative interaction is lacking or marginal at best.
For illustrative purposes we consider appropriations around two key functional aspects of the reservation system: group bookings and pricing. The effective management of group bookings is important both in terms of customer relationship management, but also in terms of assessing the profitability of different market segments. Adequate flexibility and control in pricing is essential for competitive survival in the accommodation sector. We contrast the manner in which different franchisees within the Omega chain appropriate system functionality in these two key areas.
Group bookings pertain to reservations for conventions, clubs, family reunions etc. By design group bookings include a master booking that houses details of the group as a whole, and child bookings connected to the master booking that house information about individual guests (for example, individual arrival and departure dates). The ability to recognize reservations as part of a group booking is used at times in novel ways and in some cases completely ignored by various franchisees within Omega. Table 2 (Panel A) describes three different ways in which the group booking function is appropriated within Omega, including non-use of the facility.
In Table 3 (Panel A) we classify these appropriations and describe what would happen if cooperative interaction were introduced into the situation. In each case we consider whether the appropriation is faithful or unfaithful to the designer’s intent by comparing actual use to training materials and system documentation. We also classify each appropriation as being either functional or dysfunctional from both an operational and a managerial perspective. Operationally, we focus on the efficiency and effectiveness with which relevant processes (for example, check-in, reservation taking) may be executed. Managerially we consider the degree to which the appropriation helps (or in the negative, hinders) the collection of data that enables effective management of relevant processes and the business as a whole (such as analyzing market trends).
In a similar vein, pricing functionality engenders interesting appropriation issues. In response to increasing competition, Omega franchisees have begun to be more flexible and aggressive in pricing. This includes tying prices to minimum stay lengths and the use of non-traditional sales channels such as sales by auctions. Both of these business innovations have required workarounds with the reservation system. Panel B in Table 2 and 3 describe and classify two relevant appropriations of pricing functionality. Interestingly, we suspect that some franchisees have been slow to adopt the business innovations in pricing because the system dominates, and they have been unable to develop suitable workarounds (user innovations) to cater for the new modes of business.
Two key insights are obtained in the analysis presented in Table 2 and 3. Firstly, appropriations (and thus innovations) can have vastly different impacts depending on whether they are viewed from an operational perspective, or a managerial perspective. Secondly, all of the issues and undesired outcomes can be addressed through the development of shared task conceptualizations and effective communication that is central to cooperative interaction. Importantly, this cooperative interaction is not simply between users and designers, but also amongst different user groups (such as operational versus managerial).
Outcomes and Implications
There are several notable outcomes arising from this analysis. Firstly, there is variation in the appropriation of systems at the system feature level. Secondly, there is variability in appropriations from franchisee to franchisee, despite common training materials and system documentation. Furthermore, some of these appropriations are quite innovative (and thus warrant sharing within the firm and with the developers through cooperative interaction). Finally, it is clear that an appropriation may be functional at an operational level, but dysfunctional at a managerial level. This suggests the importance of communicating managerial information requirements to operational level staff—for cooperative interaction to be open to both operational and managerial users.
Pragmatically our analysis of these simple appropriations highlights the potential for innovation evolution. Innovation evolution is driven by cooperative interaction: shared commitment to innovation, equality and longevity of collaboration, and the development of shared conceptualizations of both operational level tasks and big picture processes and purposes. Consequently, to innovate continually requires recognizing that design and development of a system does not end with delivery and installation of the software product, rather it evolves through ongoing cooperative interaction.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment
Comments are closed.