# Usability Specialists as Boundary Spanners – An Appraisal of Usability Specialists’ Work in Multiparty Distributed Open Source Software Development Effort

Netta Iivari

► To cite this version:

Netta Iivari. Usability Specialists as Boundary Spanners – An Appraisal of Usability Specialists’ Work in Multiparty Distributed Open Source Software Development Effort. 14th International Conference on Human-Computer Interaction (INTERACT), Sep 2013, Cape Town, South Africa. pp.571-588, 10.1007/978-3-642-40480-1_40 . hal-01501774

HAL Id: hal-01501774

https://inria.hal.science/hal-01501774

Submitted on 4 Apr 2017

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Usability Specialists as Boundary Spanners – an Appraisal of Usability Specialists’ Work in Multiparty Distributed Open Source Software Development Effort

Netta Iivari

¹ Department of Information Processing Science, University of Oulu, P.O. BOX 3000, 90014 Oulu, Finland

netta.iivari@oulu.fi

**Abstract.** This study examines the work of usability specialists in a multiparty research project producing an open source learning application for children, with children. Children as a user group has been acknowledged decades ago and methods for involving them have been devised, but there is a lack of research examining what happens to children’s input in practice, when integrated with actual development. The paper contrasts the empirical findings with the existing research on the usability specialists’ roles and with the knowledge management literature on boundary spanning, which argues that for successful knowledge sharing and arriving at shared understandings there needs to emerge boundary spanners and boundary objects and a new joint field of practice within which the experts involved can collaborate. This paper argues for the boundary spanner position to be acquired by usability specialists. Instances of successful boundary spanning are described and conditions for successful boundary spanning are discussed.

**Keywords:** Usability specialist, boundary spanning, boundary object, children

## 1 Introduction

This study examines the work of human computer interaction specialists (HCI), whose work practice has been studied under the varying labels such as usability professional [7, 13], usability specialist [4, 6], usability practitioner [25] and HCI practitioner [12, 15]. Here, these experts will be called usability specialists [in line with 3, 13], as this is a widely known and accepted job role in industry and there already is an association for usability professionals. This choice naturally makes usability as the main goal of their work, even though they may place their emphasis also or actually even more on usefulness or high quality user experience.

However, even though the importance of usability specialists’ work has generally been accepted in the industry, there also are pertinent problems in their work. One of those has been their work of not having impact on the solution under development [e.g. 4, 7, 15]. Usability specialists, if not totally ignored, may be in informative or
consultative roles, meaning that they may only be allowed to provide information or
to comment on predefined design solutions, without having decision-making power or
ability to directly impact the design solution [15]. Also studies in open source soft-
ware development have shown that usability specialists, when trying to contribute to
the development, tend to remain isolated and alienated and their work not necessarily
having any impact on the actual solution [e.g., 1, 26, 27]. However, it is recommend-
ed that usability specialists should be in participative role, actively taking part in the
design process, having decision-making power regarding the solution [15, 27] if not
acting as the designers having authority to make the important design decisions con-
cerning the product quality [e.g. 8].

This paper will examine what kinds of roles usability specialists adopt in multipar-
ty, distributed IT development settings. The case inquired in this paper is a multiparty,
distributed research project developing an open source application for children, with
children. This study thus truly represents a multicultural setting for HCI: the project
participants are located in different countries, working in different organizations
(companies or universities) and represent different disciplines (information technolo-
gy, human computer interaction, educational science) and generations. Children, i.e.
the future users of the application, are important participant group who possess valua-
ble knowledge on what being a kid entails [11] that should be utilizable during the
development, among other expertise. Although there has been extensive research
interest in the means enabling children to take part in IT development [e.g. 10, 24],
there is a lack of research on the participation of children in large-scale multiparty
development efforts. The literature on global, distributed, open source and multiparty
development efforts reveals that nowadays there might be multiple organizations,
professions, areas of expertise, disciplines, and nationalities involved in IT develop-
ment, making collaboration challenging [1, 5, 19, 21, 22, 26]. To make sense of the
work of the usability specialists in such a complex setting, indeed involving multiple
organizations, professions, areas of expertise, disciplines, nationalities as well as gen-
erations, we will rely on theoretical framework on boundary spanning [22]. This
framework maintains that to be able to successfully span the boundaries of different
organizational and professional settings, there needs to be people acting as boundary
spanners as well as common, shared objects acting as boundary objects [22]. The
conditions for such to emerge are discussed in this paper.

The paper is structured as follows. The next section discusses the existing body of
knowledge related to the work of usability specialists, pinpointing areas in need of
future study. The existing categorizations of usability specialist roles are discussed
and the theoretical framework of boundary spanning is introduced and combined with
the role repertoire presented. The third section introduces the empirical case of this
interpretive case study as well as the research methods used in relation to studying the
case. The fourth section presents the empirical findings, the fifth section discussing
their implications and limitations as well as paths for future work.
## 2 Theoretical Framework

Even though user interface design has aroused researchers' interest already during 1980s, empirical studies on the work of usability specialists are more recent. During 2000s, there has been increasing interest in this topic. Gulliksen and his research group have reported numerous studies, mostly concerning public authorities in Sweden [e.g. 3, 12, 13], while Iivari has analyzed usability specialists work practices in product development in Finland [15, 16]. These are qualitative inquiries on the matter, but there is also some survey research carried out [6, 12, 37]. Moreover, one can identify recent HCI journal issues empirically addressing usability work in organizations (see e.g. Interacting with Computers 18(4), International Journal of Human-Computer Interaction 21(2), International Journal of Technology and Human Interaction 5(3)). Furthermore, there also are some studies addressing usability specialists' work in recent development settings such as in distributed open source software development [e.g. 26, 27], reporting on usability specialists' ways of working when face-to-face contact is impossible. However, the literature remains silent of multiparty development efforts, where there are numerous stakeholder groups with which usability specialists have to cooperate. On one hand, the HCI literature has touched upon the issue in the sense that it maintains that usability specialists have to act as usability champions and evangelists inside their organizations and try to seduce and convince numerous stakeholder groups, i.e. developers, managers, sales, marketing and documentation, to buy into usability [2, 8, 13, 15, 16, 25, 37]. On the other hand, the literature on multiparty IT development efforts reveals that there nowadays are parties from numerous organizations and even countries involved, representing different kinds of areas of expertise: not only technology, marketing and business, but also strategy, manufacturing, education, curation, meteorology etc. [5, 19, 20, 21, 22]. In this kind of a design team collaboration is a true challenge [e.g. 20].

