Undoubtedly, today very few would question the relationship between usability and user orientation. To be able to design a usable interface to a system, active user influence is essential. How come, then, that the users often are left out or considered an aggravation in development work? Is it a question of attitude, maturity or managerial influence? Is it a question of project organisation, supervisory control or is it just one example of how difficult it can be for human beings to communicate and respect each other?

We guess the general answer is: Yes, it is all of these!

A user-oriented approach to system development and design should in all situations be preferred. The main reasons for this are two:

1. End users are experts on their work and therefore the only ones that can describe it.

2. End users are the ones that are most suitable for testing and evaluating prototypes and systems that are developed for them.

But, on the other hand, user participation in a development project is never, in itself, a guarantee for a usable system. Abundant evidence of this is furnished by the large number of computer systems with severe usability problems that exist in working life today and the vast number of projects that have failed before becoming a working system.

Product development companies can, in many situations, be accused of having the following approach to usability: If it sells, then it is usable! They couldn’t be more wrong. Numerous consumer products exemplify this: there are hundreds of functions on cellular phones, video-recorders and wristwatches, yet only a handful of these functions are actually used. Would there not be a bigger market for an easy-to-use cellular phone with only the ten functions needed by the average user, or one which focused on elderly users, users with special needs, and so on?

In-house development is very much different. The users can rarely choose which product to use in their work situation. They are forced to use what is there, no matter how great the usability problems are. This is very serious since usability deficiencies in products can lead to stress, physical and mental strain. In-house development projects have promising presumptions with a defined user population and times available for the users to participate. The actual possibilities for the user to influence the development of their own computerised information system have, though, proven to be rather limited.

Despite all the research efforts that have been put into user orientation, applying HCI knowledge in real life development projects is problematic. What is the essence of the problems with user-oriented design? The methods and tools are already available, but is something missing or do the methods and tools lack anything? At a Scandinavian workshop on "User orientation in practice" a number of Swedish scientists and consultants compiled the following list of categories of problems with user participation:

• Attitude problem. System developers do not see their work role as service in a work context. Many system developers regard computer system development as an artistic occupation with an expressive task, or a task of breaking new technical limitations.

• Communication problems. The lack of ability, time or interest in trying to understand and interpret the worlds of the various roles involved in the development work, indicate a problem of communication. Is it the group process, the way in which the participants cooperate, that is insufficient? Do we demand too much of the users? Indeed, do we even speak the same language? Is anybody in the project using his/her empowerment to prevent everybody’s view from being heard?

• Methods and tools problems. Methods and tools exist, but are they useful and available to everybody? Some descriptions are only available as standards and commercial methods and therefore not accessible to the public. Other methods and tools have to be thoroughly searched for by the project team.

• Lacking time. Iterative development work is one of the bases for user-oriented design. But there is seldom enough time in a project to be able to develop in an iterative fashion. The construction phase of the development tends to delay the project. When the time comes to perform usability evaluation, it is not uncommon to find that time has run out and that there is only room for a final evaluation, the results of which are only a mechanism for judgement and do not result in any changes being made to the final systems. Conversely, problems of different types are generated by the fact that many large system development projects tend to last for several years.

• Organisational problems. A user-centred design process must be supported and encouraged by the organisation. Severe obstacles to this process can be presented by adverse managerial influence, various conflicting power relations and the lack of minimal organisational support for usability-related work. The management seldom supports the allocation of sufficient time and resources for user centring.

• Participants support. There must be support for user-centred work both at the managerial level and at the user level. This is important both for the allocation of time and resources to a project and in order that the users should feel that they can participate as much as necessary, and that there is support for that.

• Competence problems. The participants in the design process seldom have the knowledge, competence, special abilities or even interest in working in a user-centred fashion. HCI knowledge is, despite decades of research, still relatively unknown to most participants in practical system development. In distributing this knowledge our universities and teaching institutions have a great responsibility. A great deal of research has been performed in this area, especially in Scandinavia, but these results seem to be difficult to apply. Researchers have a great responsibility to make the research results available and accessible as methods and knowledge and to disseminate this knowledge on the market.

• External aspects. Everything can happen in practice. User-oriented work is never performed in a vacuum: on the contrary, various unexpected incidents can disturb the development work. A project can be affected by processes of change, or political or other strategically important decisions, and seldom is there any possibility of influencing these. Differing interests might be represented, and conflicts may occur that can not be solved within the project.

The definition of users is also problematic, as it is not always clear who is behind the concept of users. The concrete contact between a project and the users can be anything from the buyers and managers to the persons that finally are to use the system: the so-called end-users. The eventual cooperation possibilities certainly depend on who the users are.

CID, the Royal Institute of Technology’s Center for user oriented IT-design has as its aim the performing of research and development focusing on the usability and aesthetics of information technology. A user-oriented approach is therefore a necessity, even though it is not always obvious how to achieve one. At CID we have a working group focusing especially on how to get user orientation to work in practice. This group analyses why user-centred methods are difficult to realise in practice, and strives to complement existing models to make them more applicable.

The main objectives of the group's work are to:

• Summarise existing approaches to user-centred systems design.

• Identify and analyse methodological and practical experiences, especially key problems in connection with user-centred design.

• Specify complementary methodological parts in order to minimise the problems experienced, adapted to the specific organisation.

• Implement, test and evaluate these methods in real development projects in different organisations.

• Specify competencies needed for participation in user centred design, and appropriate education programmes.

• Specify requirements for development methods and tools to support a user-centred methodology.

• Test and evaluate the methods in real development projects.

• Generalise the results and formulate methods and models.

In the near future we are planning to hold an international workshop on experiences of user orientation in practice.

© 1998,1999,2000 i3net	-- Search i3net --	About the i3net web pages
Revised: 17 April, 1998.		Mail to webmaster@i3net.org