The ICT4D Jester

The Jester has recently been involved in a number of ICT4D classes. These are all well-meaning courses with respected faculty teaching them. They are also all located in the United States. For anyone hoping to teach practical ICT4D skills, such as design or entrepreneurship, this latter point immediately brings up a question: How does one teach practical ICT4D skills at a university that is inconveniently located thousands of miles from Africa?

In this post, the Jester discusses interventionist projects in which the goal for students is to design or prototype technologies, or to write business plans or grant proposals for new ideas. (Note that this post does not discuss academic ICT4D, in which the goals are to cram student brains with language-obfuscated journal articles and to teach them to spout incoherent jargon. That can be effectively done in a classroom even on Mars.)

As a problem faced by wealthy professors teaching rich kids at elite universities in developed countries, it might not be among the most pressing of issues in development, but since these courses are often the first indoctrination of the next cadre of idealistic changemakers, it seems important to set them off in the right direction.

The wrong direction is to make young impressionable minds design solutions for environments that they don’t know anything about while sitting in first-world classrooms and libraries, and then to pretend that they’ll have learned something useful without actually implementing anything on site. This all-too-frequent exercise in ICT4D design and business classes, is effectively asking students to practice what the Jester calls Blind Man’s Design: Attempting to solve problems one’s never encountered for people one’s never met in places one’s never been to. Blind Man’s Design is a lot like White Man’s Burden – arrogant, misguided, and ineffective in bringing about meaningful learning. Actually, it’s even worse if a lucky good idea comes out of these exercises, because students then learn the wrong lesson – that you can devise good ideas in development without a clue.

The right direction is to ensure some sort of immersive experience, ideally where sincere attempts are made to implement ideas “in the field.” The best designers and the best entrepreneurs have great intuition for their customers. How does a person develop good intuition for an environment she’s unfamiliar with? She spends time in the environment. She gets to know everything she can about it. Most importantly, she feels its vibrations until she can tap the rhythms herself. That can lead to a good gut feel for the “real” problems and for real demand, as well as the myriad constraints that a design has to navigate. There is simply no substitute for good intuition in design, and there’s no substitute for time spent physically in the environment to gain good intuition. Anyone who says there are even reasonable approximations to firsthand experience has a bridge to sell.

In particular, the Jester notes that reading case studies of successful design-for-development doesn’t count as knowledge (even if they’re written by as august an intellect as the Jester!), any more than readers of books about Google have real insight about what it takes to be the next Larry Page. Steve Jobs never took a formal course in design, and Bill Gates never finished college. What they know, they learned directly from their personal interaction with their market. Mathematics students have to do proofs on their own; English literature majors have to read actual literature; budding anthropologists have to spend a couple of years living among the natives – why should ICT4D intervention be any different?

Unfortunately, not every ICT4D course conducted in a wealthy country can afford to send all of their students to a developing country for an immersion experience. There are constraints of money, time, and other classes. Plus, not every student taking such a course will be committed to seeing an intervention through.

The problem is not, the Jester stresses, that someone who’s never been to a poor community could never design something valuable for that community. Exhibit A is the mobile phone, which was more or less fully formed before anyone considered them for poor communities in developing countries, and yet it’s perhaps the most successful ICT4D ever (the Jester believes this fact will hold even until his death). Sometimes, good design for rich human beings has value for poor human beings. No surprise – good design is good design, and poor people are people, too. But, if the goal is to nurture generically good designers, presumably there are generic design courses for that.

No, the problem with Blind Man’s Design in ICT4D courses is that it reinforces the bad habit of rationalizing decisions made in the absence of real data. This is a cardinal sin in development. Better to admit you don’t know and that you’re guessing. The Jester sometimes repeats himself when he worries that people didn’t hear the first time: The problem with Blind Man’s Design in ICT4D courses is that it reinforces the bad habit of rationalizing decisions made in the absence of real data and experience.

