Forum: under development

XIV.4 July + August 2007
Page: 12
Digital Citation

User-centered design for development


Authors:
Indrani Medhi

Over the past two years that I have spent designing user interfaces for illiterate people in underserved communities, the most important lesson that I learned was to unlearn certain preconceptions about user-centered design.

Two years ago, fresh out of graduate school, I believed in meticulously following the design processes and standard evaluation methods I had just mastered. But since then, I’ve discovered that more important than any particular process is the sheer time spent with the people I was designing for or with during initial investigations, during prototyping, and during usability testing. Immersion in a community allowed me to gain intuition and a sense of its culture in a way that is difficult to realize through process alone. It is this cultural understanding that is of foremost value to key insights. Of course, processes have their place, but almost always with adjustment to the cultural context.

Together with my colleagues, I have been working on text-free user interfaces for illiterate and semi-literate users. The goal is to devise and implement design principles such that a illiterate person can, at first contact with a PC, immediately realize useful interaction with minimal or no assistance. Through an extensive ethnographic study involving more than 300 hours and 250 people from urban slums in Bangalore, India, we arrived at several design principles that we believe could apply to many illiterate groups new to computer use. These design principles include avoidance of text, use of unabstracted cartoons, voice feedback for all functional units, a consistent help feature, and full-context video to dramatize the intent and mechanism of an application. Our usability tests with illiterate users show not only that text-free designs are preferred over standard text-based interfaces, but also that they go a long way toward our goal of value for the user on first, unaided contact. So far, we have applied these principles to designing three applications—a job-search application for domestic helpers, a map-navigation system, and a health-information system for patients. I present some of our experiences below.

Gaining access into a community and building rapport

The first important step in spending time with any unfamiliar community is to gain access to one. In our work, we collaborate with nonprofit organizations to do this, as they have done the hard work of establishing trust with communities. The trick is to identify an organization that finds our research relevant, so that the relationship is mutually beneficial. In our case, we found an organization, Stree Jagruti Samiti, which had worked for 15 years with slum residents to improve their working conditions in domestic labor. SJS was interested in our research with illiterate users, and they in turn helped me work within the community—they were invaluable in helping arrange interviews and conduct user trials.


Differences in religion or culture can cause unintended interpretations, especially in UI work.

 


One of the challenges was establishing rapport with community members. In addition to frequent visits (two or three times a week), I took various actions to put our "subjects" at ease. (It seems strange to call these folks "subjects" as I have since become friends with many of them, but for the sake of exposition, I will continue to use the term.) Wealthier outsiders are frequently treated with undue respect, and I struggled to minimize these social barriers. I refused their offers to sit in chairs, as they all sat on the floor; I dressed in the same type of traditional clothing that they wore, spent time listening to their stories, and attended the community’s weekend meetings. For the first few months, I was always accompanied by SJS members, but eventually, the community felt comfortable working directly with me.

Paying attention to subtle details in social, religious, and cultural affiliations

Once rapport is established, time spent testing prototypes with potential users is critical. Differences in religion or culture can cause unintended interpretations, especially in UI work. For example, in representing start and end times for work in our job-search application, we discovered that two clocks side by side may be read differently by different groups. Muslim culture views time as flowing from right to left by default (probably because Urdu and Arabic are written from right to left), so I added an explicit arrow between our start and end clocks to ensure there was no misunderstanding (see Figure 1).

Iconic representations can also be misinterpreted due to cultural differences. For instance, my initial graphic for a residence is shown in Figure 2 (left), using what I thought was a universal symbol for a home. Our subjects, however, perceived it as a village hut and were confused because they expected that prospective employers would live in urban apartment complexes; with their feedback, I redesigned this graphic as shown in Figure 2 (right).

It is in identifying such culture-based differences that formal design processes can be handy. In our health-information system, we use graphics of medical symptoms. To design these, we needed input from our target community. Two techniques were used to elicit the appropriate gestures from our subjects: (a) 2-D paper dolls—where the participants were asked to depict a given symptom using the dolls; (b) enacting—where the participants were asked to enact the given symptom without using verbal communication. As an example of the value of such exercises, consider the case of illustrating "weakness of the body" as a medical symptom: Whereas I imagined a man feeling dizzy, holding his head, and almost fainting, the subjects identified weakness with physical pain in the limbs, which, in retrospect, is consistent with the fact that their occupations involve hard physical labor. Weakness, a daily occurrence, was always associated with physical pain.

Issues beyond strict usability

There can be other fundamental issues that might not strictly be issues of "usability," and again, intensive time spent with subjects is critical in discovering these. During usability tests, we observed that in spite of our subjects’ understanding of the UI mechanics, they nevertheless failed to complete tasks. What emerged were barriers beyond illiteracy in interacting with the computer: lack of awareness of what the PC could deliver, fear and mistrust of the technology, and lack of comprehension about how information relevant to them found its way into the PC. Ultimately, we addressed these challenges with a "full-context video" that provides not only instructions on how to use the application, but also a dramatization with actors role-playing the value of the application and the means by which the relevant information finds its way into the computer. (In our experiments, full-context video improved the success rate of task completion for a job-search task from 30 percent to 100 percent.) This was another simple solution in hindsight, but one that came only because of our time with our subjects: We knew they regularly watched soap operas and movies on TV and that they related to drama. In contrast, the traditional instructional videos that we had started with (consisting of over-the-shoulder shots of the screen) were of only marginal benefit in raising task-completion rates.


The "Bollywood Method" embeds tasks in dramatized stories to motivate subjects.

 


Adapting evaluation techniques

In most user studies, subjects are generally familiar with computers and live in economic conditions similar to those of their testers. Because of this, tests can be conducted in usability labs with controlled environments, and little attention needs to be paid to the mental comfort of the subjects. In our case, however, our subjects were not habitual PC users, and more important, they came from communities where air-conditioned office environments are alien and possibly intimidating. Thus, we needed to make a number of modifications to ensure that subjects were as comfortable in the environment and testing scenario as possible. First, in all cases, we performed the testing in a physical setting that was routine for the participants. In most instances, we visited subjects in their own homes or at the SJS office. Second, for all of our participants, we reached out through contacts that they trusted and who were, in almost all cases, present throughout the study. Third, while most user studies tend to focus on isolated tasks, we found this was inadequate, as subjects had a poor understanding of the capacity of the computer overall and almost no sense for what kind of tasks could be accomplished. We used a methodology termed the "Bollywood Method," developed by Human Factors International, in which tasks are embedded in dramatized stories involving the subject; this methodology has proved successful at motivating subjects toward the desired tasks.

User-centered design in the developing world requires innovations in design processes, tweaking established processes to fit the context. It is essential for a designer to spend as much time as possible engaging with potential users, all while keeping eyes open to cultural differences.

Author

Indrani Medhi
Microsoft Research India
indranim@microsoft.com

About The Author

Indrani Medhi is an assistant researcher in the technology for emerging markets group at Microsoft Research India in Bangalore. Indrani completed her master’s degree in design from the Institute of Design at Illinois Institute of Technology in 2005 and received a bachelor’s degree in architecture from Visvesvaraya National Institute of Technology in 2002.

Figures

F1Figure 1.

F2Figure 2.

©2007 ACM  1072-5220/07/0700  $5.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 © 2007 ACM, Inc.

 

Post Comment


No Comments Found