### 2.1 Usability Specialist Roles

There already are studies that have defined a set of roles for usability specialists to adopt during development. Iivari [15] has identified four of those: informative, consultative, participative and designer roles. In the informative role, usability specialists provide information to developers about users based on their empirical studies concerning the actual or potential users or on their general state-of-the-art HCI knowledge [15, 16]. However, this role is problematic as it does not necessarily have any effect on the actual design solution [15]. In the consultative role, usability specialists provide feedback to the already made design decisions, again either relying on the user feedback gathered through empirical evaluations or on the expert evaluations utilizing the general HCI knowledge [15, 16]. This role may not have any impact on the actual design solutions either and another problem is that this role may position usability specialists as police, only pointing out negative issues that may hinder their possibilities to have any impact even more [15]. In the participative role, furthermore, usability specialists are accepted as active participants in the design process, having some decision-making power regarding the solution among the other team members
[15, 16]. In this situation usability specialists indeed can contribute, but it is a chal-
lenge to involve a usability specialist in every relevant design situation [15]. Moreo-
ver, in the designer role, usability specialists are given the authority to make the im-
portant design decisions concerning the product quality based on their expertise [3, 8,
15, 16]. However, this may actually remove the job role of the usability specialist
altogether that has also proven out to be problematic as in the situation in which every
designer should be also an expert in usability; usability may end up in being taken
care of by nobody [15].

Finally, also a facilitator role has been identified in the HCI literature [4, 7, 13, 16, 17, 30]. Either it is emphasized that usability specialists should orchestrate design session and facilitate collaboration among developers and users [4, 7, 13, 16, 17, 30] or usability specialists are positioned as evangelists that should advocate usability inside their organization even more broadly, targeting the management, sales, marketing and documentation [2, 8, 13, 15, 16, 17, 30, 25, 37]. The developers, in particular, should perceive usability specialists as team members and allies [25, 37], but also the other stakeholder groups should be addressed [2, 8, 25, 37].

## 2.2 Usability Specialists as Boundary Spanners

In multiparty design teams, in which there are experts representing different disciplines, professions, organizations and nationalities cooperating, it has been reported that communicating, collaborating, and arriving at shared understandings are very challenging [5, 19, 20, 21]. However, knowledge sharing and the creation of shared understandings are also postulated as vital for successful multiparty design teams. For these reasons, in addition to the existing HCI literature on the work practice of usability specialists, this paper relies on the theoretical framework on boundary spanning [22], which focuses on a successful knowledge sharing.

Within this framework, important is the emergence of boundary spanners, boundary objects and a new joint field of practice, within which the agents involved can share knowledge [22]. The emergence involves that the boundary spanners achieve at least a peripheral understanding of each involved practice as well as legitimacy as negotiators on behalf of the parties whose interests they are attempting to represent. In addition, they need to transform their own practices so that they accommodate the interests of the other parties. [22] They also need to create and use boundary objects, which in turn need to attain local usefulness and common identity from the viewpoint of each involved party [22, 29]. The boundary objects may be existing ones or they may be created or modified by the boundary spanners specifically for the purposes of boundary spanning [22].

Boundary spanners and particularly boundary objects have been extensively dis-
cussed in the literature and shown to contribute to knowledge sharing and to the de-
velopment of shared understandings among various experts [20, 22, 23, 29] as well as
to mobilizing for design action and to legitimizing design knowledge [23]. While
boundary objects are not the main focus of this paper, they will be touched upon in
the empirical analysis. The notion of boundary spanners, on the other hand, will spe-
cifically be used, to give more depth to the analysis of the roles assigned for usability
specialists. It will enable making sense of how usability specialists can act as facilitators in a distributed multiparty design team: how they can enable knowledge sharing and the creation of shared understandings among the various experts. According to Levina and Vaast [22], this involves 1) gaining at least a peripheral understanding of each involved practice; 2) gaining legitimacy as negotiators on behalf of the fields whose interests they are trying to represent 3) transforming their own practices so that they accommodate the interests of the other fields; 4) producing boundary objects, which need to gain local usefulness and common identity from the viewpoint of each involved practice. With this analytic lens, the empirical case will be examined.

## 3 Research Design

The case examined in this paper is a research project that develops a learning application for children, with children. The overall idea for the application came from researchers within the field of educational science, and the justification for the specific features of the application are derived from educational science research. These researchers had earlier been involved in creating an initial version of this application and this project was to produce an enhanced version of it. The other parties—IT experts, usability experts, and additional educational science experts, representing different research institutions and two IT companies—became involved in the project ideation later on. The project participants were located in four countries, two IT companies, and five research institutions; the children involved were from numerous schools and kindergartens from different countries.

