User Centered Design in Practice - Problems and Possibilities

association with other PDG projects related more closely to the development of the
OpenMath Standard. Programming staff (who worked on the IPS project in addition to
other PDG projects) felt that although there was a temptation to customize for the IPS
context, that they should remain within the OpenMath specifications. One result of this
was that the design team was reluctant to dedicate time to implementing features that either
did not conform to the OpenMath Standard, or for which no standards yet existed.
While the instance of conflicting goals described here had few significant
consequences, it is indicative of a wider problem user-centered design practitioners are
now facing in North America. Increasingly companies are reluctant to engage in ‘custom’
system design efforts, and agree to do so only when they believe commercial benefit can
be gained in the future from involvement with users, who are increasingly seen as
representative users.
For example, a major Canadian hospital has contracted a health software
development company in the United States to develop health telecommunications software
for the Canadian hospital. Commercial rights to the software will remain with the
software development company, which hopes to market the new software primarily in the
United States. Widespread concern exists among health care professionals and the
hospital employees’ union that the end goal of marketing the software in the United States
(which has a private health care system) will make it difficult to ensure that the software
‘custom developed’ for the Canadian hospital will meet the needs of the public (statefunded)
health care system in Canada.
In a sense, the project to develop mathematics software described here is very similar
to the hospital project described above. In the school project, student users told members
of the design team (sometimes directly, and sometimes through their teacher, who was
also a member of the design team) what changes they wanted implemented. If user
demands could be easily implemented or they were viewed by senior programmers as
important in relation to the emerging OpenMath Standard, they were implemented.
Ultimately members of the design team and not users decided which of the shortcomings
identified by users were or were not implemented. Although the students could and did
participate in the project, they did not have the power to completely determine the final
form of the software. The features identified by users that were implemented reflected (in
part) the power dynamics inherent to the student/teacher/designer power relations. Some
features identified by student users as important were dismissed as unnecessary to
learning objectives by the rest of us. As members of the design team, we assumed our
socially sanctioned roles as more knowing adults, in relation to children. Although we are
all good people and have a great deal of respect for the students we worked with on this
project and we did listen to and learn from the students, we did not give ultimate control
of the software to them.
The two instances of conflicting goals in the system development process -- in the
hospital and in the school setting-- suggest that in a North American context even when
user input is sought, other factors may have greater influence on the system development
process than users. And, it highlights another challenge: even if a design team does want
to implement users’ suggestions, they may be constrained by management ultimately.
Indeed, this problem has been articulated by several of the participatory design and
ergonomics practitioners I have interviewed over the last two years.
32 (85) CID-40 • User Centered Design in Practice