Erwin Elling - A sceptic approach to User-Centred Design

8/14/2019 Erwin Elling - A sceptic approach to User-Centred Design

1/8

A sceptic approach to User-Centred Design

(Final Draft)Erwin Elling (0000132)

[email protected]

ABSTRACTAs 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 itsapplication. 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.

1. INTRODUCTIONDuring 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 toinvolve 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, fluffylittle 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 ofsources discussing how the business case for UCD should be

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.

2. OUTLINE OF RESEARCHAs 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 optimistic and

heterogeneous notion of UCD lead? Which problems in UCD can be related to these

misconceptions?

What attempts have been made or should still be made totackle 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 theconcept of UCD in order to reduce misconceptions and provide

ideas on how to cope with the related problems.

3. DEFINING USER-CENTRED DESIGNAs 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 human-

computer 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


2/8

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

Bdker, 1991, p.235).

One of these attempts is made by Landauer who defines user-

centred 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, likefor example identified by Gulliksen et al. (1999) and Maguire

(2001):

An appropriate allocation of function between user andsystem:

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 Human-

Centred 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.

Figure 1 ISO 13407 Key human-centred design activities

(Maguire, 2001)

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

supportsthat you must involve users in system designwhile

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 asystem 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 howexactly 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 User-

Centred 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 aprocess. 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 detailshave yet to be filled in.


3/8

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 whatis 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.

4. DIFFICULTIES CONCERNING THEAPPLICATION OF UCDAs 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

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 IntegrationAlthough 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 toUCD:

We, the engineers, the real designers of software, can buildreliable 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, developersthe functionality buildersmust

implement the system that supports the user tasks.

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 examplemostly technology driven and quality is measured by product

defects and performance, organizations have to learn what


4/8

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.

Figure 2 Practices in software development versuspractices 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 ContextThe lack of integration is closely connected to another problemthat 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

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 Bdker (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 limitedresources.

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 cost-

benefit 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 tasksinstead 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 methodby Beyer and Holtzblatt (1999). Based on the idea that great

product ideas come from the marriage of a designers detailed


5/8

understanding of a customers 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 customers 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 tofocus 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 thecontext 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.

4.3 UCD IslandsThe 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 asthis 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 UIDCs. 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

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 ofspecialists 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

oftechnical 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.

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.

5. MOVING UCD TO THE MAINLANDIn 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 proposenew solutions based on the findings that have been presented

throughout this paper.


6/8

5.1 Existent SolutionsIn 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.AlsoBeyer 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 arent 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.

5.2 Proposed SolutionsThe search for a definition of UCD has shown that throughoutthe 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 thephilosophy 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 acommitment the usability community supportsthat you must

involve users in system designwhile 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 andtechniques 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 cultureinvolving people, process,

and technologynot 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 couldserve 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 beovercome 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.


7/8

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, shouldcontribute 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.

6. CONCLUSION AND FUTURERESEARCHIn this paper I started off with concerns about the ambiguity and

over-optimism surrounding the concept of UCD. The scepticapproach 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 conceptsomewhat 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 gapbetween 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 organizations 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.

ACKNOWLEDGEMENTSI would like to thank Betsy van Dijk and Mariet Theune for

their efforts in helping me during the process of writing this

paper.

REFERENCESArnowitz, J. and Dykstra-Erickson, E. (2006). It's all about the

user, isn't it?. interactions 13, 1 (Jan. 2006), 64-64.

DOI=http://doi.acm.org/10.1145/1109069.1109114

Bannon, L. J., and Bdker, S. (1991). Beyond the interface.

Encountering artifacts in use. In Carroll, J. M. (Ed.),

Designing interaction: Psychology at the human-computer interface, 227-253. Cambridge, UK:

Cambridge University Press.

http://www.ul.ie/~idc/library/papersreports/LiamBanno

n/13/LBsb9.html

Beyer, H. and Holtzblatt, K. (1999). Contextual design.

interactions 6, 1 (Jan. 1999), 32-42.


Binder, T., Brandt, E. and Buur, J. (1999) User-centeredness

and product development. Avoiding isolated UCD

competency and the TLA trap. In User centered

designproblems 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 Bdker, 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= http://doi.acm.org/10.1145/347642.347768

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-CenteredEngineering for Web Applications.IEEE Software, Vol.

19, No. 2, pp. 42-50.

DOI=http://dx.doi.org/10.1109/52.991331

Dray, S. M. and Siegel, D. A. (1998). User-centered design and

the vision thing. interactions 5, 2 (Mar. 1998), 16-20.


Earthy, J., Jones, B. S., and Bevan, N. (2001). The improvement

of human-centred processesfacing the challenge and

reaping the benefit of ISO 13407.Int. J. Hum.-Comput.

Stud. 55, 4 (Oct. 2001), 553-585. DOI=

http://dx.doi.org/10.1006/ijhc.2001.0493 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, 1327-

1331.

Gulliksen, J., Lantz, A., and Boivie, I. (2000) Making User

Centred Design Usable - A summary of the 1999

INTERACT workshop. InHow 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


8/8

Erwin Elling - A sceptic approach to User-Centred Design

Documents

Transcript of Erwin Elling - A sceptic approach to User-Centred Design