The project was to last for three years. The first year was about specifying the requirements for the forthcoming application and designing the application, including both educational, usability and software design. The second year was to be mainly about implementing the application, while the third year was to be about evaluating the application from the viewpoint of project goals. The contribution of the usability specialist was significant especially during the first year of operation on which this analysis will concentrate. During the first year, work related to following aspects was to be carried out: requirements specification, usability and design. In addition, development work was to begin during the last two months. The work was distributed and involved multiple project partners. The project partners extensively relied on email and a shared data repository for knowledge sharing and communication. In addition, video conferencing and voice chat solutions were used and two face-to-face meetings organized during the year. The responsibility of the work to be carried out was a shared responsibility of multiple partners of different disciplinary backgrounds, working in different institutions and countries. For all major project deliverables, however one specific institution was nominated as the responsible leader.

The usability specialists had as their task to take care of usability and child-centeredness. They worked extensively with children during the year. Numerous children were involved in two different countries. The work involved different kinds of experiments connected with evaluating certain design ideas, empirical user testing, paper prototyping with children, interviews, observation, and different kinds of design
sessions [see e.g. 10, 11, 24]. The children acted as testers, informants, and design partners [see 10], drawing, talking to researchers, using the earlier version of the application or the new version presented as a paper prototype, and playing games or creating prototypes of the application of art craft materials, among other activities.

This paper reports an interpretive case study on the work of usability specialists in this multiparty, distributed open source development effort [see e.g. 18, 31]. In this study, in line with Klein and Myers [18: 69], it is assumed that “our knowledge of reality is gained only through social constructions such a language, consciousness, shared meanings, documents, tools, and other artifacts” and the study does not try to identify independent and dependent variables, but instead to understand the complex case and human meaning making in it in more depth. My role can be characterized as “involved researcher” – I had a direct personal stake in the outcomes and interpretations, but on the other hand I was able to get a direct sense of the field from the inside [31]. I was involved in the project already during the funding application preparation and I acted as a manager and supervisor of more junior researchers working on the project. Therefore, I acted both as a participant and as an observer in the project. I represent one of the usability specialists in the case.

The research material consists of documentation produced during the project. The material consists of official project documents, project deliverables (of particular interest are the requirements specification and design documents), different kinds of memos and unofficial documentation (e.g., different kinds of sketches, scenarios and drawings) and email correspondence among the project participants. The documentation was created independently of my research interest for the purposes of the project, but they were collected to form the research material to be examined.

During data analysis, I first reviewed the project activities from the viewpoint of usability specialists: I identified the instances in the empirical material that could be connected with their role in the development. After collecting this huge amount of evidence together, I started to make sense of it within the analytic framework developed. I identified the boundaries that needed spanning in this case. Levina and Vaast [22] consider organizational and professional boundaries which apply quite well to the usability specialists' interaction with the educationists and developers in this case. Afterwards, I identified successful cases of boundary spanning: I looked for situations in which the usability specialists had succeeded in facilitating collaboration and knowledge transfer across the identified boundaries – the identification was based on actual evidence of the impact of the usability specialists' work or on the other parties acknowledgement of the usability specialists success in creating a new joint field of practice where the experts successfully shared knowledge and created shared understandings. After identifying such cases, I also gathered data on whether the usability specialists had aimed at 1) gaining at least a peripheral understanding of each involved practice; 2) gaining legitimacy as negotiators on behalf of the parties whose interests they are trying to represent 3) transforming their own practices so that they accommodate the interests of the other parties; 4) producing boundary objects that have local usefulness and common identity from the viewpoint of each involved practice.
# 4 Empirical Insights

In this section two differing types of successful boundary spanning will be presented. In the first type the usability specialists succeed in influencing the designs and prototypes created by the educationists and the developers, making them to integrate into their work objects issues that the usability specialists considered important after working with children. In the second case, the usability specialists succeed in facilitating shared understandings among the educationists and the developers related to specifying the software requirements for the project, the other parties thanking the usability specialists as a useful 'link' between the developers and the educationists.

## 4.1 Usability Specialists Impacting the Educationists' and the Developers' Work Objects

As mentioned, the usability specialists used different kinds of methods for working with children, i.e. with the future users of the application. The children took part as informants, testers and design partners [10], Through all the usability activities, one can conclude that the usability specialists become relatively well informed of their users. The usability specialists also seriously tried to take into account that they were working with children, carefully planning all their sessions with children, including play and singing, for example: "We implemented the program as planned. As a start and addition, [a usability specialist] sang with the children a [song] to remind the children who we were." (Usability specialist, memo)

The educationists started the project work by identifying requirements for the application. First they sent their ideas through email, but soon they captured them into a lengthy PowerPoint presentation on the matter. Afterwards, they started to capture their ideas into hand drawn scenarios of use. Later on, they delivered the requirements in a table format. All these requirements documents were sent to the other project partners through email. Especially the educationists wished for the developers' feedback to the ideas presented, while also the usability specialists were free to comment.

The usability specialists, on the other hand, started planning their empirical work with children. Before carrying it out, they asked for input from other parties. The educationists hoped for children's feedback to some icons and design ideas as well as children's ideas relating to some features planned for the application. Based on their empirical work with children, the usability specialists informed the other parties of their results. They also created two formal project deliverables: Usability Requirements and Usability Design. The first one described the evaluation results concerning the earlier version of the application, user feedback to some initial design ideas of the educationists as well as children's own ideas and designs. The usability specialists had also carried out expert evaluations on the earlier version of the application and on the scenarios, the results of which they presented as well as some general state-of-the-art HCI knowledge on interaction design and children. The Usability Design document, on the other hand, described the screen contents, the functions available, possible user actions and system responses. All in all, the usability specialists were positioned in informative, consultative and designer roles, as they were providing infor-
mation and feedback to the other project parties as well as making important design decisions themselves [see 15].

