# Examining Usability Work and Culture in OSS

Mikko Rajanen, Netta Iivari

► To cite this version:

Mikko Rajanen, Netta Iivari. Examining Usability Work and Culture in OSS. 11th International Conference on Open Source Systems (OSS), May 2015, Florence, Italy. pp.58-67, 10.1007/978-3-319-17837-0_6. hal-01320160

HAL Id: hal-01320160

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

Submitted on 23 May 2016

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
# Examining Usability Work and Culture in OSS

Mikko Rajanen and Netta Iivari

Department of Information Processing Science, University of Oulu
{mikko.rajanen, netta.iivari}@oulu.fi

**Abstract.** Organizational culture has been recognized as an influential factor affecting the successes and failures of usability work in organizations; however, there is a lack of research on organizational culture in open source software (OSS) development. This paper shows that there are different kinds of cultures in OSS development projects and builds propositions on the relationship between culture and usability work in OSS development projects. Partly those are derived from the literature, partly from an exploratory empirical inquiry. We speculate whether there is an ideal culture type for usability work in OSS development or whether usability work should be modified to fit the different cultures of OSS development projects.

**Keywords.** Open source software, usability, culture, empirical study

## 1 Introduction

This paper examines usability work and organizational culture in the context of open source software (OSS) development. Usability work includes usability activities relating to analysis, design and evaluation that aim at making systems and products usable (e.g. [1,2,3,4]). The introduction of usability work into software development in general (e.g. [1,2]) and OSS development in particular [3,5,6,7,8,9] is challenging. In OSS projects usability has traditionally been neglected, as OSS developers have traditionally “scratched their own itch” and usability in the sense of ease of use has not been a major concern. Yet, nowadays many OSS solutions have attracted a large amount of users who do not want to participate in OSS development, but only to use the OSS. Thus, usability of OSS and usability work in OSS development have become crucial.

This paper argues that there are different kinds of cultures in OSS development projects as well as stipulates the role culture may play in the introduction of usability work into OSS development. The influence of organizational culture on usability work has been brought up in the literature (e.g. [1,2,11,12,13]). It has been argued that usability work should be compatible with the organizational culture in order to succeed [1,2,9,10,13]. As to OSS development, however, literature on the matter is very scarce. It has been brought up that OSS development projects have different kinds of cultures [6], OSS development culture may be in conflict with usability work
[6,7,8] and usability activities should be tailored to fit the OSS development philosophy and culture [7,8,10]. Yet, no empirical research has been reported.

This paper initially inquires the cultural context of OSS development projects and speculates on the relationship between usability work and culture in OSS development. Culture (as defined in section 2) is approached here through the lens of the competing values model that is a widely used model for culture studies (e.g. [1,14]). Although the model has originally been developed for explaining differences in the organizational effectiveness literature [15], the value orientations in the model seem relevant also in OSS development. Moreover, the model has already been applied in related research on usability work in commercial software development [1]. The paper reports some exploratory research findings gained during a research program where attempts for introducing usability work into OSS development have been organized. Four OSS case projects are discussed in this paper.

This paper is structured as follows. The next section addresses the concept of culture and reviews related research addressing the relationship between usability work and culture. The third section presents the research method used in the empirical studies and the empirical results. The last section discusses the implications of the findings as well as their limitations and paths for future work.

## 2 Literature review

Culture has been the topic of study within numerous disciplines, while in cultural anthropology it has been the main focus. The discipline studies humans as cultural beings, assuming that ‘man is a symbolizing, conceptualizing, meaning-seeking animal’ [16]. Although there are several hundred definitions of culture within the discipline, some are more prominent than others. A famous definition by Geertz is the following: “Man is an animal suspended in webs of significance he himself has spun, I take culture to be those webs, and the analysis of it to be therefore not an experimental science in search of law but an interpretive one in search of meaning” [16]. Later on, the study of culture has spread to different disciplines; including also Information Technology (IT) related disciplines. Some studies have even addressed the relationship between usability work and organizational culture.

