Interactions - January/February 2010

IT systems first introduced
to Africa by American and
European multinational
companies, or by white
Africans during the
Apartheid era, are embedded
with values and practices
that differ from those of
African people. While
systems might be customized
for African contexts, they
are founded on non-African
values and practices.

January + February 2010

[ 4] Bourdieu, P. The
Logic of Practice.
Stanford, CA: Stanford
University Press, 1990.

interactions

defined by Western readings of modernity and
development; movements from Negroism and
Pan-Africanism to the contemporary African
Renaissance call for vocalizing an African cul-
tural identity in learning. But, at least within
IT, students are at the mercy of achieving their
aspirations by accruing, as Bourdieu would argue,
the educational and cultural capital determined
by the elite of the West [ 4]. It is not that students
and professionals do not recognize the incompat-
ibility of the imported standards, propagated in
textbooks and professional practices, with African
contexts. However, the capital they gain through
education and professional pathways means that
they do not privilege voicing dissent, such as
when faced with systems that are being globalized
via short visits by non-African IT experts. IT stu-
dents and professionals know only too well that
things work differently in Africa. Consider the
following banal incident, one of us experienced, in
a country considered to be one of the more devel-
oped in southern Africa:

After reserving, but having not yet paid for, a bus
operated by a major company from a regional city to
access a rural research site, problems ensued. While
previously unproblematic, on this particular day the bus
office’s electronic ticketing system was down, which
created a trial of actions simply because clerks at the
regional offices were unable to handle cash payment or
manually process credit cards. Thus, payment required
finding and then taking a taxi to the bank to draw a
bankers order, then to a fax office to fax the receipt of
the bankers order to the bus headquarters. It would
seem the designer of this system had not balanced the
constraints of permissions of the regional office clerks,
probably associated with employee trust or security, and
the highly likely event of compromised connectivity, due
to electricity cuts, etc. The consequence would not have
been affordable for the ordinary African passenger.

Situations of the type are common in many African countries and may be acerbated by poverty, corruption, and cronyism. However, they are not the type of constraints and consequences that appear frequently in HCI and systems-design textbooks, nor those that a prospective employee might feel comfortable raising during an interview, especially with an international consultant.

Students and professionals certainly recognize dissonance and cultural gulfs in their relationship with the values that construct and shape gathering requirements and design and usability methods, as well as the constraints shaping the digital environment. For instance, students show a genuine recognition of the paucity of certain instruments for collecting reliable data, in particular, the questionnaire. Class discussions reveal their representative strategy of filling a questionnaire with the expected correct answers, independent of their personal opinion. Yet in HCI examination papers or project proposals, students repeatedly recommend these very same instruments, “because it’s in the textbook.” It is no surprise that when students enter professional life, perhaps collaborating with international consultants, that again they will support inappropriate methods in requirements gathering and usability tests. This is despite an intimate appreciation of the values (e.g., consensus, reciprocation, and economic pragmatism) that drive participants to try to determine what might be the “correct” response on a questionnaire.