The educationists, then again, created their own Educational Requirements and Educational Design deliverables. The usability specialists had taken the educationists' scenarios as a basis and evaluated and refined them together with children, based on which they had created their usability design. The educationists, however, had continued their work with the scenarios; hence, those that the usability specialists had evaluated were not the most current ones anymore. The educationists had then based their designs on the refined scenarios that neglected some of the results of the usability specialists' work. While producing their documents, neither party carefully examined the other party's documentation to prevent conflicts and overlapping work. Instead, both parties, when delivering their documents, mentioned that there might be some overlap between their and the other party's documents, and asked others to check that. Unfortunately, the educationists' and the usability specialists' design documents were scheduled to be delivered at the same time, even though the usability specialists document was expected to create 'usability on top', which naturally was impossible as they did not have the educational design at hand when creating their own design. These two designs ended up in being in conflict with each other and the educationists and the usability specialists had to negotiate the designs (adding the participative role to the usability specialists' role repertoire [see 15]).

The usability specialists critically reviewed the educationists' design from the viewpoint of children and pointed out, based on their empirical data, many issues that should be modified to better suit the target user group, e.g.: "We are wondering here together with [another usability specialist] why the user interface for the younger age group has been done anew and our findings from last spring neglected? In the project, feedback was gathered and ideas generated based on the scenarios produced [by the educationists]. Now it seems that this feedback has been ignored but instead the work has been continued based on the own scenarios (for instance the door, house, and the pictures of (...) and (...) children have been left out ...). I would say that one should prefer already evaluated designs." (Usability specialist, email) *Briefly related to some central functional elements (...) 1) House and home in general was a central and important element for the 5 to 6 years old and it should be kept in the main menu. (...) The [tutor] should also be kept in the same place, for instance in the upper right corner. (...) the same place in every screen was found to be good for 5 to 6 years old in the prototyping; (...)" (Usability specialist, email)

Related to many of the suggestions, the educationists made changes to their design documents. However, this did not happen related to all suggestions, instead the educationists referred to certain project goals or to their authority to settle the educational aspects when keeping certain issues as they were. The educationists and the usability specialists sent their design documents to each other and exchanged numerous emails on the matter. In addition, the usability specialists created a document called a List of concerns, in which they in a table format listed all the problems they identified from the educationists' design. In addition to the issues that according to the usability specialists were to be changed in the educationists' design due to their user data, the usability specialists also identified unclear or inconsistent issues from
the document. Afterwards, the educationists made some changes to their designs, but ignored other issues. They listed their responses in the List of concerns document, pointing out what they had changed, what they hadn't changed and reasons for the decisions, marking their response in a different font color.

The developers also received the usability specialists' requirement and design documents. The developers seemed to value those, especially some documents that were produced before creating the formal project deliverables on the matter. An informal Usability Requirement document, which the usability specialists started by graphically outlining the possible use cases of the application, was thanked: "*UI group requirements will be sent later (remark: [a usability specialist] sent within [software requirements] writing process ...), extremely helpful for getting use cases).*" (Developer, memo) In addition, a developer reminded other project parties related to the initial Usability Design document: "*[A usability specialist's] students have sketched quite detailed design for [parts of the application]. It is based on your scenarios and have been usability tested (paper prototyping) with 5-6 years old children. The student group has made magnificent work! (...) I hope you can continue from that. (Just to remind to make sure that you are not doing overlapping work)*" (Developer, email) The developers were not very happy with the adopted waterfall development model but instead relied on the development of prototypes, into which they integrated the usability specialists design as soon as it was sent: "*The project is following waterfall model where only one cycle from requirements analysis to design, to implementation, and finally to testing and experimenting is done. (...) Thus, our process is far from ideal in a research project where results are unclear beforehand. (...) We have tried to overcome this limitation by using different process and schedule internally (...)*. For example, we have already built prototypes and framework for (...) user interface, and produced an initial user interface design. We will then modify those according to the requirements and design when the corresponding documents are ready.*" (Developer, email) Thus, the usability specialists' initial usability design became implemented very fast into the developers' prototypes.

## 4.2 Usability Specialists Facilitating Shared Understandings in the Design Team

The usability specialists also facilitated shared understandings among the design team during some occasions. For instance, in a situation in which a developer needed to know the maximum amount of files a child should be able to save during a use session, first an educationist replied, giving the answer from the perspective of educational science research, but also indicating that the question actually belongs to the field of the usability specialists. A usability specialist replied, indicating that studies with children should be carried out to be able to answer the question, but offering still some initial guesses. On the other hand, she also indicated that there is not only the question related to the amount of files to be saved, but also a question of versions as the idea was that children should be able to share files as well as to continuously update them. The question of how to represent these versions to children should be considered. Additionally, she pointed out that handling this could be a nightmare for devel-
opers but anyway this was a logical problem that had to be solved. Here, the usability specialist reflects on her knowledge gained through working with children as well as indicates how these kinds of questions are dealt with by usability specialists, i.e. by empirically inquiring them. Interesting is that the usability specialist also started to consider the question from the viewpoint of versions and even from the viewpoint of coding – clearly indicating she had some understanding also of the developers’ practice, not only of that of HCI.

Another case during which the usability specialists were acting as facilitators be-
tween the worlds of developers and educationists was when producing software re-
quirements. There was a formal project deliverable related to which extensive collab-
oration between the project parties and different disciplines was expected. One educa-
tionist was, though, positioned as responsible for this deliverable. However, it was
very difficult for her to gain input for this document from the project partners. The
educationist sent numerous emails requesting other parties to contribute. Finally, oth-
er educationists sent some user characteristics descriptions, asking: “I am very unsure
what else you need. Could you please specify?” (Educationist, email) A developer
informed her: “There are no requirements at the moment. So, we know who our users
are, but not what to do with them or for them. (...) The document should be such that
it could be given to a person who has not participated in the project and he could
start to design or implement the (...) functionality based on the detailed requirement
descriptions.” (Developer, email) The educationists were expected to produce the
main part of the document, i.e. the functional requirements. They had created their
Educational Requirements deliverable and also an early version of Usability Re-
quirements document sent by a usability specialist was available. In addition, the
educationists had a template provided by the developers, even though the developers
criticized the template as being too formal for the purposes of this kind of a research
project and warned of not producing useless content just for the sake of it: “I was not
sure if that level of formality was needed in a research project (...) I have suggested
that the sections with non-relevant information and empty content (mainly those non-
functional requirements) can be omitted. (...) I see no practical reason to generate
dummy content if it does not serve research purposes.” (Developer, email)

