Designing digital systems for developing regions can be an immensely rewarding experience. Working in areas where there is little digital infrastructure affords the designer the opportunity to have a large, positive impact with relatively small interventions. Of course, with a nonexistent digital infrastructure, the design challenge can be immense. Much has been written in this forum and other venues about the challenges of working with low-literacy users from different cultures in difficult situations. What is infrequently discussed is the logistical issues in funding, running, and completing these projects.
Typically, projects are situated within a community, with the goal of creating a technology to meet some need. These needs can be as simple as network access, or as complex as systems for health care management. Projects can be rural or urban and can last from six weeks to six years. Project ideas can come from the community itself or be driven by the agendas of funderswhether commercial or governmental.
Here, are six issues our research group has faced in running these projects. This list is written from an academic perspective, as we are based in an academic institution, but the underlying difficulties are just as relevant in the commercial sector.
In all our projects, it has taken us two to three years to build some sort of working relationship with the communities we wished to engage. It takes this amount of time for the community members to become comfortable with our presence, start making comments, and share data that proves useful in our designs.
It is easy to forget that not only do these communities have little experience with digital technology, they also have no concept of research or universities. Introducing oneself as a researcher from a university will often be met with blank looks. I once tried to conduct some research in a remote Zambian village and was trying to explain who I was and what I was doing. In the end, the best I could do was say that I was a teacher working on a class project. Not strictly accurate, but correct in intent.
So until several years have been spent building a relationship, we have found that communities shy away from researchers and give overly terse answers (suspicious of our motives), or are overly helpful and tell us what they think we want to hear (in hopes that we will stay and bring some benefit to their community). In attempts to overcome these problems, we have worked with NGOs already familiar to the community. However, depending on the NGO, there can be a long period spent on building trust with that particular NGO, a group cautious of outsiders working within a community with whom the NGO has already fostered strong links.
Regardless, if you are planning this type of project, you should expect not to get any useful data for at least the first two years.
Introducing digital technology to an environment where none has existed previously is a big design challenge. Taking into account the previous point, the systems you are likely to design in the first few years of the intervention will almost inevitably fail. However, creating an initial system is a necessary step, and until some concrete prototype exists, it is hard to adequately explain what you are trying to create. Once a system is in place, the trust is also likely to increase as the community begins to understand your intentions.
Creating an initial system is a necessary step, and until some concrete prototype exists, it is hard to adequately explain what you are trying to create. Once a system is in place, the trust is also likely to increase as the community begins to understand your intentions
Most funding cycles I am involved with tend to run for about three years. The upshot is that only in the last few months of the project are there any encouraging results. We are often in the position to do something really worthwhile just as the funding runs out. One case involved building a telehealth project. It was only when we had built a working prototype in the final year of the project that we realized we had misinterpreted the ethnographic data and created the wrong sort of solution. Fortunately, we were able to get funding from another source and continue building the system we should have built in the first place.
A number of strategies might help to overcome this long startup period and keep funders happy. The simplest is to spend the first year of the project installing basic infrastructure: a mesh network, for example. This shows the funder (and the community) that things are moving forward, and you can start to explore the interface design issues as the basic infrastructure is laid.
Alternatively, you can work with a community that has experience with other researchers. This will shorten the lead time, but it leaves the current project open to bias from the previous research.
Most developing-world issues involve situations and expenses that seem incredible to anyone funding this research. As I've experienced in Africa, equipment is often stolen or broken in unlikely circumstances. We have seen large solar panelssome several meters longand deepcycle batteries disappear overnight. We have had white ants eat the motherboard out of a computer (they chewed the green circuit board to make a nest over the power supply, leaving behind a delicate lace of copper tracks). On another occasion, we encountered a village where it was customary to offer the village head-man anything that was given to others living in the village. So, when we gave computers to people working there, we had to budget to give one to the head-man as well.
Most of our research is carried out by postgraduate students, who work for two or three years to complete a higher degree. This obviously causes issues with establishing trust (the student is ready to graduate just as the community starts to accept him or her), but the nature of these projects further delays their graduation schedule.
Most of the students I work with hail from computer science departments. Most computer science degrees do not require any field work, so students are judged on the quality of a system they build from two or three years of working in a laboratory. Students working on development projects not only have to design and create the computer systems, but they must also spend a great deal of time in the field (often remote from the university) trying to manage logistics, build trust, and gather data. This is usually conducted in areas that do not even have reliable electricity supplies.
Fortunately, most of the students who undertake these projects are passionate about their work and are happy to undertake the field work. However, they do suffer in comparison to the peers who can dedicate their whole effort to artifact creation.
Technology can be seductive, at least for engineers. Often, when starting a project, the expectation is that some new piece of technology will be created. The most successful of these projects, however, tend to involve doing something new with technology that already exists in the environment. Frontline SMS is a nice example of this (www.frontlinesms.com); it allows for a laptop to use existing cellular networks to send bulk SMSs, then record and reply individual responses to those SMSs. It has been used in everything from education to coordinating elections, creating new solutions without the need for more technology. Thus, it's not always necessary to produce a new form or type of technology in developing nations; often, what the locals desire and need most is simply an appropriate application of existing technology.
It can be difficult to know when a project comes to an end. The project can terminate due to external factors (such as a withdrawal of funding), but because the insights can be so rich, it seems there is always more to be learned. Also, in this type of exploratory project, it is impossible to set performance criteria that could be measured quantitatively to provide a benchmark of success.
Ironically, hardest of all is when the project is a runaway success. In this type of project, the system is adopted by the community and becomes essential to its functioning. Ethically, one cannot walk away and leave the community unsupported. It may be possible to productize such a successful system so that the community can continue to use a fully supported system, but this is likely to take a year or more. What happens to the community in the meantime?
In doing research of this nature, we believe there is a strong ethical requirement to properly plan for the end of the project. One must either be clear from the outset about the project's lifespan or have mechanisms in place for continued support of any system that a community comes to rely on.
These are just some of the issues that crop up whenever those of us engaged in development work get together at a workshop or conference. Everyone has their particular war story, and no one seems to have clear answers. Despite this, the number of people working on development projects seems to grow each year. Consider that in 1999 there was one paper at CHI that had a development focus, and in 2009 there were at least a dozen that could be considered to contain some aspect of development. As ICT reaches into new regions, there are a growing number of designers and HCI researchers trying to ensure that these technologies are as appropriate and useful to their target audience as possible.
But I believe it is time for our community to face up to these issues reported here and realize these are the real challenges currently facing the field. Our discipline has been successful in solving the problems of interaction at a micro level, but now I think we need to ponder the macro issues that introducing ICTs can create.
For instance, the notion of long-term engagement with users is critical. When conducting micro work, our engagement with the users was fleeting and ephemeral. When we worry about macro impact, our engagement must be long term, so we must plan for long-term funding and building trust with our users. Already, the living-labs methodology shows us how this might be possible.
As educators and researchers, we need to work toward an understanding of how to reward the effort that students put in to these projects. As practitioners, we must understand that we need to spend substantial amounts of time with our users in order to create something that is of real value to them. As a community we need to establish models for what might constitute an acceptable level of work in a macro research project. Within computer science and engineering in particular, the expectation that a new piece of technology needs to be created is particularly unhelpful.
In the end, I think this is a tremendously exciting time to be working in interaction design. Our field is maturing and moving beyond solving the puzzles of individual interactions. Instead we are looking at the impact of designs on societies across the globe.
The ideas expressed here are essentially a synthesis of opinions and ideas that I have tried to collate into one article. I am indebted greatly to my colleagues at the University of Cape Town, the Meraka Institute, and the members of the UK Bridging the Global Digital Divide group.
Gary Marsden is currently employed as an associate professor in the department of computer science at the University of Cape Town in South Africa. He was born in Ireland, studied in Scotland, and had his first job in London. Although his background is in computer science, moving to South Africa has forced him to reconsider his views about technology in general and HCI in particular.
These ideas have been expressed as "situated interaction," Harrison, S., Tatar, D., and Sengers, P. "The three paradigms of HCI." In Alt. chi. Proceedings of CHI '07. ACM Press, New York, 2006; or as a frustration with "usability," Greenberg, S. and Buxton, B. 2008. "Usability Evaluation Considered Harmful (some of the time)." In Proceeding of the Twenty-Sixth Annual SIGCHI Conference on Human Factors in Computing Systems. ACM Press, New York, 2006: 111120.
©2009 ACM 1072-5220/09/0500 $10.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 © 2009 ACM, Inc.