Erwin Elling - A sceptic approach to User-Centred Design
-
Upload
erwin-elling -
Category
Documents
-
view
216 -
download
0
Transcript of 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)
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
-
8/14/2019 Erwin Elling - A sceptic approach to User-Centred Design
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.
-
8/14/2019 Erwin Elling - A sceptic approach to User-Centred Design
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
-
8/14/2019 Erwin Elling - A sceptic approach to User-Centred Design
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
-
8/14/2019 Erwin Elling - A sceptic approach to User-Centred Design
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.
-
8/14/2019 Erwin Elling - A sceptic approach to User-Centred Design
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.
-
8/14/2019 Erwin Elling - A sceptic approach to User-Centred Design
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.
DOI=http://doi.acm.org/10.1145/291224.291229
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.
DOI=http://doi.acm.org/10.1145/274430.274433
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/14/2019 Erwin Elling - A sceptic approach to User-Centred Design
8/8