The educationists, based on the information presented above, specified the re-
quirements and sent the document to the other project partners to comment. At this
point of time a usability specialist critically reviewed the document. She pointed out
that the document confused design solutions with software requirements as well as
missed some things that are usually included in software requirements documents.
There emerged a lengthy discussion between the project partners concerning this mat-
ter, the educationists pointing out that they were not educated for creating this kind of
documents. The developers criticized the division of work that had led to this situa-
tion; all project parties agreeing that the division of work should have had been dif-
ferent: "So, the deliverables were originally meant to be written by non-software
professionals/researchers. We (SW persons) have participated in many video confer-
ences and physical meetings where the requirements were discussed. However, it was
not exactly clear to us what non-software people really wanted software to do, nor we
had enough time to decipher that." (Developer, email). A usability specialist offered
to go through the document with her team and to improve it. The project participants
happily accepted the offer: "*The project plan (...) was as argued by [a developer], mostly constructed by non-software focused people, who created the entire research idea. We [the educationists] only had some tiny little background experience on developing the (...) application. We were not familiar enough what a project like this could bring in front of our eyes. (...) [The usability specialists] are working on [the software requirements document] and trying to find a consensus with [the educationists] in the software requirements*" (Educationist, email). At this time, the educationists thanked the usability specialists as a highly useful "*link*" between them and the developers. The usability specialists later delivered the Software Requirements Specification document for other parties to review. The educationists went through the revised document and modified it further. Also a developer commented on some requirements and priorities. Afterwards, the educationists informed that they had checked the priority ratings when finalizing the document. All in all, this incidence again shows that the usability specialists possessed not only understanding of HCI, but also of software engineering and through their work, they clearly helped the design team to move towards a shared understanding of the software requirements.

# 5 Discussing the Conditions for Successful Boundary Spanning

The framework utilized in this paper maintains that to be able to successfully span the boundaries between diverse organizations and areas of expertise, there needs to be people acting as boundary spanners as well as common, shared objects acting as boundary objects [22]. Two forms of successful boundary spanning were identified from the case: 1) the usability specialists informing the educationists and the developers about their user data and succeeding in impacting the actual application design, there emerging a new joint field of practice between the usability specialists and the educationists or between the usability specialists and the developers, within which these experts could share knowledge and arrive at shared understandings about the appropriate application design; 2) the usability specialists facilitating shared understandings among the design team, all parties taking part within the new joint field of practice within which they could arrive at a shared understanding of the software requirements. In both cases a new joint field of practice emerged for the usability specialists, educationists and developers, but not involving the children. All these instances involved also the use of certain kinds of objects that succeeded at least partially to act as boundary objects that gained local usefulness from the viewpoint of each involved practice and that ultimately succeeded in transferring knowledge across the boundaries. Next, the findings of this study are discussed in relation to the conditions of successful boundary spanning as described by Levina and Vaast [22].

1) **Gaining at least a peripheral understanding of each involved practice;** This refers to the usual usability specialists' activity involving field studies and empirical evaluations together with the actual or potential users. In this case, the usability specialists interviewed and observed children, carried out different kinds of empirical evaluation sessions as well as organized several design sessions. Through all this
work, one can say that the usability specialists likely gained at least a peripheral un-
derstanding of children: their needs, skills and preferences relevant from the view-
point of the forthcoming application. On the other hand, the usability specialists also
succeeded in showing that they possessed some IT skills and education, as they indi-
cated of knowing how software development ought to proceed with associated docu-
ments (use cases. software requirements) as well as what is involved in designing
software (cf. the versioning problem). This likely has happened already though their
education, as usability specialists are many times educated in some sort of an IT de-
partment that includes also other courses than HCI. This enables the usability special-
ists to have at least a peripheral understanding of the practice of the developers, too.

The educationists were likely the most exotic group for the usability specialists in
this project but no specific effort was placed on understanding their practice. Of
course, some insights were gained almost naturally during the whole year of collabo-
ration. The educationists sent the educational requirements material and wishes for
the usability specialists' empirical work with children soon after the project started.
Later on, more formal Educational Requirements and Design documents were sent
and through those the usability specialists could again educate themselves. However,
if aiming at adopting the boundary spanner position in multiparty IT development
efforts, this is one place for the usability specialists to improve their practice: to con-
sciously try to gain at least a peripheral understanding of each involved practice, not
only of that of the users, straightaway when the collaboration is to begin.

2) **Gaining legitimacy as negotiators on behalf of the fields whose interests they are trying to represent:** The main responsibility of the usability specialists is to 'represent the users', the ignored group in systems development and computer science [9]. However, related to 'representing the users' there is a wide-spread problem of usability specialists not having any actual legitimacy to act as these 'representatives', as users usually are not even aware that there is this kind of a specialists group in the development speaking on behalf of them [16]. This applies especially in the product development context, in which users are not working inside the same organization or inside a specific customer organization for which the solution is developed; in these cases users might even be aware of usability specialists and their representation work. In the case examined in this paper the children did not see the usability specialists as their representatives in the development, as this would have involved an explicit effort of informing the children of that matter that did not happen. Moreover, the developers and the educationists were not informed of the position of the usability specialists as boundary spanners either, due to which the developers or the educationists unlikely viewed the usability specialists as negotiators trying to represent their interests. On the other hand, the educationists independently pointed out that the usability specialists were equipped to act as a link between them and the developers that indicates that this kind of role was still given to the usability specialists, therefore granting some legitimacy to their work, nevertheless. Despite that, more explicit positioning into this role is needed. Usability specialists should also become better informed of those whose needs they are to represent and on behalf of whom they are to speak.