In such studies, one can identify two strands: studies discussing the relationship between ‘usability work and engineering culture’ and studies discussing the relationship between ‘usability work and a particular organizational culture’. The first strand argues that there are discrepancies between the cultures of engineers and usability professionals, and cultural change is needed for solving these discrepancies. Engineers need to cultivate their work practices [17], but also usability experts should try to think and work like engineers to minimize the problem of cultural differences [10,13]. The latter strand, on the other hand, discussing the relationship between usability work and particular organizational cultures, maintains that the introduction of usability work likely succeeds if it is customized to the existing culture as for usability work there is no ‘one size fits all’ [1,2,10]. One should understand the particular usability myths and values that define the usability culture of the organizations [11]. Obstacles
for usability include prevalent myths, attitudes, beliefs and incentives [13]. Usability
myths and values should be presented and openly discussed to succeed [11].

On the other hand, some studies do not recommend understanding the existing usability culture of the organization, but instead present ‘usability culture’ as an ideal state where to aim at [12]. ‘Strategic usability’ is presented as an ideal state that means embedding usability in the organizational processes, culture and roadmaps [18]. ‘Full scale usability’ involves a major cultural transformation for an organization and a paradigm shift for practitioners. There is a need for a cultural change from technology and engineering centric views, but such change may cause resistance [19].

There are also studies that have shown that there are different cultures in develop-
ment organizations that may have implications on usability work [1,20]. Certain cul-
tural characteristics have been associated with certain usability work characteristics in
organizations. Four ‘usability cultures’ have been identified that do not describe ideal
situations, but current states of affairs in studied cases. The characteristics of usability
work identified seemed to be compatible with the cultural characteristics [1]. Hence,
the study recommends modifying usability work to fit the existing culture, proposing
a cultural compatibility hypothesis (see [1,2]).

Based on the literature, it seems that there may be a cultural clash or conflict be-
tween usability work and engineering culture as well as between usability work and
culture of some particular development organizations. To solve the problem of cultur-
al clash or conflict, researchers suggest that: 1) Usability work should be modified to
fit the engineering culture; 2) Usability work should be modified to fit some particular
organizational culture; 3) Engineering culture should be modified so that usability is
appreciated and ‘usability culture’ as an ideal state can be achieved; or 4) The organi-
zational culture in question should be modified so that usability is appreciated and
‘usability culture’ as an ideal state can be achieved. There is variety in the culture
conceptions in these studies as well as in the assumptions concerning the relationship
between culture and usability work. Equipped with these tools, we examine studies
addressing usability work and culture in OSS development.

Although during the past decade a huge amount of research on OSS development
has been produced, there is a lack of research addressing the cultural context of OSS
development. Nevertheless, it has been pointed out that there is variety in the OSS
development community cultures, depending on the software under development, the
size of the development community and the underlying business model [6]. However,
empirical research on culture is lacking. On the other hand, researchers have already
described the general characteristics of OSS development culture, bearing some re-
semblance with the description of engineering culture discussed earlier. OSS devel-
opment culture has been characterized by passion and technical rationality: there are
people passionate about the OSS they are developing and for them it might be diffi-
cult to empathize with users who do not have the similar level of technical knowledge
and skills [6]. In OSS development culture, the interest is in scratching one’s own itch
and in finding technical solutions; there is no particular interest in understanding ‘the
user’, but to show one’s worth in practice [7]. The culture is described as developer-
centric and merit-based that values technical skills and knowledge above all. In this
kind of a cultural context it might be difficult for usability experts to gain merit [8].
Incorporating usability into this kind of a cultural context is a challenge [5]. However, the cultural clash is not only between usability and OSS development, but between corporate usability processes and OSS development [8]: decentralized and engineering-driven OSS development does not fit very well with corporate usability processes. It is argued that usability methods should better fit this culture [8]. Usability people should understand the cultural context they are entering into. Trust building and showing merits are key concerns. Different strategies may be utilized. One may try to establish authority and trust by showing ones competence (in usability) with facts and data, or by trying to slowly integrate into the community [6].

