The problem of user designer relations in technolgy production, formatted
- 1. The Problem of User-Designer Relations in Technology Production A position statement to ECSCW ’03 workgroup 9 Pekka J. Muukkonen Department of Information Technology, University of Turku, Finland pekka@it.utu.fi Introduction This position statement is based on my ongoing research about the significance of customer-dialogue in information systems development (ISD) process. Preliminary results of this research suggest that in the real world, with real world restrictions to action, a preferable way of conduct in ISD resides somewhere between rationalistic and organized (deterministic) way to organizational change- process proposed by methods like Business Process Re-engineering (BPR) and Rational Unified Process (RUP) and in more context aware and situational (emergent) sentiment to the change as a result of Participatory Design (PD) driven design efforts. RUP and approaches in the vast category of PD aim to capture all the relevant knowledge necessary to build an adequate system to support meaningful action. In the comparison of these, dialectical activity during the design process could serve as foci. Problems in communication between different stakeholders during a BPR driven ISD process led to a closer inspection of participatory design and its offers to the development process – in particular the “how-what-why” use of representations and the rationale behind them. The research about PD and representations is based on literary review ranging from Habermas' theory of communicative action to Beyer & Holtzblatt's Contextual Design.
- 2. The problematisation of the relationship between users and designers was subjected to an empirical research, in which I examined how different stakeholders, especially users, were involved in different phases of development process. How (if at all) they were addressed as producers of design artifacts. This was examined by the study of a project organization and the interplay of different parties during the development process. In addition to the purely project technical issues, I also examined the various representations used in the whole process; how they were created and by whom, how they were used and addressed later on and in what situations. Results reaffirm the advantage of PD, which is to involve the end-user in the creation of these representations as a source for tacit knowledge about work. The viewpoint is from the designer’s side, since the empirical studies were conducted in a company that defines its position as “a producer of custom tailored information systems to support business processes”. The processes are not given by the customer organization, but they are mutually developed and defined by both parties. In most cases the production of resultant systems to support the processes is also done by the same company. This requires an intimate relationship on various levels and on many different phases of a development project. This also leads to the notion of the role of the designer. The role can be somewhat problematic, since it involves action on different levels of development and with multiple stakeholders with different and sometimes conflicting needs. One source of this notion is stated in the designer’s Janus role between management and users as seen by Howcroft & Wilson (2003). This exposes it to a fundamental discussion about the definition of action done by a designer. On the basis of earlier discussion the question is thus about the emphasis of related action entangled in these two action proposals to ISD. Their distinctions and commonalities, and of course the common goal – an operational system in
- 3. use. To illustrate the problem of user-designer relations, I present the levels of the customer-dialogue. The very heart of customer-dialogue, and the meaning of it, is in the creation of shared understanding in a mutual learning process. Dialogue acts as a way to introduce oneself across different communities of practice. In information systems design this is done with the help of different representations concerning the use environment, work practices and the application. The essence of the representational devices lies in their ability to capture the explicit and tacit knowledge relevant to all involved parties. Preliminary results also indicate that a success in customer-dialogue can be expected to lead to an increased customer satisfaction. A more exact and detailed theoretical standpoint definition is under preparation, but I’ll discuss the stated topics listed in this participation call from the current situation and knowledge gained from my research. A review to PD techniques or a description of BPR & RUP is not presented in this paper. Data was gathered by observation and with informal and semi-structured interviews. Data gathering resulted 32 hours of recorded interviews, which were transcribed later for more thorough analysis. The background to user-designer relations in design We can operationalize our thought towards practice via examination of two practices of developing information systems. I pair up the practices of BPR/RUP and PD, as they seem to build up from fairly distinct grounds. The very basis of problems in user-designer relation can be seen cascading from different “world views” defined by Pepper in his metaphysical analysis and
- 4. presented by Whiteside & Wixon 1988 1 . They illustrate a framework to a belief systems based on four distinct world views: mechanism, formism, organicism and contextualism. As a summary, it can be concluded that BPR promote action related more on the first two world views while PD relies more in the latter two. This issue is also related to the perceived role of a designer and his/her desired action in the development process - thus a concern of ontological and epistemological substantiations. This is most notably addressed in Hirschheim & Klein (1989), as they categorize the role of the analyst based on 4 different paradigmatic definitions by Burrell & Morgan (1979). Although they use a term the analyst, the way they use it is etymologically so close to the modern day caption of designer that I do not think I inflict great injustice in juxtaposing these. After all, this is actually the continuum question of what is a designer. From these paradigms, Hirschheim & Klein deduct the roles of systems expert, facilitator, labor partisan and emancipator/social therapist. Once again the opposing constellation of BPR and PD is rather fruitful, since one can find that the primus motivus and main rationale of BPR imposes the acceptance of first two roles and PD latter two. An another viewpoint to the subject is presented by Nurminen (1997), as he questions the pragmatic value of the paradigmatic analysis based on Burrell & Morgan classifications. He notably presents three different perspectives based on the ideological inspection of 'ideal types' – namely systems theoretical, socio- technical and humanistic (Nurminen, 1988). These ideal types lead to a certain type of involvement in the designer-user relationship. Viewed from this particular point of view, we can say that BPR relies more on the issues concerning first two, and PD dwells mostly on two last ones. As Nurminen points out, none of these ‘ideal types’ should be taken solely as a fixed standpoint for systems development 1 Original reference to Pepper, S.C. (1942) "World Hypotheses.", University of California Press, Berkeley
- 5. or use, but a mixture of all these three is required in a successful IS effort. I argue that this is true also in the cases of world views and paradigmatic analyses. For better communication one has to value different points of views. Solipsism and regarding any of the above mentioned as the only modus operandi can lead the design process astray. As a continuum to previous theoretical thinking, a successful design process (or project) should incorporate BPR & PD together from relevant parts and complement each other in order to build a system in practice; where business related restrictions exist in the form of limited resources, time and money. Thus the ISD-process can be seen as a negotiated compromise by different stakeholders where designer is one of the key actors– if not the one. Designer can not remain as an impartial and objective subject in the action of development and design (Howcroft and Wilson, 2003), but the more, the merrier. This can be achieved partially by taking as non-active role as possible in defining the substance of the artifacts i.e. the knowledge related content of representations. Activity done by a designer should focus in facilitating the design process. The paradox lies in the usage of terms “designer” and “user” itself. A major effort of a stated designer is directed towards rejecting the design activity itself, and focus more to supplement the action of others. This facilitation is manifested in action of using representations as mediative tools in communication between users, managers and application implementers; thus acting in an intermediary role. This is corollary to the notion of the symmetry of ignorance, where it’s stated that any solution to a complex (design) problem relies on utilization of tacit knowledge of all involved parties (Arias et. al, 2000). In practice power issues can not be left out of inspection, since in hierarchical organizations someone’s word has always more weight compared to someone else’s. This gives yet another lens to examine the distinctions of BPR and PD.
- 6. Representations and their utilization in action; Business Process Re-engineering and Rational Unified Process The core of BPR lies naturally in the defined processes. My empirical research indicates that ‘process-thinking’ is not a natural way of thinking about work or about systems (applications). In one of the cases under research, the reason for process modeling was an intention to enhance business performance by reframing, rearranging and unifying ways of working in a multinational business context. This was supposed to bring synergy benefits to multiple interest groups. The users involved (work experts – be they operational workers or managers/directors of it) and application implementers initially resented the idea to use process models as an initiative source for development of future working system. Decision to use process modeling was done by project leaders – one from customer organization and one from the development organization. Neither the intended users nor those in charge of application production were familiar with process techniques. The subject matter of the process description was done by selected representatives of the customer-organization, as they were regarded as experts in the field of their own work environment. Persons responsible for future application development (as managers) acted as a challengers of ideas – so it was somewhat like a ‘future workshop’ used in PD. Due to the unfamiliarity with modeling techniques, much learning was required on every step of the way. And to say – first time went terribly wrong; the final testing result was a shower of feature requests for the application. A lot of adjustments were made for the process of developing consequent applications. They were successful development projects from the development company’s point of view. Budgeting
- 7. and scheduling was easier to do, and the estimates were better than in the previous case. Process definition is too abstract representation of work to serve as a valid ground for system requirement definitions in building of an application to support work activity. It can be reasoned that process thinking detaches the described activity from the actual use context. If the abstraction is made at the level of inconvenience, it leaves them subjected to personal interpretations. After creating the process model it was deducted to use-cases as defined in Unified Modeling Language. In addition to process model and use-cases, some sort of prototypes were used in finding out and defining the action involved in individual process-phases and refining the use-cases. This was done in order to make it sensible to users (after customization period to the model reading), but yet again representations were too arbitrary descriptions for application builders, i.e. to those who do the programming of the technical system. They lacked detailed information about information flows and sequenced action needed to implement a physical system. Thus they were open for personal interpretations once again. To complement use-cases some other representational models were needed – for example planning and design of object-models & ER-diagrams. The link between these different representations is sometimes somewhat difficult to see, since the representations are used in different contexts and act as boundary objects for transferring knowledge not known to all parties. These boundary objects are always under influence of any given presumptions of their meaning in a particular community of practice. One representation that could contain all the relevant information for all involved parties would of course be ideal – but does not seem possible, even in the case of prototyping. A return to the first application and the problems it encountered shed some light on how a BPR driven development process can be made workable from the point of a developer. After defining the process and building task decomposition,
- 8. presented for example in use-cases, there is no room for deviation from these. The risk lies in challenging the tacit knowledge embedded in the process model and use-cases. If the application isn’t built after the exact specification described in those models, there is the risk of a malfunctioning application – in a sense of getting the work done by a future user. And the presumption is that the modelled process suits the working environment without question, and is custom fit to the existing social system of the work place. Otherwise the applications are at least partly useless and the intended changes are unreachable. This is the major risk of BPR. It can only be tested as an abstract system and on the level of thought. Although parts of it can be tested via prototypes that represent parts of the whole process, the final result is viewable only when the process is implemented as a whole. In this case the scope of the BPR was so large, and the results were intended to be used in so many different units that a gradual implementation was not considered as an option. Not a single ethnographical technique was used to describe the use context of future system. The fit relies solely on the expertise of selected representatives. The final result is yet to be unveiled, but seemingly some problems in the implementation phase lie ahead. Although beneficial to the designer organization, this approach leaves open many crucial questions about the organizational implementation and the subsequent use of the applications for creating a (work)system in the customer organization, e.g. the adoption of 1000+ pages of task prescriptions via training. Notions of customer-dialogue in ISD Levels of dialogue are depicted in table 1. BRP & RUP offer abstract definitions, while PD techniques are more concrete and subjected to twiddling with design artifacts thus giving a very different approach to capture the
- 9. knowledge to the representations. Differences can also be found in where, how, why and by whom they are used. Actor Direction of knowledge transfer Actor Prime motive of action Social action type (Habermas) World view (Pepper) Perspective on IS (Nurminen) Paradigmatic notion of designer Tools, techniques, methods Customer Designer Examination of existing social systems Communicative Contextualism Humanistic Social therapist, labor partisan Ethnographies, contextual inquiry, workplace studies etc. Customer Designer Design of work, Enhancing business operations Discoursive & strategic Formism Sosio-technical Facilitator, emancipator BPR, RUP, future workshops, exploratory and experimental prototyping etc. Customer Designer Design of a technical system instrumental Mechanism Systems theoretical Systems expert OOA/OOD, ER- descriptions, DFD etc. Table 1. An analytical classification of the phases and levels of customer-dialogue In this context the customer can be interpreted as user, since the notions of the user varies in different levels and in different phases of activity. It includes both managers and end-users. Also the paradigmatic notions and perspectives are not to be interpreted to exist only in the sole activity phase as seen in the table 1. Rather they are suggestions of the prevailing conditions and their emphasized proportions. As a result their mixture should be in delicate balance in every state of the dialogue. The knowledge referred in the table is a notion to the distinct knowledge belonging to a particular community of practice. It should be noted that the referents user and designer are in flux in practice. The case of a design can be viewed as hermeneutical learning activity. Strict boundaries do not exist and the success of design relies in an ability to move chameleon-like across different communities of practice and introduce oneself to different language games. This means adopting relevant aspects of tacit knowledge and binding this gained understanding to representations to support the efforts of others. From the standpoint of social action theories, the action of any design effort can be derived to the review of dialogue on different levels. From the
- 10. observation of dialogue we can conclude that BPR entails a rigid, top-down oriented, rather formal, rationalistic and deterministic way of change, and is based on strict discipline by the nature. The design activity is done away from the actual use situation. The controllability is easier, but leaves it subjected to a conflict with emergent way of seeing the change process. PD and techniques used in it are more informal, flexible and they promote equality as they incorporate the tacit dimension of knowledge to the representations in a joint endeavour. Design activity is in situ of work. They lack detailed controllability and inflict major challenges to the practical projects in business environments. Problems in the user-designer relationship stem from the reified portions of these idiosyncratic dichotomies. A synthesis and a common utilization of these would be profitable ex ante. Focus on the different levels of customer-dialogue could serve as a starting point for a discussion about the interlinking of these dichotomies. When any of these presented dichotomies, not only PD – BPR, is used as the one and only, it creates an imaginary boundary within a social system. This boundary prevents the creation of shared and mutual understanding. Although the definition of the concept customer-dialogue is still in progress and this presentation lacks the description of adjacent way to utilize dialogue to overcome these boundaries, I hope you find some of the ideas noteworthy. Arias, E; Eden, H.; Fischer, G.; Gorman, A.; Scharff, E. (2000).“ Transcending the Individual Human Mind – creating shared understanding through Collaborative Design.” ACM Transactions on Computer-Human Interaction 7(1): 84-113 Burrell, G.; Morgan, G. (1979). "Sociological Paradigms and Organisational Analysis." Gower Publishing Company Ltd.: ISBN 0-566-05148 Hirschheim, R.; Klein, H. K. (1989). “Four Paradigms of Information Systems Development." Communications of the ACM 32(10): 1199-1216
- 11. Howcroft, W.; Wilson, M (2003). “Paradoxes of participatory practices: the Janus role of the systems developer.” Information and Organization 13: 1-24 Nurminen, M. I. (1997). “Paradigms for sale: Information systems in the process of radical change.” Scandinavian Journal of Information Systems 9(1): 25-42 Nurminen, M. I. (1988). “People or computers: three ways of looking at information systems.” Studentlitteratur: ISBN 91-44-27251-0 Whiteside, J; Wixon, D (1988). “Contextualism as a world view for the reformation of meetings.” Proceedings of the 1988 ACM conference on Computer-supported cooperative work: 369-376