3) **Transforming their own practices so that they accommodate the interests of the other fields;** The usability specialists have a repertoire of usability methods to use
when carrying out their work. Related to children, there also is a body of work pub-
lished on the matter [see e.g. 10, 24]. Related to working with children, furthermore,
the usability specialists placed extra effort on finding suitable ways of engaging the
children and for creating a nice atmosphere for the joint sessions. Likely this contrib-
uted to the success of the design and evaluation sessions in which valuable feedback,
insights and design ideas were gained concerning children and the application. On the
other hand, the usability specialists seemingly also tried to please the developers, e.g.
through including some notations widely used by the developers (i.e. the use cases).
No specific evidence related to the usability specialists trying to transform their own
practice to better suit the interests of the educationists was encountered, however, if
not counting the educationists being allowed to express wishes for the empirical work
to be carried out by the usability specialists with the children.

4) **Producing boundary objects, which need to gain local usefulness and identity from the viewpoint of each involved practice;** In this case there were some objects used that can be argued of having gained local usefulness and common identity from the viewpoint of several parties. These objects were the Usability Requirements and Usability Design documents, the List of concerns created related to the conflicting designs produced, some emails negotiating the conflicting designs and the Software Requirements Specification document. The Usability Requirements and Usability Design documents were thanked by the developers as providing useful information. It might be that especially the use cases presented in the Usability Requirements document helped the developers in their work and made them to thank the usability specialists' documentation. On the other hand, the Usability Design document, describing the screen contents, available functions, possible user actions and system responses, enabled the developers to finalize their early prototypes and for that reason proved out to be highly useful as well. At that point the developers, due to their preference on early prototyping and iteration, needed as exact specifications as possible and the usability specialists succeed in providing such during a convenient time. The design documents provided by the educationists and the usability specialists later on contained the same information, while they were delivered too late from the viewpoint of the prototype development. In addition, the Educational Design document; even though very extensive description was not very exact on all details that might have made it less useful for the developers. All in all, one can conclude that the quite traditional usability specialists' documents were appreciated in this case by the developers. The results are also in line with studies that argue that the developers value redesign proposals and elaborate problem descriptions [14], even though in this study the documents did not only present usability problems and their redesign proposals, but also totally new requirements and designs. Nevertheless, the design provided by the usability specialists was very concrete and directly utilizable by the developers, which has been reported of being valued by developers [14]. In more theoretical terms one can argue that these boundary objects succeeded in transforming design knowledge between two different worlds and mobilized for design action, i.e. they enabled the developers to progress along the design path [see 23].

The educationists and the usability specialists did not utilize each other’s documen-
tation as should have been the case. When finalizing their design documents, both
parties mentioned that there might be some overlap between these design documents. It seems that those documents were mainly used for legitimizing the design knowledge of the each party [see 23], not for creating shared understandings. These design documents therefore cannot be conceptualized as boundary objects transferring knowledge between these two practices, while one can say that the detailed emails on the matter and the List of Concerns document that both parties modified acted as such and enabled negotiating the design on a detailed level. In both cases, the descriptions were sent back and forth, each party adding comments and modifying text. These very mundane and rather dry and abstract textual descriptions served as boundary objects in this case. They enabled negotiating the designs at detailed level and exchanging opinions before reaching a consensus. They evidently allowed finding a common language across these different social worlds as well as acceptable common solutions [see 23]. These kinds of mundane tools, e.g. email messages and word processing software documents with tables and multiple font colors, were successful in this multiparty design effort. The main requirements for such boundary objects may be easy modifiability and support for negotiations involving multiple voices. The lack of context in these descriptions necessitated, however, more lengthy descriptions that would have been the case if the comments had been added to the design documents itself. Additionally, numerous advanced groupware systems would have been available to support this task, but were not considered in this project.

The Software Requirements Specification document, furthermore, enables an interesting analysis of the collaboration between these three parties. One of the usability specialists critically reviewed the document, pointing out many unclear issues, controversies as well as design solutions that should have been avoided at this point of time. The usability specialist also revised the document. At this point the position of the usability specialists as a link between the developers and the educationists was pointed out. Afterwards, the educationists critically reviewed the document and made their own modifications, not accepting all suggested by the usability specialists. In addition, the developers entered the discussion by requesting prioritization of the requirements and some progress was also achieved. While the template for software requirements specification as such was not perfect and a software requirements specification document, altogether, is not recommended to be used as a boundary object in multiparty projects, it, and maybe its limitations as well, enabled the usability specialists to acquire the facilitator position in the project, translating the educationists' ideas into more formal language and at the same enabling the developers to relate the descriptions more easily to their own specifications. A joint effort relating to defining the requirements is suggested also for other multiparty efforts, while there clearly is a need for boundary spanners, be they usability specialists or other kind of experts, to create a joint field of practice within which different parties can express themselves in their own language while at the same time somehow make their language, or at least allow others to transform their language, understandable to the other parties. In this kind of a situation a facilitator is needed to make sense of the requirements and to enable the different parties to comment on and to negotiate further the requirements. The boundary objects supporting this work would thus need to promote shared repre-
sentational means among the participants and to transform diverse design knowledge
towards a common solution [see 23].

6 Conclusions