This paper characterizes particular OSS development projects from the viewpoint of usability work and the cultural context and offers some initial propositions on the relationship between usability work and the cultural context. The cultural context will be addressed by using a competing values model as a sensitizing device. The model has been widely used in exploring organizational culture in IT research (e.g. [1,14,15,21]). It categorizes cultures based on value orientations in organizations. The model includes two axes that reflect the different value orientations: change vs. stability, and internal focus vs. external focus. Change emphasizes flexibility and spontaneity, while stability emphasizes control, continuity and order. Internal focus highlights integration and maintenance of the existing system, while external focus highlights competition and interaction with the organizational environment [21]. From these two dimensions one can identify four primary types of culture: group, adhocratic, hierarchical and rational. Usually organizations have features of all of them, while one usually dominates. Within the **group culture type** the emphasis is on flexibility and internal focus. The values are the sense of belonging, trust, participation, openness, teamwork, and the sense of family. Within the **adhocracy culture type** the emphasis is also on flexibility, but with focus on external environment. The values are innovation, adaptation, creativity, growth, resource acquisition, and dynamism. Within the **hierarchical culture type** the emphasis is on control and internal focus. Coordination, stability, measurement, documentation, order and smooth operation are valued. Finally, within the **rational culture type** the emphasis is on control and external orientation. Planning, goal setting, efficiency, productivity, competitiveness and market superiority are valued. The competing values model was utilized to make sense of the cultural contexts of the involved case OSS projects. The model provided us a concrete typology to be used in the venture related to which no existing research was found.

# 3 Research Design and Empirical Insights

This research is part of a larger research program, started in 2007, in which suitable methods and models for introducing usability work into OSS development have been developed and experimented with. This research program follows the design science approach, which is about building artefacts for specific purposes and about evaluating how well they perform for their intended purposes [22]. The artefacts have been methods for introducing usability work into OSS development. They have been iteratively improved through experimenting with them in real-life OSS development pro-
jects. During such experimentation, material also for this paper has been collected. The research program comprises 13 usability case projects in the OSS development context between years 2007 and 2014. Four cases were selected for this paper: they characterize clearly the differences between OSS project cultures among the 13 OSS case projects.

In this paper, OSS development cultures and usability work are studied in four different OSS development cases. In each case, a different student team introduced usability activities into one selected OSS development project under the close supervision and guidance of the researchers, and collected data related to these usability activities and the OSS development project. These cases are reported in more detail from different theoretical viewpoints in [3,4,9]. All students had a background of multiple theoretical and practical usability courses. They acted as usability specialists in the OSS cases. Each student team consisted of three to ten students working between 200 and 300 hours each during four to six calendar months in planning and carrying out the usability activities, communicating with the OSS project, following up the impact of usability activities, collecting data, and writing project reports. The collected research material includes, e.g., community website content, version changelogs, emails, internet relay chat (IRC) logs, forum messages and reports of the usability activities. In this paper this research material is analyzed from the viewpoint of the OSS development culture and usability work. The competing values model offered a sensitizing device, focusing attention to the divergent value orientations in OSS development projects.

## 3.1 Case 1

In case 1, the usability intervention was done by a usability team of five students acting as external usability consultants (cf. [23]). The usability team kept its distance from developers and community as planned and therefore did not try to get to know this OSS project in detail before the usability activities. The usability team conducted heuristic evaluation, cognitive walkthrough and usability testing for the OSS and reported the findings in a report that was sent to the core developers and mentioned in a forum post at the main discussion forum of the community. The developers acknowledged receiving the report and said that they would respond when they had discussed it internally. After three years, no contact by the developers has been made, the identified usability problems have not been fixed and there has not been discussion about any usability related user interface changes in the forums.

In general, this OSS development community did not have a rigid hierarchical structure. The core developers were easily accessible by the usability team, which was indicated by the discussion forums and the IRC channel logs. Moreover, based on the discussions in the communication channels such as email lists, discussion forums and IRC channels of the project, the community and the developers seemed to be quite open to new ideas, new features, and improvements, but only as long as they were suggested by someone who was already recognized as merited by the community. Neither the community nor the core developers were really interested in an external group of usability contributors even though they were open to new ideas from within
their own community. This was again indicated by the emails and IRC messages be-
tween the developers and the usability team. Altogether, the general mindset among
the developers was not very encouraging for usability: the suggested usability im-
provements in the forums by users had been frequently shot down by the developers
as being either irrelevant or a subjective matter of taste. Altogether, based on this
evidence, we suggest that this OSS development project shares similar features espe-
cially with the group culture type in the competing values model, with emphasis on
flexibility and internal focus [21].