Design projects inevitably include phases where faculty and students whittle down brainstormed ideas, discuss them, critique them, or attempt to pick “the best” idea out of a bunch. If done by people unfamiliar with target environments, all this does is to reinforce everyone’s badly formed preconceptions, as the Jester has seen in student competitions where teams defend their Blind Man’s Designs to probing judges whose own credentials in ICT4D intervention are questionable. This is often worse with the brightest students, because bright students are spectacularly good at rationalizing in the absence of data. Inevitably, this kind of interaction teaches people to get attached to their own bad ideas, to become proficient at defending baseless decisions, and to believe that a made-up justification is better than acknowledging, “I don’t know.” That’s how the road to hell gets paved.

Many professors who teach ICT4D courses have had years, if not decades, of formal training in buzzwords like “appropriate,” “contextual,” “ethnographic,” and “human-centered,” all of which place a premium on knowing the customer right down to how many hairs they have on their left pinky knuckle. Many instructors also realize – deep in their hearts, if not in their syllabi – the hypocrisy of having students design solutions for groups they have never even interacted with. Yet, they feel compelled to run these courses – maybe they feel it’s the most they can contribute given their own expertise, station, and the golden handcuffs of academic tenure in a developed country. So, what is a well-intentioned teacher to do in the absence of a healthy travel budget? Here are some practical ideas from the Jester, for what could be done in lieu of a Blind Man’s Design project…

• Do a project for a local, poor community. Of course, the reality of poverty will be different from place to place, but the methodology of how to go about it, and the experience of unexpected challenges will all apply. Important meta-lessons can be learned. As a bonus, a recurring class can develop an ongoing relationship with local partners. The Jester applauds Keith Edwards at Georgia Tech for going this route.
• Run a wacky design project or an entrepreneurship project, without a focus on “D.” Again, there are meta-lessons in design and entrepreneurship that are worth gaining through direct attempt, rather than through bookish learning. Tina Seelig of the Stanford Technology Ventures Program has some great ideas along these lines. With some cleverness, they could probably be bent to have a little more of a “D” element. The project goals could be less about revenue and more about positive social impact, for example.
• Establish ties with development organizations “on the ground” who have need for the kind of skills the course is attempting to teach, and let students do projects for them. The important thing is that the partner organization has enough understanding of the problem context, that it has the ability to provide real direction and feedback. There’s no point in taking on an outsourced design project from an organization that is itself at arm’s length from the problems. Likely, the more the project is specified by the organization, the better – while there will always be room for creative input, well-spec’ed projects are hard to find.
• Take ideas generated elsewhere, and ask students to come up with questions that they’d have, if they were to undertake the projects themselves. Push them to ask any and all questions. The important thing here is to keep the focus on asking questions, and not on answering them. Any attempt at answering them without firsthand experience will, again, be brittle and empty.
• If it’s absolutely critical to do a complete design/plan project (the Jester doesn’t understand why it should be, except that some academic tradition demands it), put the emphasis on the degree to which the students arrive at the right kinds of questions, and their strategies for answering them. When they make design decisions, stress that they are only guesses, and that what’s important is that they are explicit that they are guesses. Perhaps allow students to arrive at multiple designs, based on multiple possibilities. Don’t even bother trying to comment on the quality of any answers however they get them (unless it’s through actual trial and error at the location). Ask students to explicitly include words like “tentative” and “preliminary” in the title of their projects and throughout any documents they write. Grade students based on their thoroughness in asking questions, and plans for how to get them answered, as well as their explicit admission of decisions made tentatively and with suboptimal knowledge. Deduct points when they make assumptions they shouldn’t be able to make. Resist the great temptation to articulate judgements about the likelihood of the idea working, even if the idea stinks — the problem is that that then pressures students into trying to come up with good ideas on the basis of poor knowledge, instead of thinking through questions and the plan of attack.

All of these suggestions avoid what the Jester believes to be the big no-nos: to have students design their own ICT4D interventions prior to immersion, to build prototypes or business plans which they then rationalize and justify with nothing other than secondhand information, and possibly to have those projects critiqued and judged by faculty or “experts.” The reality is that no one knows whether something will really work or whether it’ll meet all the constraints until it’s tried in situ, not even when endowed with a spectacular intellect like the Jester’s. Why, then, reinforce such a pretension in class?