This paper empirically examined what kinds of roles usability specialists adopt in
multiparty, distributed IT development setting sand contrasted the empirical findings
with the existing research on the suitable roles for usability specialists to take in the
development and with the theoretical framework on boundary spanning [22] that out-
lines the conditions for successful knowledge sharing and arriving at shared under-
standings in collaborative settings involving numerous organizations, disciplines,
areas of expertise and nationalities [5, 19, 21, 22], and maybe even generations [10].
The paper argues for HCI research to acknowledge that it would be useful for usabil-
ity specialists to view themselves as boundary spanners, facilitating knowledge shar-
ing and arriving at mutual understanding among multiparty design teams, involving at
least users and developers in addition to usability specialists, as well as possibly sales,
marketing, management and documentation [2, 4, 7, 8, 13, 15, 16, 25, 28] and perhaps
even numerous other areas of expertise, disciplines, nationalities and generations [5,
10, 19, 20, 21, 22, 24, 26].

Theoretically, this paper shed light on the role repertoire usability specialists rely
on in IT development. Findings from knowledge management research were utilized
for scrutinizing and enriching the usability specialists’ role repertoire. The data
showed that the informative, consultative, participative and designer roles were all
adopted by the usability specialists in the case project [in line with e.g. 3, 13, 15, 16].
The usability specialists were providing information about users based on their empir-
ical work with children and on their general state-of-the-art HCI knowledge, as well
as offering both empirical user feedback and feedback based on their expert evalua-
tions [see 15]. They were also allowed to produce their Usability Design, offering
them the designer position, while the later negotiations with the educationists settled
them more into the participative role, acting as active participants, having some deci-
sion making power among other design team members [see 15]. Regarding the facili-
tator role, furthermore, even though the usability specialists were not orchestrating
joint design sessions in which the developers and the educationists collaborated with
the children [see 4, 7, 13], they nevertheless facilitated collaboration inside the design
team including themselves, the developers and the educationists.

In this case the novel aspect is related particularly to this: to the ways the usability
specialists contributed inside the design team. The analysis offers insights on how to
develop the facilitator role of usability specialists further to enable usability special-
ists to act as usability evangelists and advocates inside their organization [e.g. 1, 2, 8,
13, 15, 16, 25, 37]. Although the whole HCI practice of ‘representing the user’ can be
considered as a mediating practice between design and use [17, 30] and along these
line the HCI methods as mediating information between divergent worlds, the frame-
work of boundary spanning contributes by targeting the focus on the design team
members as well as by requiring the objects and methods used to be modified to suit
the needs and interests of the particular groups with whom the usability specialists are to collaborate. Moreover, the importance of gaining legitimacy as a representative of the other parties as well as truly advocating the interests of all these other parties were brought up. The usability specialists in this case did not try to represent the interests of the educationists. They were thus acting as *user advocates* [cf. 13], speaking on behalf of the users to the developers and the educationists, as well as *developer advocates*, speaking on behalf of the developers to the educationists, but it seems that they did not try to gain a peripheral understanding of the practice or to change their methods or tools to accommodate the interests of the educationists [cf. 22]. If the usability specialists were to acquire this position, they should, nevertheless, try take into account and negotiate on behalf of all the involved parties. Furthermore, gaining legitimacy as a representative of all the involved parties should be sought for.

The boundary objects identified in this case were of various kinds. The Usability Requirements and Usability Design documents thanked by the developers likely provided something concrete enough at a convenient time [cf. 14], transforming design knowledge between different social worlds and mobilizing design action [cf. 23]. The same documents, however, did not work for coordinating the efforts of the educationists and the usability specialists, in which case they seemed mainly to be used for legitimizing the design knowledge of each party instead [cf. 23]. On the other hand, plain emails and word documents sent as email attachments and stored in the shared data repository served a successful boundary objects through the use of which the parties negotiated a shared understanding of the appropriate application design. The Software Requirements Specification and the work involved in its creation also succeeded in creating a joint field of practice within which a mutual understanding of the functional requirements for the application could be reached. These very dry and abstract descriptions and the distributed way of working relying very heavily on email succeeded in serving the purpose. However, HCI research could figure out more appropriate tools for boundary spanning work, this including likely not only documentation support but some procedures for their production as well.

The boundary spanner position should be valuable for practitioners working as usability specialists in industry. This role could be utilized in multiparty, distributed and global development efforts where people representing numerous fields of expertise, organizations, nationalities or generations should together contribute to a common goal. In such cases the usability experts could consider how they could gain at least a peripheral understanding of each involved practice, not only of that of users. In addition, they could try to gain legitimacy as negotiators of the other parties' interests. Moreover, they could consider how they could transform their own practice so that it better accommodates the interests of the other involved practices. Finally, they could consider their work objects as potential boundary objects that should gain local usefulness and identity from the viewpoint of the other parties involved.

There are some limitations concerning the results. Those have been gained only from one case that is very specific in many ways. More cases should be included in the analysis. This case was a research project, while industrial cases would enrich the analysis. This analysis also considered distributed design. Face-to-face setting would offer additional opportunities for the usability specialists to accomplish the job of a
boundary spanner. Another area of future work would be to devise novel or enhanced methods and tools for usability specialists acquiring this position

## Acknowledgements

I would like to thank all the project participants, including the children. This research has been funded by the Academy of Finland and EU.

## References

1. Barcellini, F., Detienne, F., Burkhardt, J.: Participation in online interaction spaces: Design-use mediation in an Open Source Software community. International Journal of Industrial Ergonomics 39, 533--540 (2009)

2. Bloomer, S., Croft, R.: Pitching Usability to Your Organization. Interactions 4(6), 18--26 (1997)

3. Boivie, I., Gulliksen, J., Göransson, B.: The lonesome cowboy: a study of the usability designer role in systems development. Interacting with Computers 18(4), 601--634 (2006)

4. Borgholm, T., Madsen, K.: Cooperative Usability Practices. Communications of the ACM 42(5), 91--97 (1999)