3.2 Case 2

Given the failure of introducing usability activities into an OSS project by following a
traditional external usability consultant approach in case 1, in case 2, the researchers
tried a new approach by getting the student team into a position of an internal usabil-
ity team. In case 2, the usability team consisted of three students who followed the
OSS project's IRC channels and discussion forums for some time and tried to get to
know the ways of the project (e.g. how to communicate appropriately in the project's
IRC channel and discussion forums, what were the development practices of this OSS
project, who would be the best developer to contact regarding usability issues etc.)
before letting themselves and their intentions known. According to initial observa-
tions collected by the team, the OSS case 2 project had no prior knowledge or training
about usability. The usability team contacted the core developers and established
contact with the lead developer. The usability team tutored the lead developer about
the concept of usability and offered their assistance to all things related to usability,
trying to get a legitimate position within the OSS project. The lead developer got
interested in the possible benefits of better usability and identified several possible
areas for usability evaluation. The usability team performed heuristic evaluation and
usability testing for the OSS and was in close contact with the lead developer regard-
ing their findings and possible redesign solutions, and also participated in discussions
in the project's IRC channel. After the evaluations, the usability team wrote a report
of the usability issues, which included also their suggestions for changes to fix the
usability problems. This time the work of the usability team had an impact. The core
developers included the suggestions of the usability team as part of the changes to be
made to the next version of the OSS and also fixed them in the next version. The core
developers also contacted the usability team later, asking for a new usability evalua-
tion for the next version.

The OSS community seemed to have a loose hierarchical structure, which was in-
dicated by discussion forum and IRC channel messages. The core developers were
easy to contact. They were interested in usability contributions and gave a warm wel-
come to the usability team even though they were not at first certain what usability
was, which was indicated by the IRC and email messages between the developers and
the usability contributors. In general, the community and the developers welcomed
everybody willing to contribute towards the common goal of the community in any
way, which was indicated by the welcoming attitude in the discussion forum and the
IRC messages. Therefore, based on the evidence collected, we suggest that this OSS
development project shares similar features especially with the adhocratic culture type in the competing values model, with emphasis on flexibility and external focus [21].

### 3.3 Case 3

In case 3, a usability team of ten students started by searching and following multiple communication channels of an OSS project for a couple of weeks, in order to get to know the proper ways of communicating in these channels, the use of community specific terminology, the development practices, and the already raised and discussed usability issues. The usability team tried to gain a legitimate position by contacting the core developers and offering their usability expertise for a particular area of the software, which had already raised some discussion as regards the complicated user interface and the difficulties in use. Extensive usability testing and heuristic analysis were performed. The usability team wrote several reports about usability problems and their suggestions for changes to the user interface to fix these issues. These reports were put available on the usability team's blog and advertised in the project's IRC channels and discussion forums. The usability team informed the core developers and the community through IRC and discussion forums about the future usability activities, the usability reports and the redesign mock-ups. The reactions within the core developers and the community were varied; one core developer was very supportive for the usability activities while the other core developers and the community ignored the usability team and the usability discussion it tried to raise. The suggested changes to the user interface have not been made.

This OSS development community had a rigid, multilayered hierarchical structure and the leading core developer acted as the benevolent dictator, who communicated mainly with his trusted core developers, which was indicated by the community website and the lack of direct communication channels to the leading core developer. Hence, the leading core developer was inaccessible to the usability team. In this kind of OSS development community it may take a lot of time and effort to gain merit and access to the inner onion layers of the project. This likely applies to usability specialists, too. The evidence also indicates that this OSS development community was not very open to new ideas, especially to those proposed by outsiders: the discussions within this community showed that the core developers and the community in general had rejected many usability and user interface improvements and had firm ideas on those matters by themselves. Thus, based on the evidence collected, we suggest that this OSS development project shares similar features especially with the hierarchical culture type in the competing values model, with emphasis on control and internal focus [21].

### 3.4 Case 4

