ACM Interactions

Authors:
Kentaro Toyama

---

 

In a small village outside of Madurai in South India, a young woman dressed in a bright blue sari sat cross-legged on the floor, holding a bulky mobile phone above a sheet of paper. She looked a little nervous at first, but as she settled into her task the jitters faded into focused concentration. The woman was part of a trial headed by Tapan Parikh to test the viability of a paper-and-phone system to streamline bookkeeping of microloans. A paper based on the study was published at CHI 2006 [1].

That paper was the first at CHI to present a system designed specifically for international socioeconomic development, and it heralded a new wave of "HCI for development." In 2006, Parikh's was the only HCI-for-development paper at CHI, but that number rapidly increased: three papers in 2007; six in 2008; eight in 2009; and 15 in 2010 [2]. Since 2010, the count has remained steady at around 15 papers, representing as much as three to five percent of the papers at HCI's premier conference.

So, it's safe to say that HCI for development is firmly on the HCI agenda, and now seems like a good time to reflect. Other authors have considered a technical history of the field in some detail [3], so here I'll use a very broad brush to discuss our accomplishments and offer some thoughts on the future of the field.

  Cultural Specificity Versus Human Universality

Niels Bohr is quoted as saying, "The opposite of a great truth is also true." If he was right, one of the great truths of doing work in diverse geographies is that human culture is unique everywhere. We dress differently. We practice different rituals. And in intricately different ways, we display our wealth, creed, status, and personal taste through our digital devices.

The opposite is also true: As human beings, we are all the same. We all have a special bond with blood relatives. We all seek security, recognition, and meaning. And according to the latest mobile statistics—globally 6.8 billion accounts and still counting—we all cherish remote, low-cost, real-time communication.

The HCI community is very comfortable with this great truth, and I think we can be proud that we have embraced both sides of it in our work in the developing world. HCI has long been perceptive of the differences between subcultures, whether it's kindergarten classrooms or knowledge workers at multinational corporations. In our work in the developing world, we have extended that sensitivity to environments in which the majority of adults are non-literate, or where a family's store of wealth is their livestock.

At the same time, we have discovered some HCI universals. For example, in terms of methodology, some variation of the observe-proto-type-evaluate-iterate cycle has been applicable in every geography and every culture where HCI practitioners have worked.

What we're missing, however, is any sense of the line between universality and cultural specificity. For example, some of us believe that every culture is distinctive and that design must occur out of an understanding of special context. Yet these participation-seeking, culture-sensitive assumptions are challenged by the ubiquity of the mobile phone. Here's a device that is without doubt the single most popular consumer technology in history, but its UIs have been dictated by developed-world engineers, many of whom probably never engaged with so much as a focus group. (Of course, HCI ideas have influenced region-specific phone design, but one visit to a developing-world mobile shop demonstrates that these vibrant markets require no such nods to context.)

How do we reconcile with this phenomenon? Designers of mobile phones and other successful mass-market products, such as radios and televisions, have obviously tapped into a deeper well of the universal human psyche. Whether it's common biology or a collective unconscious, we do share inclinations and capacities as Homo sapiens. But that's not to say we are all the same, either.

So, again, the questions are, what is universal and what is culture-specific, and what are the implications for design? As a discipline, we tend to avoid these questions, possibly out of political correctness, narrow focus, or intellectual complacency. As a result, there are very few statements we can make with any confidence about what applies universally and what is specific to culture. Are there generalizable statements we can make about all non-literate people, for example, and if so, what are they? Conversely, what aspects must be tested group by group? We have few examples of studies attempting to answer such questions, and we have even fewer theories that would help us explain and predict our failures and successes. There is room here for groundbreaking scholarship that could have impact well beyond HCI.

As a community, HCI for development is well suited to answering these kinds of questions. Our activist goals provide strong motivation. And we comprise disciplines that span a spectrum: Many qualitative researchers among us insist on cultural variation; many with a quantitative bent seek out universality. The truth is obviously a complex interaction of these viewpoints, but only a field that encompasses both poles is likely to work with the tensions long enough to find out. Of course, it requires a deliberate attempt to go beyond disciplinary dogmas to make progress.

  The Epistemology of Direct Experience

