You are on page 1of 8

A sceptic approach to User-Centred Design (Final Draft

Erwin Elling (0000132) ABSTRACT
As a large share of the people who write about User-Centred Design seems to consist of gurus, visionaries and other enthusiasts, the story that is preached might be a bit too optimistic. Furthermore, with only some consensus on a high, abstract level, there is a lack of agreement on what UCD exactly is, which makes the concept rather ambiguous. Simultaneously, the amount of problems faced when trying to adopt a UCD process still inhibits this philosophy from making a real stand in day to day business practice. This calls for a sceptic approach of this matter. In this paper I will show the relation between the difficulties in defining User-Centred Design and the problems in its application. I will demonstrate how the heterogeneity and the over-optimism that surround the concept lead to a detached and isolated manner of performing it. A lack of integration and context leads to what I would like to call ‘UCD Islands’, which actually do not deserve the flag of UCD. I will make an attempt to reduce the misconceptions about UCD by increasing the tangibility of the concept. Finally, I will provide some ideas on how to cope with the problems surrounding it and in this way help moving UCD to the mainland. made can be found (i.e. Siegel, 2003). Attention goes out to making the business case in terms of return on investment (Rosenberg, 2004) and the difficulties on integration with existing software engineering methodology (Seffah and Metzker, 2004). The lack of commonly agreed on definitions and methodology and the over-optimistic approach to UCD on one side, and the difficulties that arise on the other side, call for some scepticism. In this paper, I will therefore approach User-Centred Design with a balance between optimism and realism, in order to find some clarity about the way to think about and apply it.

As suggested, this paper will present a sceptic approach to UCD. The heterogeneous and optimistic notion leads to misconceptions, which in their turn could well be related with the difficulties that are faced during UCD-application. Therefore the research objective of this paper is as follows: “Investigate the relation between the misconceptions about UCD and the problems that arise during its application and find (existing) solutions.” The associated research questions that will be answered throughout the paper are: • • • • In what ways is UCD defined? To what misconceptions does the heterogeneous notion of UCD lead? optimistic and

During the execution of a design project at university, I first got in real touch with User-Centred Design (UCD). My project group aimed at a high rate of usability and was inclined to involve users as much as possible from the beginning of the project. Using several usability tools and techniques such as a metaphor, personas and a wizard of oz experiment, as they appeared to be appropriate, we created our own UCD method. While doing so, the question about the availability of a more rigid, structured methodology arose. While a need for usability seems to be generally agreed upon and an increasing body of literature points at UCD as the methodology to achieve this, the concept remains rather ambiguous. The vagueness of the concept is partly due to the lack of a clear definition. With some consensus on a high, abstract level, there is room for fairly different approaches. This does not provide much assistance to the seeking mind. Maybe the suggestions that UCD should be considered as “a nice, fluffy little catch phrase” (Karat, 1996, p.20) or just another TLA-trap - the trap of the three letter abbreviation - (Binder et al., 1999) are quite appropriate. A large share of the people who write about UCD seems to consist of gurus, visionaries and other enthusiasts in the field, which makes the general story they preach a bit too optimistic. Preece, Rogers and Sharp (2002), for example, dedicate a whole chapter to user-centred approaches in which only half a page is used to present several dilemmas in terms of time, cost and flexibility, when involving users. Looking at UCD in an idealized manner blurs the path to implementing UCD, and the concrete changes this takes (Dray and Siegel, 1998). Simultaneously, it seems that UCD has difficulties making a stand in the way organizations perform their activities. A lot of sources discussing how the business case for UCD should be

Which problems in UCD can be related to these misconceptions? What attempts have been made or should still be made to tackle these problems?

This research paper presents an analysis of current literature on this subject. First, an overview of scientific material defining UCD is given. Differences in definitions are pointed out as well as what underlies these differences. Several important problems that surround the application of UCD, related to the difficulties in defining it, are described. Finally, an overview of how the problems in defining and applying UCD are related is given and (existing) solutions are described. This should lead to a more tangible understanding of the concept of UCD in order to reduce misconceptions and provide ideas on how to cope with the related problems.

As the introduction suggests, it is quite hard to find a single definition for User-Centred Design. In this part I try to find out why this is so hard and attempt to get a better understanding of the concept. The term was first used by Norman and Draper in their book ‘User centered system design: New perspectives on humancomputer interaction’ (1986, p.?): ”User-centred design emphasizes that the purpose of the system is to serve the user, not to use a specific technology, not to be an elegant piece of programming. The needs of the users should

dominate the design of the interface, and the needs of the interface should dominate the design of the rest of the system.” This book, in which they emphasize the importance for a thorough understanding of the users, is considered a landmark in Human-Computer Interaction. Gaining popularity since then, there have been many attempts to further define the concept of UCD. This is maybe partly due to the fact that many of the articles in the book “speculate on alternative ways of doing things in HCI without much practical grounding” (Bannon and Bødker, 1991, p.235). One of these attempts is made by Landauer who defines usercentred design in his book ‘The trouble with computers’ (1995, p.221) as "design driven, informed, and shaped by empirical evaluation of usefulness and usability". According to Mao et al. (2001, p.1) “UCD refers to a multidisciplinary design approach based on the active involvement of users for a clear understanding of user and task requirements, and the iteration of design and evaluation. It is considered the key to product usefulness and usability.” This comes close to a currently more general agreed upon notion of UCD that seems to be based upon four principles, like for example identified by Gulliksen et al. (1999) and Maguire (2001): • An appropriate allocation of function between user and system: The division of labour between people and hard- and software, based on an appreciation of human capabilities, their limitations and a thorough grasp of the particular demands of the task; • • • Active involvement of users; Iterations of design solutions; Multidisciplinary design teams: The active involvement of other stakeholders such as managers, usability specialists, software engineers, interaction designers, training and support staff and task expert. These are also captured in the ISO 13407 standard on HumanCentred Design processes for Interactive Systems in which an attempt is made to make UCD more tangible. The standard defines five essential processes, which should be carried out in iterations as shown in Figure 1.

Before starting the iterations, careful planning of the integration of UCD throughout the project should take place. After this, a cycle of defining context (i.e. users, tasks and environment), specifying requirements, producing (partial) design solutions and finally evaluating these is repeated until the project objectives are attained. However some convergence in the notion of UCD is clearly seen, there is still some heterogeneity in all of the above definitions, which does not lead to a clear understanding of UCD. This problem was nicely described by Karat (1997, p.38) who states the following: “I suggest we consider UCD an adequate label under which to continue to gather our knowledge of how to develop usable systems. It captures a commitment the usability community supports—that you must involve users in system design—while leaving fairly open how this is accomplished.” He does come up with a definition that resembles the more generally agreed notion as presented before: “UCD defines an iterative process whose goal is the development of usable systems. There is general agreement that this is achieved through involvement of potential users of a system in system design.” (Karat, 1996, p.20; Karat, 1997, p.38) Furthermore, Karat presents several principles introduced by Gould that, according to him, best describe UCD: • • • • Early focus on users; Early and continual user testing; Iterative design; Integrated design: Usability engineering being approached as an integrated part of the design of a whole system. This general definition and these principles however offer an immediate example of his statement about leaving open how exactly to fill in a UCD process. More criticism on the vagueness and ambiguity of UCD is given by Constantine and Lockwood (2002, p.45) who claim that UCD is a “loose collection of human-factors techniques united under a philosophy of understanding users and involving them in design”. Also Macdonald (2005, p.78) states that “UserCentred Design is merely a toolkit”. The approach of these three authors is in some sense opposed to the claims about abstractness. The tools and techniques they talk about are rather low-level, while a philosophy is high-level. The part that seems missing is how to instantiate these tools and techniques under the flag of UCD. Several sources trying to define UCD (i.e. Katz-Haas, 1998) shortly note the fact that UCD is both a philosophy and a process. This twofold interpretation seems to be of great importance. All of the aforementioned sources agree on the philosophy, or as expressed by Karat (1996) on the commitment to involve users. The process however is only described in a very high-level, abstract fashion and on the other side there exists a large collection of techniques. I do not dare to state yet if this is necessarily a bad thing, but it could well be the source of a lot of misinterpretations. When Maguire (2001, p.629) introduces the ISO 13407 standard, he states that its principles and activities provide an “ideal framework to ensure full representation of the users throughout the software design process.” Important here is the statement that it is a framework. Like perhaps all of the definitions that go beyond showing just the philosophy, the broad process is outlined, but the details have yet to be filled in.

Figure 1 – ISO 13407 Key human-centred design activities (Maguire, 2001)

Related to this, Earthy et al. (2001) show a hierarchy of five levels of abstraction, which can be used to specify UCD: • Process statement: Concise, implementation free descriptions of what is done to make a system lifecycle user-centred. Aimed at process assessors, implementers and also used when planning a project; • Generic contextualized process statement: Methodologies and lifecycles to give guidance on how to apply UCD. Typically in the form of large textbooks by consultants; • Corporate contextualized process statement: Methodologies and lifecycles in the form of a company handbook; • Project instantiation: A project plan that sets out the activities to be performed on a particular project; • Project enactment: The application of specific tools and techniques. When describing UCD activities it is important to make clear on what level this is done, as each of the levels has its own purpose. A process statement, for example ISO 13407, describes what is done to make a process user centred, not how this is done, as this depends on business and project context. ‘Generic contextualized process statements’ are embodied by more detailed methodologies and lifecycles that can be adapted to suit a particular company in ‘corporate contextualized process statements’. The two most detailed levels, ‘project instantiation’ and ‘project enactment’ describe what activities are to be performed and what specific tools and techniques are used to do so, i.e. what is done on a day-to-day basis. They argue that problems arise when models of UCD are specified below the level of process models, as this leaves little room for adapting to particular business or project contexts or fit in with other methodologies. Furthermore the level of process statements is most suitable for management understanding. Current literature however is said to show inadequate rules for tailoring the high level definitions to a specific context, which is addressed by Dray and Siegel (1998) as the challenge of connecting vision and concrete changes. It is easy to understand the over-optimistic view of UCD as pointed out in the introduction now the division into philosophy and process has been made. To be enthusiastic about the philosophy is one thing and many people and companies are. When it however comes to actually executing a process, problems arise. While high level process statements can be used to get people (i.e. management) in favour of UCD, it remains difficult to contextualize and lower the level to concrete tools and techniques for day-to-day business. Furthermore, the ambiguity surrounding UCD, does not seem to come from really different notions of what UCD should be as there is clearly some convergence in this. It is rather a difference in levels of abstraction which makes it difficult to see if the same subject is discussed.

centring the user in their design process, a high level understanding of the corresponding process and some ideas on low level tools and techniques. Nevertheless, they still have difficulties with how to achieve this and really apply UCD. If it is not clear how to achieve the envisioned goal of UCD, there is a risk of arbitrarily trying some tools and techniques and never really reaching the goal. In this part several problems that are related to this are described.

4.1 Lack of Integration
Although the general opinion about UCD methods according to for example a survey by Mao et al. (2001) is positive and UCD is believed to increase the utility and usability of computer systems, the degree of adoption varies significantly. The common approach to UCD according to Gulliksen (2003) is rather ‘add-on’, performed as single usability activities. This poses the risk of for example being cut off when facing deadlines. When trying to introduce UCD in the overall process of a company, common activities such as setting up UCD guidelines and the incorporation of its principles into a standard methodology generally shift attention to a more abstract level. According to Dray and Siegel (1998) this often nurtures an idealized way of looking at the case, detached from development work in progress in the company. Due to the detached and high level approach, people involved in the overall process of the company (and not in setting up UCD) may therefore experience the activities towards application of UCD as being irrelevant and may thus show resistance. Adopting UCD throughout the entire process is difficult, but of major importance. Usually adopted late in the process, evaluations of a system - for example - might point out problems without having the possibility of correcting these (Gulliksen, 1999). When usability activities are carried out in such a detached fashion, this greatly reduces their effect and relevance. As software engineering techniques and tools have long time been developed independently from UCD methodology and even having some overlap, integration is hard. The question posed by Seffah and Metzker (2005, p.1) “Where to consider UCD techniques and knowledge in the existing software development life cycle to maximize benefits gained from both software engineering and UCD?” is hard to answer. Avoiding the obstacles that exist between these two worlds should be the first step towards integration. Obstacles exist due to for example different notations, languages, tools and different perception of the role and importance of the software artefacts that have an impact on usability. The great difference in notions of UCD as described in part 3 only worsens this. To illustrate, Seffah and Metzker (2005, p.4) present two extremes in the approach to UCD: • We, the engineers, the real designers of software, can build reliable and safe software systems with powerful functionalities. The usability people, the psychology guys, can then make the UI more user friendly. We, the usability professionals and interaction designers, should first design and test the interface with end users. Then, developers—the functionality builders—must implement the system that supports the user tasks.

As described in the part 3, there is a gap between the philosophy of UCD and how to give form to the actual UCD process. Due to this fact, companies might have a clear vision of the need of

Creating understanding of the complete UCD process instead of familiarity with some basic UCD concepts is part of the bridge over the gap between software engineering and UCD. Where current practices in software development are for example mostly technology driven and quality is measured by product defects and performance, organizations have to learn what

knowledge and skills are required to gradually adopt best practices from UCD such as a user-driven process and quality defined by user satisfaction, performance, etcetera (quality in use). Figure 2 shows an overview of these and several other important differences between both fields that still have to be overcome.

disciplines it is more difficult to broaden the scope and look at a greater deal of context. Usability however, is context dependent, so designing for usability depends on context. This is nicely addressed by Buur and Bødker (2000), who have investigated a more integrated way of working, opposed to the detached usability laboratory. The lack of understanding of use context, is tackled by them by integrating all of the participating competencies into a ‘usability collaboratorium’. Working together instead of the isolated way of taking over from each other in the tradition of the pipeline of analysis, design, realization and evaluation has proved the current way of enacting UCD to be too limited and less efficient. Arnowitz and Dykstra-Erickson (2006, p.64) point out several other problems surrounding the lack of context. In a world where everyone has his or her own interests it is actually quite hard to point a whole process toward converging on the user. “Designers want to trust their instincts; businessmen want to trust the business case; and computer scientists strive to build something bug-free and rock solid.” They argue that the only way to achieve the goal of a good ‘user experience’ is to have everyone bringing something to the table. “When smart designers, business folks, engineers, and usability professionals get together, they can make magic happen.” It is thus indeed collaboration in a multidisciplinary fashion that seems to count. Also Karat (1997, p.37) gives a warning about scope. The idea of centring something in a design process is dangerous, as it might lead to believing that other elements are less important. UCD can thus be taken as “suggesting that users (or usability people) should be in control of design rather than equally critical participants.” He concludes that when developing usable software many perspectives need to be balanced. For the ‘usability people’ this means that besides the mere involvement of users it is important to keep the difficult necessity of multidisciplinary communication in mind in order to operate within a context of for example design trade-offs and limited resources. Also many UCD enthusiasts, busy with persuading their management to adopt a new way of working, are facing context problems. Siegel (2003) describes them using the wrong arguments. There is a need for contextual awareness and an idea of the bigger picture, for example when talking about costbenefit or return on investment (ROI). Rosenberg (2005) adds that any usability ROI is not truly relevant per se, as these are performed at a tactical level, where it is the strategic level that counts. He promotes looking at the larger dialogue instead of isolated intermediate steps in the product lifecycle. Too much focus and the related lack of context have been called harmful by Norman (2005). He states that apart from too much attention on particular users, there is a primary focus on tasks instead of activities which can be comprised of multiple, overlapping tasks. Failing to support the sequential requirements of tasks and activities can lead to a lack of cohesion and added complexity. The focus on particular users, might lead to improvements in usability for them, whilst worsening the situation for others. By looking more at the activities than at particular tasks of particular users (which is said to be overdone by some companies that are proud of their user-centred philosophy) it is possible to prevent too much tailoring by discarding user suggestions that do not fit in. Norman likes to present this as a ‘new’ concept named Activity Centred Design, although he admits that the biggest difference to UCD is a change of mindset. Something similar is caught in the Contextual Design method by Beyer and Holtzblatt (1999). Based on the idea that “great product ideas come from the marriage of a designer’s detailed

Figure 2 – Practices in software development versus practices in human-centred development (Seffah and Metzker, 2005, p.5) According to Seffah and Metzker (2005) usability specialists should think and work more like engineers in order to overcome barriers as described here. Siegel and Dray (2003, p.22) concur with this stance. According to them UCD professionals are “perceived as identifying problems and then handing off responsibility to others to generate potential solutions and weigh their trade-offs.” It seems that the UCD camp should stand up and demonstrate their ability to participate by doing much more to generate solutions. Concluding, the lack of integration comes from two sides. On one side, companies have difficulties aligning UCD with their regular process and thus usability is performed in a detached, add-on manner. This can be related to the gaps distinguished in part 3. Companies seem to grasp the need of usability and might be aware of UCD process statements, but lack the ability of contextualizing this to their specific situation and therefore do not know how to effectively act out UCD on a day-to-day basis. When starting off with specifications on a low level, some usability methods might be used. Without integration in the overall process however, one can hardly name this UCD. From the other side, UCD professionals should do more to make integration easier by generating more solutions and nourish the idea of relevance.

4.2 Lack of Context
The lack of integration is closely connected to another problem that UCD professionals are coping with, a lack of context. From the heterogeneity discussed in part 3 follows that some definitions are clearly less broad than others. Furthermore, UCD is not only about the user interface and does not work in isolation (Earthy et al., 2001). Still concepts like mere usability testing are easily mistaken for UCD (Mao et al., 2001). The attitudes and approaches of UCD however differ from the traditional human-factors approaches by the focus on broader context (Karat, 1997). The isolation of UCD professionals, due to the lack of integration inhibits one of the generally agreed principles discussed in part 3, being working in multidisciplinary design teams. As long as there is no real integration with the regular (software engineering) process, a real multidisciplinary approach seems out of the question. Without input from other

understanding of a customer’s need and his or her in-depth understanding of the possibilities introduced by technology”(Beyer and Holtzblatt, 1999, p.32) it offers a process statement that guides a team in understanding and redesigning a customer’s work, with explicit attention to context of the process that is to be supported. They recognize that any system embodies a way of working and “by explicitly defining the work and the system, Contextual Design unifies design, marketing, delivery, and support in a coherent response to the customer.” (Beyer and Holtzblatt, 1999, p.33) They help multidisciplinary teams to agree on what their customers want and how to design a system for them. This is reached by multidisciplinary collaboration and the individual parts of their framework are aimed at furthering the design process, maintaining a shared purpose and direction or help the team coordinate with the larger organization. Without going into details, it is interesting to note that also Constantine and Lockwood (1999, p.23) came up with an approach that not so much focuses on the users, but on the work they need to perform: “It is not users who must be understood, but usage – how and for what ends software tools will be employed”. Focus on users is not sufficient, it is imperative to focus on their work and on providing usable tools for them. Many sources agree on the fact that context is an important part of UCD. Some come up with new concepts because UCD focuses too much on users. I believe this might be true in practice, but in theory UCD is not omitting context at all. When thinking of UCD as described in part 3, principles such as the ‘appropriate allocation of function between user and system’, ‘multidisciplinary design teams’ and ‘integrated design’ should actually create a lot of context. The inability to achieve this and the lack of integration however seem to narrow down the scope. Furthermore, enthusiasts might sometimes forget that there is more around the user that is ‘centred’. It is however not just the context of the system that is being designed that should be taken into account. Also the particular business or process context of the designing company is important. As argued in part 3, higher level process statement should be contextualized and tailored in order to be able to really act out a UCD process.

UCD staff is mostly organized in a centralized structure, closely followed by a mixed structure, as can be seen in Figure 3. They state that “many organizations do not insist on a close relationship of HCI professionals to their product teams. Future research should look at the effectiveness of this approach.” (Mao et al., 2001, p.8)

Figure 3 – Organization of UCD Staff (Mao et al., 2001) Vredenburg, Isensee and Righi (2002, p.?) have identified problems with the centralized structure. When groups of specialists are kept together, although provided with more peer support, they “are not really considered equals by the product organization and thereby are not perceived to be part of the core team.” In the decentralized structure however, they argue that there is too little contact with discipline peers for the sake of “technical vitality and career development”. Therefore, they advocate more of a mixed model. The issues on structure do not address how people are physically located. As Vredenburg et al. (2002, p. 175) note, specialists are often not even co-located and are thus sometimes almost literally placed on an island.

4.3 UCD Islands
The aforementioned lack of integration and context leads to what I would like to call ‘UCD Islands’. UCD is performed in an isolated manner, with too little contact with the other stakeholders in the process. Partly due to this fact, there is too much focus. Living on an UCD Island makes it hard to stay in contact with the outside world and thoroughly work together and thus narrows down the scope of its inhabitants. In fact, it is quite inappropriate to place the UCD flag on such an island as this way of performing it, does not really meet with most of the principles presented in part 3. Marcus (2005) describes major companies seeking to establish or improve their own ‘user-centred user-interface design centres of excellence’, shortly UIDC’s. Whilst some start off well with special taskforces consisting of ‘evangelists’, many efforts stall after a while. The same problems arise in medium sized companies, where generally some sort of taskforce is created to familiarize the company with UCD. Working in isolation is one of the main causes he mentions. Furthermore, companies seem to believe that UCD is different from other corporate activities in the sense that it might survive as informal, un-budgeted, voluntary efforts of dedicated individuals. UCD Islands also appear when looking at organizational structure. Mao et al. (2001) conclude from their survey that

Figure 4 – UCD specialists are sometimes almost literally placed on an island. (Original cartoon by Don Norman) It has slowly become clear that UCD should work in a more integrated, multi-disciplinary fashion, in order to assure sufficient context and bring the formation of UCD Islands to a halt. The next part will discuss several means of transportation to help moving UCD to the mainland.

In this part I will give a final overview of the problems that exist, concerning the application of UCD, in order to increase its tangibility. I will furthermore provide ideas on how to cope with these problems. In order to do so, I will start off with giving a short overview of readily existent solutions and then propose ‘new’ solutions based on the findings that have been presented throughout this paper.

5.1 Existent Solutions
In part 4, I have shortly presented several existent solutions to the problems of a lack of context and a lack of integration. Norman (2005) with the Activity Centred Design methodology and Constantine and Lockwood (1999) with Usage-Centred Design both address the problem of context. They all state that a need for more context instead of only concentrating on the users and their tasks is needed. Also Beyer and Holtzblatt (1999) cope with the problem of context by the use of Contextual Design. This methodology furthermore explicitly aims at multidisciplinary collaboration and thus also copes with the lack of integration. In practice the problems of context and integration exist, in theory however UCD does prevent these problems. For example, multidisciplinary design teams, integrated design and a proper allocation of function between user and system are generally agreed ingredients of UCD. Therefore these ‘new’ methodologies seem to present solutions for symptoms, instead of taking on the real problems. Norman (2005) himself states that the biggest difference to UCD is a change of mindset of the ones who apply this methodology. Furthermore, all of these solutions are presented on the level of the process statement or the generic contextualized process statement. Beyer and Holtzblatt (1999, p.33) state that they offer “a useful framework for tailoring a design process. Individual steps can be shortened or omitted if they aren’t applicable, or a step can be elaborated with additional techniques if it is important”. This means these methodologies might partly solve the symptoms of the presented misconceptions, and might give some more support on how to enact UCD, but still leave the need for contextualization and adaptation to fit the specific organizational needs. Therefore, the next part is aimed at solving the real problems of UCD.

involve users in system design—while leaving fairly open how this is accomplished.” It must however be clear that, on this level, parts are left open intentionally. Part 3 pointed out that starting with more detailed specifications leaves too little room for adapting to a particular company with specific characteristics, such as existing methodologies. There should thus be awareness of the need for tailoring high level definitions to a specific context. On a lower level, plenty of tools and techniques are available to create a fitting UCD process. Karat (1997, p.38) states: “The challenge is to build up an understanding of how and when each is appropriate”. It seems rather unlikely that it is possible to have one generic process that suits every company, therefore a UCD process should be specified or adapted and implemented in each organisation; Organisations must design their own UCD processes (Gulliksen et al., 2000; Gulliksen, 2003) or as Dray and Siegel (1998, p.19) express it: “The key is understanding both UCD and the culture of the organization to find a strategy that will effectively work in the reality of a particular company.” I strongly concur with the company ‘Human Factors International’ with their approach to UCD being a strategic business approach. UCD might be indeed best considered as a business philosophy. “By institutionalizing usability, it becomes infused throughout the software lifecycle. User-centered design is part of an organizational culture—involving people, process, and technology—not a silver bullet or quick-fix approach.” (Nadel and Piazza, 2005, p.12) A good example of a company that has successfully institutionalized UCD is IBM. In the mid-1990s IBM developed a UCD process for the development of their hardware, software, web sites and services. Due to a change in their business environment, this process has recently been enhanced and now goes by the name ‘User Engineering’ (Vredenburg, 2003). Their extensive documentation is available on their website, and could serve as an archive of best practises. Marcus (2005) states that this archive is almost too deep and broad for use as a practical on-the-job document for other companies, which is easily understood, knowing that this process has been heavily tailored to fit IBM. This is a perfect example of a corporate contextualized process statement that is not easily applicable in a different context. By approaching UCD in this way it should become clear that UCD should first be addressed at the strategic level rather than the tactical level. While tailoring UCD to the context of the particular company, a lot should be done to nurture integration in the existing overall process. This however might not be enough to achieve full integration: The gap between the world of Software Engineering and User Centred Design can only be overcome when both sides become conscious about their differences and the synergy that can be obtained when collaborating. To be most effective none of both sides should work in isolation. As shown in part 4, integration is closely connected to the need for context. Everyone in the process must understand its full scope and its inherent problems (Gulliksen et al., 2000). The notion that context is crucial, should contribute to both sides willing and being able to integrate and work together. As Earthy, Jones and Bevan (2001, p.569) state: “Research is required into the most effective means of integrating user-centred design processes and techniques with other systems disciplines. Sociologically, research is required into barriers to the uptake of user-centred approaches within technically driven engineering disciplines.”

5.2 Proposed Solutions
The search for a definition of UCD has shown that throughout the years the notion of UCD has slightly changed. Nowadays there seems to be a clear convergence in the notion of what UCD should be. The seeming ambiguity is mainly caused by differences in level of abstraction and the gap between being enthusiastic about a philosophy and really being able to act this out in a day-to-day fashion. It is furthermore quite acceptable that the fact that UCD is sometimes mistaken for usability testing or older definitions with a main interest in interface design increases the idea of heterogeneity. The ISO 13407 standard for example seems a good starting point for talking about the current stance on UCD as this standard represents the present general idea of UCD. The abstractness of this standard, being on the level of the process statement, makes it very useful for communicating about the philosophy of UCD with management, process assessors, implementers and so forth. Examples have made clear that informal, un-budgeted, volunteer effort of dedicated individuals is not enough to really achieve UCD, so such a high level of abstraction should be used to communicate the need for it at the top of the organisation. As Gulliksen et al. (2000, p.15) conclude from a workshop: “Usability must be made an important issue at the top of an organization – management must be committed to usability.” The high-level approach alone however, is just the start. It must be made absolutely clear that it is known that a high level of abstraction is used, which needs to be made more concrete to be of real use. When communicating on this level, Karat (1997, p.38) was fairly right when stating that UCD “captures a commitment the usability community supports—that you must

The barriers that inhibit integration and the difficulties of tailoring the UCD process to the particular business context seem the most apparent challenges left. The creation of awareness of what UCD actually is and what ingredients it has, should deal with the problems of ambiguity. Making clear on what level UCD is being discussed and showing the need for starting on a high level (both in definition and in the company) that is lowered in a company dependent manner, should contribute to this. The notion of the difficulties concerning contextualisation and integration plus the consciousness that a lack of integration and context leads to UCD Islands, which actually should be prohibited to use the UCD flag, should reduce over-optimism. Knowing where the problems are, means knowing where efforts need to be made, which causes a more realistic approach to UCD. All of these subjects can be seen as prerequisites to really applying UCD and moving UCD to the mainland.

Arnowitz, J. and Dykstra-Erickson, E. (2006). It's all about the user, isn't it?. interactions 13, 1 (Jan. 2006), 64-64. DOI= Bannon, L. J., and Bødker, S. (1991). Beyond the interface. Encountering artifacts in use. In Carroll, J. M. (Ed.), Designing interaction: Psychology at the humancomputer interface, 227-253. Cambridge, UK: Cambridge University Press. n/13/LBsb9.html Beyer, H. and Holtzblatt, K. (1999). Contextual design. interactions 6, 1 (Jan. 1999), 32-42. DOI= Binder, T., Brandt, E. and Buur, J. (1999) User-centeredness and product development. Avoiding isolated UCD competency and the TLA trap. In User centered design—problems and possibilities. Gulliksen, J., Lantz, A., and Boivie, I. (1999). Centre for User Oriented IT Design, Royal Institute of Technology Stockhom, Sweden. 36-42. Buur, J. and Bødker, S. (2000). From usability lab to “design collaboratorium”: reframing usability practice. In Proceedings of the Conference on Designing interactive Systems: Processes, Practices, Methods, and Techniques (New York City, New York, United States, August 17 - 19, 2000). D. Boyarski and W. A. Kellogg, Eds. DIS '00. ACM Press, New York, NY, 297-307. DOI= Constantine, L. L. and Lockwood, L. A. (1999) Software for Use: a Practical Guide to the Models and Methods of Usage-Centered Design. ACM Press/Addison-Wesley Publishing Co. Constantine, L.L. & Lockwood, L.A.D. (2002) User-Centered Engineering for Web Applications. IEEE Software, Vol. 19, No. 2, pp. 42-50. DOI= Dray, S. M. and Siegel, D. A. (1998). User-centered design and the “vision thing”. interactions 5, 2 (Mar. 1998), 16-20. DOI= Earthy, J., Jones, B. S., and Bevan, N. (2001). The improvement of human-centred processes—facing the challenge and reaping the benefit of ISO 13407. Int. J. Hum.-Comput. Stud. 55, 4 (Oct. 2001), 553-585. DOI= Gulliksen, J., Lantz, A., and Boivie, I. (1999). User centered design— problems and possibilities. Centre for User Oriented IT Design, Royal Institute of Technology Stockhom, Sweden. Gulliksen, J. (1999). Bringing the Social Perspective: User Centred Design. In Proceedings of HCI international (the 8th international Conference on Human-Computer interaction) on Human-Computer interaction: Ergonomics and User interfaces-Volume I - Volume I (August 22 - 26, 1999). H. Bullinger and J. Ziegler, Eds. Lawrence Erlbaum Associates, Mahwah, NJ, 13271331. Gulliksen, J., Lantz, A., and Boivie, I. (2000) Making User Centred Design Usable - A summary of the 1999 INTERACT workshop. In How to make User Centred Design Usable, Gulliksen, J., Lantz, A., and Boivie, I. Centre for User Oriented IT Design, Royal Institute of Technology Stockhom, Sweden, 7-18

In this paper I started off with concerns about the ambiguity and over-optimism surrounding the concept of UCD. The sceptic approach that originated from this made clear that there actually is not that much heterogeneity as suspected. Lately there has been a clear convergence in the notion of UCD, however older definitions and related concepts are easily mistaken for the current stance on UCD. The fact that UCD can be addressed in different levels of abstraction and that it is not often made explicitly clear on what level UCD is being discussed, contributes to the vagueness of the concept. The gap between the philosophy and how to give form to the actual UCD process leads to detached attempts of enacting UCD, with a lack of integration and context; UCD Islands are formed. This results in companies claiming to enact UCD, while in fact they are not. This paper has made clear what the generally agreed main ingredients of UCD are and should thus make the concept somewhat more tangible. It has shown that the fact that UCD can be interpreted in many ways it is not a bad thing, but rather a necessity. The appropriate way of applying UCD is highly dependent of the organizational context (i.e. methodologies that are already in use and company structure). UCD should best be seen as a business philosophy, and communication about it should be first – explicitly – done on a high level, while not forgetting the need for lowering this level. Furthermore, the notion that misinterpretation of the concept leads to problems that do not fit with UCD should lead to awareness of how to treat UCD. It has become clear that the real difficulties of UCD are in the questions of how to contextualize and adapt the high-level concept towards a day-to-day application in business context and how to bridge the gap between the world of UCD and the world of Software Engineering. Contextualization, integration and multidisciplinary collaboration combined with the problem of adopting a new business philosophy forms a quite difficult problem. While several attempts have already been made to tackle this, such as the ISO TR 18529 standard which provides means to assess an organization’s capability to perform UCD (Seffah and Metzker, 2005) and research by for example Earty et al. (2001) and Maguire (2001), future research should go out to making it easier to overcome this problem.

I would like to thank Betsy van Dijk and Mariet Theune for their efforts in helping me during the process of writing this paper.

Gulliksen, J., Göransson, B., Boivie, I., Persson, J., Blomkvist S. and Cajander, A. (2003) Key Principles For User Centred Systems Design. In the special section on Designing IT for Healthy Work of the International Journal Behaviour and Information Technology, Vol. 22, No. 6, pp. 397-409. Edited by Jan Gulliksen Katz-Haas, R. (1998) User-Centered Design and Web Development summary of this article, Ten Guidelines for User-Centered Web Design. Usability Interface, Vol 5, No. 1, July 1998 Karat, J. (1996). User centered design: quality or quackery?. interactions 3, 4 (Jul. 1996), 18-20. DOI= Karat, J. (1997). Evolving the scope of user-centered design. Commun. ACM 40, 7 (Jul. 1997), 33-38. DOI= Landauer, T. K. (1995). The trouble with computers: Usefulness, usability, and productivity. Cambridge, MA: The MIT Press. Mao, J., Vredenburg, K., Smith, P. W., and Carey, T. (2001). User-centered design methods in practice: a survey of the state of the art. In Proceedings of the 2001 Conference of the Centre For Advanced Studies on Collaborative Research (Toronto, Ontario, Canada, November 05 - 07, 2001). D. A. Stewart and J. H. Johnson, Eds. IBM Centre for Advanced Studies Conference. IBM Press, 12. Macdonald, N. (2005). Beyond human-centered design?. interactions 12, 2 (Mar. 2005), 75-79. DOI= Maguire, M. (2001). Methods to support human-centred design. Int. J. Hum.-Comput. Stud. 55, 4 (Oct. 2001), 587-634. DOI= Marcus, A. (2005). User-centered design in the enterprise. interactions 12, 1 (Jan. 2005), 18-23. DOI= Nadel, J. and Piazza, G. (2005). Managing the Knowledge Behind Business Decisions through User-Centered Design. Human Factors International White paper Norman, D. A., and Draper, S. W. (Eds.) (1986). User centered system design: New perspectives on human-computer interaction. Hillsdale, NJ: Lawrence Erlbaum Associates. Norman, D. A. (2005). Human-centered design considered harmful. interactions 12, 4 (Jul. 2005), 14-19. DOI= Norman, D. A. (2006). Interaction design is still an art form: ergonomics is real engineering. interactions 13, 1 (Jan. 2006), 45-60. DOI= Preece, J., Rogers, Y., and Sharp, H. (2002) Interaction Design. 1st. John Wiley & Sons, Inc. Rosenberg, D. (2004). The myths of usability ROI. interactions 11, 5 (Sep. 2004), 22-29. DOI= Seffah, A. and Metzker, E. (2004). The obstacles and myths of usability and software engineering. Commun. ACM 47, 12 (Dec. 2004), 71-76. DOI=

Seffah, A. and Metzker, E. (2005) Usability in Software Engineering: Prevalent Beliefs, Myths, and Obstacles. In Human-Centered Software Engineering - Integrating Usability in the Software Development Lifecycle, Series: Human-Computer Interaction Series, Vol. 8 Seffah, Ahmed; Gulliksen, Jan; Desmarais, Michel C. (Eds.) 2005 Siegel, D. A. (2003). The business case for user-centered design: increasing your power of persuasion. interactions 10, 3 (May. 2003), 30-36. DOI= Siegel, D.A. and Dray, S. (2003). Living on the edges: usercentered design and the dynamics of specialization in organizations. interactions 10, 5 (Sep. 2003), 18-27. DOI= Vredenburg, K., Isensee, S., and Righi, C. (2001) UserCentered Design: an Integrated Approach with Cdrom. Prentice Hall PTR. Vredenburg, K. (2003). Building ease of use into the IBM user experience. IBM Syst. J. 42, 4 (Oct. 2003), 517-531.