In case 4, similarly with cases 2 and 3, a usability team of five students followed the case OSS project's IRC channels and discussion forums for some time and tried to get to know the practices of the project before introducing themselves and their intentions. The usability team conducted heuristic evaluation and usability testing. The
usability team wrote a preliminary and final usability reports about the usability issues and their suggestions for changes to fix them. The preliminary usability report, delivered to the project's mailing list, resulted in active discussion and lots of interest. The final usability report was delivered to the wiki of the OSS project, where the developers commented it actively. In addition, the usability team also submitted code patches and level design work, including new user interface menus and a new tutorial for the OSS. These were also received positively and they were accepted into the code repository. Moreover, the work of the usability team was referenced in several commit messages and one commit message asked explicitly for input from the usability team. Furthermore, one of the members of the usability team was invited to the development team and given commit rights as a result of his work in the usability team, his contributions to the code and discussions, and his recognized skills as a user of the OSS.

This OSS community had the traditional onion style hierarchical structure, but the culture of the community was open for new ideas and innovations. The development team of this OSS project was a tight group, who promoted into their team only those contributors who had contributed high level code, bug fixes or designs for a long period of time and whose ideas were in line with the design philosophy of the developers and the community. The development team made all decisions after lengthy discussions, trying to achieve a consensus. The core developers were easy to contact and the team was actually quite open to new members, as was indicated by the invitation of the usability team member into the development team. The core developers were also interested in the contributions of the usability team, which was indicated by the discussion forum and developer IRC channel messages. The development team encouraged the usability team to reduce all unnecessary tedious actions in the OSS to make the use better. In general, the community and the developers welcomed everybody willing to contribute towards the common goal of the community, which was again indicated by the discussion forum and the IRC channel messages of this project. Therefore, based on the evidence collected, we suggest that this OSS development project shares similar features especially with the adhocratic culture type in the competing values model, with emphasis on flexibility and external focus [21].

# 4 Concluding Discussion

There is a lack of research on culture in the OSS development context; thus, this paper contributes by offering initial insights on the matter. The literature review showed interesting distinctions in the literature. ‘Usability culture’ in an ideal sense as well as in a sense of current state of affairs was brought up. Some studies recommended changing the culture to fit usability work, while others emphasized that usability work should be modified to fit the culture in question. Initial results of our inquiry into culture and usability work in OSS development projects were presented. The competing values model was used as a sensitizing device and the four OSS case projects were classified to represent adhocratic, group or hierarchical types of culture [21]. Our usability intervention succeeded only in the OSS projects showing resemblance
with the adhocratic type of culture, while in the unsuccessful cases the culture types identified were hierarchical and group culture type. However, our results on the relationship between usability work and different culture types in OSS development projects are clearly inconclusive as there are numerous issues that may be affecting the results. Quantitative research is required for testing these initial findings.

However, one can still speculate on the relationship between usability work and culture in OSS development projects. Our findings could imply that **the adhocratic culture type is the most suitable culture type for usability work in the OSS development context.** Thus, the description of the adhocratic culture type (e.g. [21]) could offer guidelines for identifying an ideal culture type for usability work in OSS development. Then one could either target only OSS projects representing this ideal state of affairs or try to change the culture of OSS projects representing other culture types. However, criticism against this kind of conception of culture has been expressed: cultures should not be viewed as something that can be intentionally changed [1,2], probably even more so in OSS development projects than in commercial development organizations, as OSS communities usually operate on voluntary basis.

On the other hand, an alternative interpretation of the findings could be that: **when aiming at introducing usability work into OSS development; it needs to be modified to fit the culture type.** This proposition assumes that in the adhocratic culture type our approach was suitable, while for other culture types more fitting approaches need to be figured out. Along these lines, we next propose what this cultural fitting could entail for different culture types, relying on the work of Iivari [1], who has offered recommendations on how usability work could be modified to fit the different culture types. We adapt this work to suit the OSS development context and suggest that in an OSS development project: 1) With the group culture orientation, the emphasis as regards usability work should be on communal decision-making, informal information sharing, training and teamwork; 2) With the adhocracy culture orientation, the emphasis as regards usability work should be on innovation, experimentation, risk taking, supporting teamwork, brainstorming and iteration; 3) With the hierarchical culture orientation, the emphasis as regards usability work should be on careful planning and rules, procedures, control and documentation; and 4) With the rational culture orientation, the emphasis as regards usability work should be on measurement and cost benefit considerations that reveal the rationale for usability (cf. [3,4]).

