The problem of user designer relations in technolgy production, formatted

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.

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

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

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

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.

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

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,

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

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

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

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

The problem of user designer relations in technolgy production, formatted

Related slideshows

More Related Content

The problem of user designer relations in technolgy production, formatted