The benefit of a truly inclusive design process is an end result that is genuinely well suited to the needs of the community
In a rural community in Southeast Kenya, women's Self-Help Groups (SHGs) are the driving force behind a technical initiative that enables women to be heard on community radio. In pre-deployment conversations, these women clearly articulated project features not originally envisioned by the project's ICTD technical 'experts.' In so doing, these women became active participants in community development – as they defined it. Their input also contributed to the development of technical innovations not originally within the project's scope, which were then piloted in the community for the women's evaluation. This inclusive feedback loop sustains interest and participation in the ICT intervention. The authors describe their experience with this process at the intersection of need and innovation, and cite two examples of technical innovation that resulted from this process.
ICT for development projects often follow a common model: an expert has an idea for a technical intervention that will help a community, verifies with the community that the idea is sound and that the targeted problem is relevant, and can now assert that the project has community input and participation. Subsequently, the expert may be disappointed that the community is not making full use of the ICT intervention, or is not using the intervention as envisioned by the expert. The best-intentioned intervention can yield this result – the Internet kiosk meant to provide health information is instead used almost exclusively for entertainment; the text-based service that goes unused because user commands are not sufficiently intuitive; the laptop screen used for night illumination only.
Of course, efforts to introduce new technologies are not intrinsically bad- indeed, more innovation is needed in ICTD initiatives. For example, even with the fastest growing cell phone market in the world, almost half of the African subcontinent does not enjoy coverage. Low literacy, high cost, perceived relevance and cultural impediments can slow adoption of any ICT solution, including the best ICTD interventions. However, we argue that designers of ICTD interventions who fail to listen to the real system experts – the end users – are destined for failure. This translation of community needs into technical requirements goes beyond what is frequently termed 'participatory design.' Indeed, it goes to the heart of innovation. An inclusive design process can yield unexpected innovation, as designers respond to technical challenges introduced by end users who are unaware and unconcerned with the common wisdom of what is considered possible. In this paper the authors share their experiences with these ideas in the context of the AIR (Advancement through Interactive Radio) project.
AIR – Advancement through Interactive Radio
A more concerted and comprehensive The AIR project – Advancement through Interactive Radio – is a system that enables women off the cellular and electric grid to communicate with their local community radio station. AIR allows women to 'talk back' to the community radio station to ask questions, comment about programming content, and create content themselves. This community radio programme can specifically address women's unique development concerns and needs by letting women articulate these concerns, thus enabling women to achieve a greater level of empowerment as they define empowerment. The AIR Project thus explores how technical intervention changes both the individual and their community. The project's first deployment is at Radio Mang'elete in Southeast Kenya. In discussions with the station and its listeners, the authors identified some common frustrations – the radio station wanted to increase women's participation but had not come up with sustainable ways to do so; the female listener base wanted to provide feedback to the station regarding programming content, but did not have convenient means to do so. The authors set out to design, implement and deploy an ICT-mediated solution to this problem. When the authors met with the community to describe their design, the authors found that some features that the community expected to be important were irrelevant to the users of AIR, and some features they considered essential had been overlooked. The final feature set of the AIR device, created by its intended users, challenged the authors' textbook understandings of 'Africa,' 'women,' 'rural,' 'community radio,' 'feedback,' 'user interface,' and 'need'.
However, the experience of the author suggested that a truly user-centric design process, one in which users not only inform, but actually lead the identification of design requirements, offers substantial benefit. Below are two examples of how the user requirements shaped technical decisions as the authors translated these requirements into hardware and software. In some cases, the requested features addressed technical issues that had otherwise frustrated the authors, demonstrating how user-centric design is not just a good principle, but also a potential strategy for technical innovation.
The pilot deployment of AIR is in the three communities primarily served by Radio Mang'elete: Nthongoni (where the station is located), and the outlying communities of Ivongoni and Masongaleni. Ivongoni and Masongaleni are too far from the station to support a standard wireless back-haul solution. The authors considered and rejected a variety of alternatives due to range constraints and lack of power. However, when the authors discussed the problem with the community, they learned that women travel every week to Nthongoni on market day. The authors arrived at a simple solution in which one AIR device in each of the two outlying communities is designated to serve as the primary collection device for that community. These designated devices have expanded voice storage capacity, and are programmed to promiscuously collect voice input from all other devices in range, but otherwise function as standard AIR devices. The collection devices are taken weekly into Nthongoni on market day by women who routinely make the journey to sell their goods at market. The stored voices from the designated collection devices are then transmitted to Radio Mang'elete while the women are in Nthongoni.
The potential one-week market day to market day cycle between recharge opportunities challenged the power design of the AIR device, since the available power from four rechargeable AA batteries was only six volts at 2500 milliamp hours. Low-power high-efficiency components and an efficient switch-mode voltage regulation circuit were insufficient in themselves to provide a week of operation. The required additional power reduction was achieved by having the device enter a sleep mode when not being used to record voice, and to only periodically awaken from this sleep mode to check if another device is in range. If no device is in range, or there is no new information to transmit or receive, the device returns to sleep mode for another few minutes. This sleep interval is increased or decreased based upon observed activity levels and remaining available power.
When deployed in the community, AIR devices are used by women to record feedback and questions about existing programming content, as well as to create their own new content. There are multiple devices in each community, one for each women's work collective, or mwethya. These devices form an ad hoc network in which recorded voices are asynchronously passed from device to device, eventually reaching a device that is (or will be) in range of the radio station.
When a woman presses the push-to-talk button and speaks into the device, her voice is filtered (in hardware) and compressed for storage (in software). The resulting content is then stored. Transmission of the stored voice is accomplished as follows: Each voice message is tagged with a unique field of separately stored metadata that indicates the originating device and message recording time. This metadata is used by all devices in the system to track message status. When a device comes within range of another device, the devices exchange metadata, allowing each device to pull or to push particular messages. The interesting part of this algorithm is how devices decide when to send and receive message content.
Assuming the device has not already processed the message, whether a particular message is transmitted depends upon a probabilistic adaptive algorithm that makes this decision based upon (1) the number of other devices to which the message has been successfully transmitted (the more devices that receive the message, the higher the likelihood that the message will reach the radio station); (2) a measure of device mobility (a historical record of the number and diversity of devices that have been recently in-range); (3) available power (devices will reduce transmission rates when low on power); (4) the number of devices in range (messages need not be transmitted to every device in range), and (5) the state of these devices in range (messages should only be sent to devices that have adequate capacity and power). The parameters that guide these choices are adjusted from their initial settings based upon the device's success in ultimately getting all messages to the radio station within one week. This maximum time delay was collectively decided by the user community. The idea is to use the minimum number of redundant transmissions to other devices (and therefore power) to accomplish this objective. If all messages get through, parametres are relaxed; if the objective is not met, transmission parametres are made more aggressive. The algorithm uses hysteresis to prevent oscillation.
The remaining question is how a device decides to delete stored voice message. As a practical matter, once the radio station has received and stored a particular voice message, that message can be deleted from all devices that store it. However, if devices in contact with the radio station simply deleted the message, more remote devices would not be aware of this fact. The authors originally intended to have all devices purge their message buffer every seven days, but a user-driven design requirement led to a more elegant solution.
The women who were going to use the device wanted to be able to hold the radio station accountable for what it did with user voice information. They asked for an LED that would be illuminated when all of their voice data had reached the station. In considering how to support such a feature, which would clearly involve having information find its way from the radio station back to the device, we arrived at the following solution: When the radio station receives a voice message, an acknowledgement packet is sent to the transmitting AIR device. That device can then recover the buffer memory used to store that message, but the message metadata is retained, so that other devices with which that device comes into contact will receive the acknowledgement packet, indicating that they too can reclaim their buffer memory.
Once the originating device has received the acknowledgement, all AIR devices can delete all references to that message. This is accomplished by marking the message metadata appropriately and forwarding the revised metadata the next time metadata is exchanged. This process will eventually clear all buffers and metadata associated with that particular voice message. When a device has cleared all of its current metadata, it can turn on the 'My voice has reached the station LED.
Principles of user centric design
These two examples illustrate how user-centric design can lead to both more appropriate and technically innovative results. By considering user needs paramount, we achieved a better design from the perspective of all concerned. In this case, recognising how women move throughout the community in semi-structured patterns, consistently attending certain market days, stopping by the same wells and community establishments at fairly set points during the week, resulted in power management and message routing designs superior to those conceived by our technical experts. We recognise once again that ICT for Development truly is a social science. Successful ICTD strategies should understand and adapt to the movements and interactions of the communities that we seek to serve, rather than attempting to train the community to move, act, and interact in a way dictated by the technology.
Suggestions and recommendations
The authors, on the basis of their recent experience on how to create a climate for more effective requirements gathering (which is where opportunities for innovation are likely to be found) suggest the following:
- Follow women of the community throughout their day, selecting these women with as much geographical, economic, age and ethnic diversity as possible. Ask permission to do this, and be sensitive to the potential negative impact on important daily activities. Seek to understand how women interact with their environment, including those things they might wish to change in that environment.
- Participate in daily chores and recreational activities, in order to understand where technology (any technology, not just ICT) is utilised.
- Verify observations by asking a wide variety of people if these observations relate to the actual experience of the community. This is one way to have erroneous assumptions challenged, as well as to highlight the differences of perspectives within the community.
- Discuss prototypes together, once an ICT concept is ready for testing. While drawings are a common method for discussing prototype ideas, tactile examples (such as might be created using molding clay or play dough) may more readily convey certain ideas.
- Play with the targeted technology, to diffuse concerns about use and self-efficacy – and budget for this play time. In the early stages of the AIR project, the authors gave the women's groups digital voice recorders to understand women's willingness to 'talk back.' While the authors tried to conduct a structured training, the women were more interested in recording their voices and playing back the recordings, amazed at hearing their voices for the first time.
- Wait while people mimic the familiar, before expecting that they will generate new feature ideas. After becoming familiar with the AIR device prototype, women were able to recognise its limitations and propose new features based on that familiarity.
- Act upon what is learned. Genuine human need, rather than technology, should always drive the design of any ICTD intervention. Innovation in ICTD requires a clear understanding of both social and technical requirements, and a willingness to let the community fully participate in the technological design.
- Following these principles will contribute to the creation of ICTD solutions that are successful, and innovative, and that serve well the real needs of the community.
In contrast to waning interest as novelty fades, the authors have observed a consistent increase in the engagement of the mwethya members served by the AIR Project. In addition to being active participants in community development, these women contributed to the development of technical innovations not originally within the project's scope. The authors argue that this inclusive feedback loop both sustains interest and participation in the ICT intervention. The authors describe their experience with this process at the intersection of need and innovation, and cite two examples of technical innovation in their current project that resulted from this process.
The critical view that mwethya members have taken during the design and implementation of the AIR system has positively impacted the project from the initial feasibility studies through the evaluation process. These women have apparently made the connection between desired community change, community radio station accountability, and the potential of the AIR system to help accomplish these objectives. The authors are continuing to focus on linkages between voice, feedback, and the technologies that help mediate and support community participation, while enabling individuals to articulate their own unique experiences. Future directions include longitudinal studies of this community, and further exploration of potential feedback mechanisms for Community Radio development initiatives.
|Get a chance to meet who's who of Transport ecosystem in India including key policymakers from Central and State Governments. Join us at National Summit on ‘Strategy for Ports, Highways Infrastructure and Logistics Efficiency , New Delhi on Aug 13, 2018 to explore business opportunities. Like and connect with us on Facebook, Linkedin and Twitter.|