Edwin Blake, Meryl Glaser, Adinda Freudenthal
If Amartya Sen  is right to view poverty as capability deprivation, then empowering marginalized communities through information and communications technology (ICT) can play a big role in poverty alleviation. Unfortunately, ICT for development (ICT4D) projects have a notoriously high failure rate. As Richard Heeks says in his blog, “Good data on success/failure of ICT4D projects is embarrassingly limited, and more historical than recent” . ICT4D researchers tell many anecdotes to support this assertion; we have our own.
In dialogue with colleagues we have developed a method of community-based co-design (CBCD) [3,4] in response to this situation. This is now to be taught to computer science (CS) students who have the essential technical skills but are not trained in working on ICT empowerment projects. It turns out we really have to bring about a major mind shift in our students.
The strength of CS training lies in “abstracting away” from details. This is necessary because of the multi-leveled complexity of an ICT-based solution space. Students are taught to move quickly from seeing the trees to perceiving the forest. Once they have the big picture, they move fluidly between levels of abstraction in the digital domain. This provides them with impressive skills for problem solving, solution design, and implementation.
Powerful as it is, the leap to abstraction is an obstacle to co-design if it is done prematurely. Design decisions have to be kept in abeyance while all interlocutors reach a common understanding of the issues to be addressed and the potential of an ICT intervention to help address those issues. Designers simply have to tolerate the tension of uncertainty; to do otherwise is to jump to incorrect conclusions and to damage the reciprocal trust between participants by appearing arrogant and disrespectful.
Here, we report on the approach we recently adopted in a short course to convey CBCD to CS students and reflect on our experience, that of our students, and of our co-designers in the community. An important contribution is to show the mind shift we facilitated with the students and how that came about.
While our design method is general, the course we are describing took place within a specific context; it always does. Our multidisciplinary group works with a grassroots NGO, Deaf Community of Cape Town (DCCT), which is staffed by Deaf people and serves the needs of the larger Deaf community. (Deaf with a capital D denotes membership of a cultural, linguistic group that uses South African Sign Language (SASL)—deaf with a small d refers to a medical condition of hearing loss.)
DCCT arose in response to the dearth of services and support for Deaf people from mainstream sources. Most Deaf adults are semi-literate due to poor educational practices. Many are unemployed or underemployed in menial jobs. This adversely affects the socioeconomic level of the community as a whole. Over the years we have worked with this community, the technology we introduced has been appropriated and sustained for advocacy and empowerment.
As part of our long-term relationship with DCCT, we were conscious of the need for reciprocity, so if they helped us to educate a large group of students then the community would also have to benefit.
We gradually developed the community-based co-design (CBCD) approach with DCCT and with other communities in which we are active. CBCD grew out of a synthesis of participatory design and action research. “Community-based” conveys that we deal with groups of people rather than individuals. “Co-design” derives from the application of the action research paradigm in a design setting: Both the computer experts and the community members are designers on an equal footing and work cooperatively.
Designers need to bridge cultural differences and enter into design conversations with people who do not have technical skills but who are knowledgeable about their own needs. In many ways the Deaf community provided an ideal training in cross-cultural design because none of the students knew any SASL and all carried some incorrect notions about the community.
In every design situation, there are many communities: the elders, the youth, women, migrants, and so on. Each of these must have a voice in design; for that to happen, designers must be trained to recognize groups of stakeholders, identify gatekeepers, and consider how all the diverse needs might be investigated.
Once stakeholders have been identified, a common design language (or metaphor) must be developed. With sophisticated users and simple technologies, this language can be based on paper prototypes, since such people can readily imagine how this might work in an ICT artifact. Where a common understanding of the potential of technology does not exist, co-designers have to be given insight into the possibilities offered by the technology through prototypes implemented using that very technology. It is a serious mistake to commit to a design solution before the co-designers have found their voice. We have to train students to keep their own design decisions on hold and to cultivate an attitude of openness.
A Computer Science Course in CBCD
Our fourth-year module (about 72 hours spread over six weeks) covered our new approach, and, unusually for CS, we exposed students to fieldwork. It seems impossible to learn any method based on action research inside a laboratory. Students were anxious about this atypical activity and needed support. Action research arose out of cyclical engineering design approaches, and we can refer students back to their own training in agile software engineering as a form of scaffolding.
We built an understanding of the community and discussed cultural sensitivity through lectures and group exercises. We gave practical guidance, for example, how to communicate effectively using (sign language) interpreters. Student groups made a mind map representing their newly acquired understanding of the key stakeholders, and they identified any gaps.
Work then progressed cyclically, and at every step we encouraged reflection, which we initially facilitated. Reflection was followed by preparation for the next round of activities.
The first focus group session with staff members of DCCT was conducted by the students. Several students reported anxiety about this since they had never before worked with any clients—at best with fellow students representing clients. The aim here was to discover community needs and wishes. It became clear that the community wanted a website.
Following facilitated reflection, the students made some preliminary global design choices and assigned roles to teams. The next day the students went into co-design sessions with DCCT members. They found that their paper prototypes worked only with the few people who had used computers before.
Ten days later, and after further co-design, the students presented a functioning prototype to DCCT. The response was positive and encouraging. DCCT staff members were impressed by how fast the students had delivered a working system. They engaged constructively on aspects they liked and features they wanted changed. Interestingly, there were many spelling errors, which immediately subverted any perceived power arising from the students’ superior education. Once they saw how easily a student changed something in the prototype, they felt encouraged to ask for more changes.
Following further reflection and report-back meetings, the final prototype was presented to DCCT staff after about a month. We had committed from the start to employing a few of the students to produce a robust deliverable during their vacation. The students knew what they were designing would actually be used.
The students were assessed on group reports and individual reflective essays. Here, we report on these outcomes and on our own and DCCT staff’s reflections.
Reflective essay by the students. We asked students to address the impact of the objectives of the course and culture they worked within. This was probably one of their first experiences doing design in a realistic situation. We emphasized ethical and professional issues and they were asked to consider those, as well as sustainability of the outputs they produced. They were also invited to look at their own growth as professionals.
The following comments from the students’ reflections give a qualitative sense of how the course went. They weren’t always comfortable, but they found it very exciting. Many realized in hindsight that they had prejudices about Deaf people and felt superior in their design capabilities.
Impact of fieldwork. The fieldwork aspect of the course was widely recognized as the most exciting and challenging in a module that “promised interaction with real world users of a system.” The student wanted exposure to “working with people.” There was a shared sense that they were doing something real: “I liked the interaction with real users who actually had a stake in the project I was involved in (i.e., not just some mythical persona).”
“CBCD was a fruitful exercise in exploring computer science beyond the textbook.”
Struggling with uncertainty. As we have remarked, the uncertainty of requirements and outcomes was very different from the controlled lab exercises the students had mostly done before: “But this CBCD course taught me that the aim is not to know everything, but rather…to have enough fundamental knowledge to be able to: identify a situation, apply what I already know, adopt, adapt, and get the job done.”
Communication gaps. All students were confronted by a large cultural gap since SASL is so different from any spoken language, and they were completely reliant on the interpreters. There was also a large divide between their technical sophistication and the lack of technical knowledge in the community.
They had to keep levels of computer literacy in mind and could not use jargon because it was difficult for the interpreters to sign and it would not be understood anyway: “This shocked me at first, but later I realized this is because I have been living in a bubble of UCT where everyone is educated, tech-savvy with the latest gadgets and all the tech know-how. Whereas in the real world this is not the situation at all. During one of our meetings I realized that some of the DCCT staff members did not know how easy it was to embed a video on a Web page.”
Delaying design decisions. We believe we successfully encouraged students to delay design decisions and to pay attention when they jumped to conclusions. One student reported about half of all initial design ideas across groups were discarded because they would not make sense to their co-designers. Another noticed “how our assumptions can mislead us. When we started the design process, we focused heavily on the social aspect of the client’s requirements. It was interesting to see how with one mention of some people in the community showing interest in social media, we got a little carried away with the idea of developing a social medium for the DCCT community…. So we just extended our own experiences and assumed the people at DCCT felt the same…. Staff had little or no interest, at least at this point, with provision being made for social interaction technology.”
Integrating the experience. It was important that this course should not be seen in isolation from the rest of their training in CS. The very fact that they were able to produce a working deliverable attests to their ability to implement systems. One remarked, “You gauge the needs, but also consider their input and what is suited to their culture and context. It also required me to draw on my technical background in computer science as well as my design knowledge and integrate the two in a co-design environment which was very different to any environment in which I had previously worked.”
Responses of teaching staff and community members. The intended beneficiaries of the module were the students. We have, however, always maintained that our relationship with any community has to be based on reciprocity, and so it was important that DCCT also benefited from this course.
We were apprehensive about taking computer science students, with their focus on abstraction rather than people, into a community-based learning experience.
In this case, the undoubted technical and design abilities of the students gave DCCT a much desired website. One of the leaders of DCCT remarked that it was “embarrassing for an organization that had celebrated its 21st anniversary to not have a website.”
While we anticipated that students would be anxious when confronted with such a departure from their normal type of course, we also mirrored this trepidation in the lead-up. This was a new pedagogic approach for CS, and we did not know how the process and the relationship with the community would unfold.
In negotiating access and expectations with the community, we relied on previous trust and relationships built up in the years of collaborative work with the community. We knew the people we worked with and knew how to get skilled facilitators such as SASL interpreters.
We structured the course to convey an action-research-based method to the students. In parallel with their cyclical build-up of reflection upon action, we were able to develop our own growing understanding of the pedagogic necessities.
We were apprehensive about taking computer science students, with their focus on abstraction rather than people, into a community-based learning experience. It turned out there are significant advantages associated with the skills of our students. They can knock up working prototypes to help their co-designers who don’t see the implications of paper prototypes, which is often the case in design for development. They can then produce working systems with that same technology. Equally essential for collaborative work, the final product is in exchange for services rendered by the community, making the work truly reciprocal.
We see our primary achievement as that of giving CS students an opportunity for direct engagement with a community where the students could deploy and refine their design skills. Our students were overwhelmingly positive about the experience. They gained much in their personal and professional development. One commented, “[the course] has given me fresh perspective on the possibilities I can do in the field of computer science which I was unaware of before. There’s a huge difference between reading research about co-design and being part of co-design fieldwork with a community.”
The people with whom we worked commended our students on their approach; they felt they were treated with respect and dignity. They felt listened to, not patronized. We believe this is partly due to the humility inherent in co-design practice where we work with equal collaborators whose views are essential in building a satisfying outcome. During the final meeting, DCCT responded in a spontaneous gesture by offering all the students a T-shirt, reflecting their gratitude and pride in their language and institution.
The course involves risks and so will work only in a situation where risks are tolerated. Students may regard qualitative assessment as risky if they are used to high achievement in quantitatively assessed, well-determined courses. The planners of the course also cannot predict the exact events and have to be comfortable with a skeleton schedule, which is populated as the teaching cycles unfold.
A course like this requires interdisciplinary expertise and input. In our case, we had the benefit of a long collaboration across a number of disciplines. There may be little support for interdisciplinary teaching, and so resources and space in the curriculum have to be found in spite of the structures present.
Thanks to William Tucker for providing many of the ideas and infrastructure that made this course feasible, and to Heike Winschiers-Theophilus and Nicola Bidwell for many thoughtful discussions. Our sincere thanks to the staff of DCCT, our students, and the SANPAD program (South Africa Netherlands Research Programme on Alternatives in Development—www.sanpad.org.za) for funding.
2. Heeks, R. Can a process approach improve ICT4D project success? ICTs for Development, Nov. 29, 2011; http://ict4dblog.wordpress.com/2011/11/
3. Blake, E., Tucker, W., Glaser, M., and Freudenthal, A. Case study 11.1: Deaf telephony: Community-based co-design. In Interaction Design: Beyond Human-Computer Interaction, 3rd ed. Wiley, 2011, 412–413.
Edwin Blake is a professor in computer science at the University of Cape Town. His main research focus has been on information and communications technology for development. He also works on user experience as applied to games and virtual environments. His research outputs range from reflections on policy issues to methods for community-based co-design. email@example.com
Meryl Glaser is a researcher and facilitator consulting on Deaf issues in education, language, and literacy. She studied audiology at UCT and subsequently retrained as a teacher, completing an M.Sc. in human communication (specializing in Deaf people) from the City University, London. She collaborates on various ICT4D projects with the computer science departments at both the University of Cape Town (UCT) and the University of the Western Cape (UWC). firstname.lastname@example.org
Adinda Freudenthal received her Ph.D. from the Faculty of Industrial Design Engineering, Delft University of Technology, the Netherlands. Since then she has specialized in user-centered co-design of complex biomedical information systems. Currently she leads the Intelligent Healthcare program as an associate professor. email@example.com
©2014 ACM 1072-5220/14/0300 $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 © 2014 ACM, Inc.