Another area where we as the HCI community do well is in our emphasis on working directly with user communities. I have not yet personally read a published HCI-for-development paper in which at least one author did not spend time interacting with intended users or beneficiaries. Meanwhile, as a paper reviewer for HCI publications, whenever I see studies with no time in the field, the papers are rejected—typically by unanimous reviewer decision. I can't say the same thing for our non-HCI computer science or engineering cousins. They sometimes build systems for a developing-world context based on secondhand knowledge, and papers about such projects are not infrequently accepted. The difference is entirely attributable to the user-focused culture of the HCI community itself.

But before we claim our field's superiority, it's worth considering what we could do better. At the heart of HCI's insistence on fieldwork is a particular epistemology: First of all, we believe that an essential way to gain information about technology users is to observe, interact, and live with them in their actual environments. But it's not enough for one HCI researcher to do this, write a paper about it, and inform the rest of us. Even "thick description" à la Clifford Geertz is a poor substitute for reality. We expect every HCI professional seeking to design for a set of users to have direct personal experience of the context. We have little respect for the designer who is steeped in the literature but has not so much as visited the site.

In other words, books, papers, videos, lectures, and discussion aren't enough. As a field, we believe that something about direct experience is not easily conveyed.

This fact has huge implications for those of us who are in a position to teach, mentor, or advise others about HCI for development. First, anyone who lacks direct experience with a particular environment must be careful that any advising they do is limited to what they truly know. There is nothing wrong with making methodological suggestions, contributing to brainstorming, or acting as a sounding board, but final decisions about design or the interpretation of data should align with those who have deep experience with target users.

If this principle seems obvious, I have nevertheless witnessed gross violations. In one case, a Ph.D. student's advisor forced a paper to be written in a way that contradicted the conclusions the student felt comfortable with. The advisor had never even visited the site of the study, while the student had spent more than a year on location. In another case, I was a guest in a seminar in which the professor vocally criticized a design choice in a paper because it didn't fit with his experience. He had just returned from working on a project in Mexico—his first significant trip outside of Western Europe and North America—and spoke as if he now knew everything about "the developing world." A little learning can be a dangerous thing.

I don't mean to suggest these kinds of problems are rampant—they aren't. Most of the researchers I know are very aware of what they don't know, and all of them push those whom they advise to spend time with actual users. Still, there are subtle ways in which we erode our user focus, for example, when teaching project-based classes of the kind that are common in HCI curricula: Students are asked to pick, implement, and then report on a compact HCI project that usually involves some design and prototyping. Often, each project is presented at the end of the term and students critique one another's work.

To be completely frank, I think it's a mistake to have students do projects meant for communities in another country in the course of a semester during which both teacher and student must remain on campus [4]. (This comment doesn't apply if the campus has easy access to target communities, or if the course involves an extended class field trip to the project site.) If we believe in the importance of field experience, why do we ask our students to defy this recommendation in their first exposure to the topic?

The problem is not that some students might actually come up with a good project idea due to either luck or previous developing-world experience. The problem is the meta-lesson: Students learn in a visceral way that design can be done remotely.

If the intention is experiential learning, there are other possibilities. One is to work on projects that interact with underprivileged communities nearby. Another is to forego the development aspect explicitly, and simply focus on the process of design. Both approaches avoid the problem of design at a distance. Another is to have students design projects, but then focus on preparing questions they would want to answer in the field. Learning to ask the right kinds of questions is a good preparation for budding HCI professionals.

  The Bounds of HCI

Last, I want to discuss a topic that speaks to that part of us that is concerned with meaningful international development. If we're really concerned about development, the proof is in whether we're willing at times to sacrifice HCI objectives for the larger cause.

About a year ago, I was at a conference on technology and development when a colleague asked several of us—all experienced researchers who have worked in HCI for international development—to provide some feedback on a project by one of her students. The student, a master's candidate I'll call Norm, was working with a large international non-profit on a project in an African country. The objective was to keep track of the sales and stock of agricultural goods at local shops so that the non-profit could target specific shopkeepers for training and inventory support. His proposal was to have shop owners send in their sales data via SMS text messaging, and he cheerfully presented a poster about his design options and a usability study comparing them during his first trip to the country. Norm's question to us: Did we have any suggestions on improving usability or on running a more effective trial?