In this paper, we utilized the competing values model for making sense of the cultural context of OSS development projects. Although the model has been widely used in culture studies, other models exist in the literature (e.g., Hofstede's model of culture and organizations) and other methods can be used (e.g., ethnography). As regards these four cases, it might also be considered as a limitation that the usability specialists in these cases were students. On the other hand, students from the IT field actually act as fully fledged developers in many OSS projects - students may have both development skills and time at their disposal. OSS projects usually do not prioritize formal education, but instead value the ability to contribute something useful to the project. In the described cases, the OSS developers did not see their status as students as being any kind of problem. In addition, the chosen OSS projects may affect the results of this experiment and more research is needed.
5 References

1. Iivari, N.: 'Representing the User' in Software Development - A Cultural Analysis of Usability Work in the Product Development Context. Interacting with Computers 18(4) (2006)

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

3. 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)

4. Rajanen, M., Iivari, N., Keskitalo, E.: Introducing Usability Activities into Open Source Software Development Projects: A Participative Approach. In: NordiCHI 2012 (2012)

5. Bach, P., DeLine, R., Carroll, J.: Designers Wanted: Participation and the user experience in Open Source Software Development. In Proc. CHI 2009, 985-994 (2009)

6. Bach, P., Twidale, M.: Social Participation in Open Source: What It Means for Designers. Interactions 17(3) (2010)

7. Bødker, S., Nielsen, L., Orngreen, R.: Enabling User-Centered Design Processes in Open Source Communities. In Proc. Human Computer Interaction International, 10-18 (2007)

8. Terry, M., Kay, M., Lafreniere, B.: Perceptions and Practices of Usability in the Free/Open Source Software (FOSS) Community. In Proc. CHI, 999-1008 (2010)

9. Rajanen, M., Iivari, N.: Power, Empowerment and Open Source Usability. In: CHI (2015)

10. Rajanen, M., Iivari, N.: Open Source and Human Computer Interaction Philosophies in Open Source Projects – Incompatible or Co-existent. In: Proc. Academic Mindtrek (2013)

11. Bloomer, S., Croft, R.: Pitching Usability to Your Organization, Interactions (1997)

12. Catarci, T., Matarazzo, G., Raiss, G.: Driving Usability into the Public Administration: The Italian Experience. Int'l J. of Human-Computer Studies 57 (2002)

13. Mayhew, D.: Strategic Development of Usability Engineering Function. Interactions 6:5, 27-34 (1999)

14. Leidner, D., Kayworth, T.: Review: A Review of Culture in Information Systems Research: Toward a Theory of Information Technology Culture Conflict, MIS Quarterly 30(2) (2006)

15. Quinn, R., Rohrbaugh, J.: A Spatial Model of Effectiveness Criteria. Management Science 29 (3), 363-377 (1983)

16. Geertz, C.: The Interpretation of Cultures: Selected Essays. New York: (1973)

17. Anderson, W.L., Crocca W.T.: Engineering Practice and Codevelopment of Product Prototypes. Comm. of the ACM 36(4), 49-56 (1993)

18. Rosenbaum, S., Rohn, J.A., Humburg, J.: A Toolkit for Strategic Usability: Results from Workshops, Panels, and Surveys. In Proc. CHI 2000, 337-344 (2000)

19. Hutchings, A.F., Knox, S.T.: Creating Products - Customer Demand. Comm. of the ACM 38(5), 72-80 (1995)

20. Mirel, B.: Product, Process and Profit: The Politics of Usability in a Software Venture. ACM Journal of Computer Documentation 24(4), 185-203 (2000)

21. Denison, D. R., Spreitzer, G. M.: Organizational Culture and Organizational Development: A Competitive Values Approach. Research in Org. Change and Devel. 5, 1-21 (1991)

22. Hevner, A.R., March S.T., Park, J.: Design Research in Information Systems Research. MIS Quarterly, 28:1, 75-105 (2004)

23. Schaffer, E.: Institutionalization of Usability: A Step-by-Step Guide. A-W, Boston. (2004)