5. Boujut, J., Blanco, E.: Intermediary Objects as a Means to Foster Co-operation in Engineering Design, Computer Supported Cooperative Work 2, 205--219 (2003)

6. Bygstad, B., Ghinea, G., Brevik, E.: Software development methods and usability: Perspectives from a survey in the software industry in Norway. Interacting with Computers 20(3), 375--385 (2008)

7. Bødker, S., Buur, J.: The Design Collaboratorium – a Place for Usability Design. ACM Transactions on Computer-Human Interaction 9(2), 152--169 (2002)

8. Cooper, A.: The inmates are running the asylum: Why high-tech products drive us crazy and how to restore the sanity. Sams, Indianapolis (1999)

9. Cooper, C., Bowers, J.: Representing the users: Notes on the disciplinary rhetoric of human-computer interaction. In: Thomas, P. (ed.): the Social and Interactional Dimensions of Human-Computer Interfaces, pp. 48--66. Cambridge University Press, Cambridge (1995)

10. Druin, A.: The Role of Children in the Design of New Technology. Behaviour and Information Technology, 21(1), 1--25 (2002)

11. Druin, A., Stewart, J., Proft, D., Bederson, B., Hollan, J.: KidPad: a design collaboration between children, technologists, and educators. In: Proceedings of the SIGCHI conference on Human factors in computing systems, pp. 463--470. ACM, New York (1997)

12. Følstad, A., Bark, I., Gulliksen, J.: How HCI-practitioners want to evaluate their own practice. In: Morch, A., Morgan, K., Bratteig, T., Ghosh, G., Svanaes, D. (eds.): Proceedings of the fourth Nordic Conference on Human Computer Interaction, pp. 417--420. ACM, New York (2006)

13. Gulliksen, J., Boivie, I., Göransson, B.: Usability professionals – current practices and future development. Interacting with Computers 18(4), 568-600 (2006)

14. Hornbæk, K., Frøkjær, E.: Comparing usability problems and redesign proposals as input to practical systems development. In: Proceedings of the SIGCHI conference on Human factors in computing systems, pp. 391--400. ACM, New York (2005)
15. Iivari, N.: Understanding the Work of an HCI Practitioner. In: Morch, A., Morgan, K., Bratteig, T., Ghosh, G., Svanaes, D. (eds.): Proceedings of the fourth Nordic Conference on Human Computer Interaction, pp. 185--194. ACM, New York (2006)

16. Iivari, N.: Culturally Compatible Usability Work - An Interpretive Case Study on the Relationship between Usability Work and Its Cultural Context in Software Product Development Organizations. Journal of Organizational and End User Computing 22(3), 40--65 (2010)

17. Iivari, N., Karasti, H., Molin-Juustila, T., Salmela, S., Syrjänen, A.—L., Halkola, E.: Mediation between design and use – revisiting five empirical studies. Human IT – Journal for Information Technology Studies as a Human Science 10(2), 81–126 (2009)

18. Klein, H., Myers, M.: A Set of Principles for Conducting and Evaluating Interpretive Field Studies in Information Systems. MIS Quarterly 23(1), 67--94 (1999)

19. Lawrence, K.: Walking the Tightrope: The Balancing Acts of a Large e-Research Project. Computer Supported Cooperative Work 15(4), 385--411 (2006)

20. Lee, C.: Boundary Negotiating Artifacts: Unbinding the Routine of Boundary Objects and Embracing Chaos in Collaborative Work. Computer Supported Cooperative Work 16(3), 307--339 (2007)

21. Levina, N.: Collaborating on Multiparty Information Systems Development Projects: A collective Reflection-in-Action View. Information Systems Research 16(2), 109--130 (2006)

22. Levina, N., Vaast, E.: The Emergence of Boundary Spanning Competence in Practice: Implications for Implementation and Use of Information Systems. MIS Quarterly 29(2), 335--363 (2005)

23. Mark, G., Lyytinen, K., Bergman, M.: Boundary Objects in Design: An Ecological View of Design Artifacts. Journal of Association for Information Systems 8(11), 546--568 (2007)

24. Markopoulos, P., Read, J., MacFarlane, S., Höysniemi, J.: Evaluating Children's Interactive Products: Principles and Practices for Interaction Designers. Morgan Kaufmann Publishers Inc., San Francisco (2008)

25. Mayhew, D.: The usability engineering lifecycle: a practitioner's handbook for user interface design. Morgan Kaufmann Publishers, Inc., San Francisco (1999)

26. Nichols, D., Twidale, M.: Usability Processes in Open Source Projects. Software Process Improvement and Practice 11, 149--162 (2006)

27. Rajanen, M., Iivari, N., Anttila, K.: Introducing Usability Activities into Open Source Software Development Projects – Searching for a Suitable Approach. Journal of Information Technology Theory and Application 12(4), 5--26 (2011)

28. Rosenbaum, S., Rohn, J., Humburg, J.: A Toolkit for Strategic Usability: Results from Workshops, Panels, and Surveys. In: Proceedings of the Conference on Human Factors in Computing Systems, pp. 337--344. ACM: New York (2000)

29. Star, S., Griesemer, J.: Institutional Ecology, ‘Translations’ and Boundary Objects: Amateurs and Professionals in Berkeley’s Museum of Vertebrate Zoology, 1907-39. Social Studies of Science 19, 387--420 (1989)

30. Tuovila, S., Iivari, N.: Bridge Builders in IT Artifact Development. In: Österle, H., Schelp, J., Winter, R. (eds.): Proceedings of the 15th European Conference on Information Systems, 819-830 (2007)

31. Walsham, G.: Interpretive case studies in IS research: nature and method. European Journal of Information Systems 4(2), 74-81 (1995)