Not knowing a lot about the context, we—the improvised panel—peppered Norm with a range of questions about the shopkeepers and mobile use in the country. Norm answered patiently, deferring some questions for his trip. And then we jumped in with some thoughts. Some of us had had some experience trying to impose record-keeping exercises on people in informal economies and knew that it was not easy to elicit consistency and precision. Meanwhile, studies showed that data collection via text messaging was less accurate than information collected through voice calls [5]. One of us asked whether Norm had considered having a human operator call the shopkeepers for the information, rather than using SMS.

As we spoke, Norm's shoulders started to slouch and a worried look appeared on his face. He acknowledged that it might make sense to have human operators field calls, but there was a catch: Voice calls require little design. That solution would eliminate the need for HCI. What, then, would become of Norm's project?

Norm's dilemma points to one of the great ironies of HCI: Sometimes the core tenets of HCI lead us away from HCI. User-centered design, participatory design, user experience design, and so forth all insist that we should design for, and often with, the user. Specifically, our designs shouldn't inconvenience users or contradict their own preferences.

But potential users don't necessarily do or want things that make for interesting HCI projects. And sometimes their concerns go well beyond HCI. In Norm's case, what was the right response?

First and foremost, it seemed important to investigate user preferences before prototyping. A big problem with Norm's project was that either he or whoever had given him the assignment had assumed the form of the solution before there was any chance to interact with users.

Next, let's suppose he did ask potential users, and that the vast majority strongly preferred voice calls. What then? One possibility would be to run a trial in which voice calls and text messages were compared against one another for accuracy. It's always possible that user preferences don't align with other desiderata, and that's important to know. But unless there was a good reason to suspect that text messaging might do better, this seems like a desperate attempt at HCI relevance.

Sometimes the right thing is to walk away. Not all problems are HCI problems, and we don't want to become the proverbial hammer that sees everything as a nail. This point is discussed concisely in a paper titled "When the Implication Is Not to Design (Technology)" [6]. Admittedly, in Norm's position as a student intern it might have been hard to push back against the combined authority of his sponsors and his curricular timeline. But if there's one thing we should do as HCI practitioners, it's to champion the potential user even against our own interests. If we don't do that, who will?

In the space of just a few years, HCI has found ways to engage meaningfully with international development. We have applied our general approach to problem solving across the globe while being sensitive to situational differences. And we have done so while insisting on the primacy of users and other beneficiaries of technology in contexts where they are otherwise overlooked and marginalized. As a community of practitioners, we can be proud not only that our values apply in challenging circumstances, but also that they align particularly well with the attempt to address the needs and aspirations of the world's less privileged people.

In the future, I look forward to a couple of things: First, it would be interesting to see more deliberate efforts to understand the interplay of human universals and cultural differences, and how it pertains to design. Second, we should continue to strive for greater empathy with potential users and beneficiaries. Whether it's avoiding assumptions about them, teaching the importance of working with them, or, in some cases, walking away from projects they don't need or want, there is much more we can do to be of even greater value to those we aim to serve.

  References

1. Parikh, T. S., Javid, P., Sasikumar, K., Ghosh K., and Toyama, K. Mobile phones and paper documents: Evaluating a new approach for capturing microfinance data in rural India. Proc. of the SIGCHI Conference on Human Factors in Computing Systems. ACM, New York, 2006

2. Toyama, K. Human-computer interaction and global development. Foundations and Trends in Human-Computer Interaction 4, 1 (2010) 1–79.

3. Ho, M., Smyth, T., Kam, M., and Dearden, A. Human-computer interaction for development: The past, present, and future. Information Technologies and International Development 5, 4 (2009).

4. Toyama, K. Blind man's design. ICT4D Jester blog. Apr. 28, 2010; http://j.mp/jesterbmd

5. Patnaik, S., Brunskill, E., and Thies, W. Evaluating the accuracy of data collection on mobile phones: A study of forms, SMS, and voice. Proc. of Int'l Conf. on Information and Communication Technologies and Development. 2009.

6. Baumer, E. P. S. and Silberman, M. S. When the implication is not to design (technology). Proc. of the SIGCHI Conference on Human Factors in Computing Systems. ACM, New York, 2011.

  Author

Kentaro Toyama (www.kentarotoyama.org) is a researcher in the School of Information at the University of California, Berkeley and a fellow of the Dalai Lama Center for Ethics and Transformative Values at MIT.

 

©2013 ACM  1072-5220/13/11  $15.00

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

The Digital Library is published by the Association for Computing Machinery. Copyright © 2013 ACM, Inc.