Healthcare IVRS for Non-Tech-Savvy Users

Prasad Girish Rashinkar1, Anirudha Joshi1, Mandar Rane1, Shweta Sali2, Salil Badodekar1, Nagraj Emmadi1, Debjani Roy1, Riyaj Sheikh1, and Abhishek Shrivastav1
Indian Institute of Technology, Bombay, Mumbai 2 iGatePatni {prasad.rashinkar,swetz21,colour,nagrajmumba,debjani.r, riyajsheikh,abhishek.nmd}, {anirudha,mrane}

Abstract. The rapid increase in mobile penetration has cut through the literacy barriers even in the developing countries. It has paved a way for technological interventions in healthcare domain, using the mobile platform such as Interactive Voice Response Systems (IVRS). Over the past few years, IVRS have been looked upon as an intervention in frequent and non-frequent but time-critical health support systems for chronic diseases. We present an IVRSbased solution for a low-resource setting, to ameliorate the problems of People living with HIV/AIDS (PLHA). We discuss the strategy to deal with frequently and non-frequently used menus. We describe a style of interface added especially to meet the problem of selection of multiple and overlapping options. We highlight the use of flat messages (like health tips) and IRV-based quiz to provide information and shape users’ understanding of the disease. We describe and discuss comparative study of usability evaluations of our system conducted with low literate rural users (independent of their HIV/AIDS status) in two villages of Maharashtra (India) in Marathi, the local language. Training provided to the users overcomes the problem of inability of abstract thinking in low literate users. Keywords: HIV/AIDS, healthcare, adherence, user study, IVRS for chronic diseases, IVRS for low resource-settings.



The treatment of chronic diseases such as HIV has moved, at least in part, from the medical and pharmaceutical domains to information and communication domain [1]. At the same time, technology usage has become widespread. Today, it seems feasible to provide personalised healthcare information technology (HIT) services to ‘almost everyone’. In this paper, we investigate the issues related to usability of HIT for supporting treatment of chronic diseases to low-tech-savvy users but exposed to mobile telephony. The growth in mobile phones has been quite recent and dramatic, and has managed to cut through several layers of society in a manner that was quite unexpected. For example, Figure 1 shows the number of mobile phones from Telecom Regulatory
A. Holzinger and K.-M. Simonic (Eds.): USAB 2011, LNCS 7058, pp. 263–282, 2011. © Springer-Verlag Berlin Heidelberg 2011


P.G. Rashinkar et al.

Fig. 1. Mobile, landline, and internet usage over the decade in India [3], [2], [4]

Authority of India (TRAI) [2] and the education figures from the Census in India over the past 20 years [3]. As of September 2011, there are 2.1 billion users of the internet [4] and 5 billion users of mobile phones in the world [5]. That means that there are 2.9 billion noninternet mobile users (NIMU), or about 45% of the world population. The proportion of NIMU is even greater in developing countries. For example, in India, there are 65% NIMU with the mobile phone penetration at 74% [2] and the internet penetration at less than 9% [4]. One implication of the increase in NIMU is that we can potentially provide services such as HIT to a large number of people over the phone. Unfortunately, several challenges have to be met before such services can be realised. The growth of mobile telephony has been recent in developing countries, and several NIMU have limited abilities. They use mobile phones primarily for voice calls. Many NIMU still do not use features such as sending or reading SMS, adding a contact to the phonebook, or looking up missed calls [6], [1]. Many NIMU have limited exposure to other technologies. Many are from rural areas, with less exposure to urban amenities such as banking, public transportation, or entertainment. Many are either illiterate or have low levels of literacy. A majority of NIMU phones do not support custom applications nor do they have a connection to the internet. Some lack colour displays or polyphonic audio capabilities. Interactive voice response systems (IVRS) are perhaps the only common technology that can be used to reach NIMU today. Yet, these too have many unsolved usability problems as we discuss below. In this paper, we investigate several questions related to HIT based on an IVRS for NIMU. The next section discusses the prior work in the area of needs of People Living with HIV/AIDS (PLHA) and problems with IVRS. Section 3 describes the

The solution should support PLHA with different levels of disclosure.1 Background HIV and Technology Interventions Though early on. During the initiation of antiretroviral therapy (ART). while some disclose only to the spouse or a sibling. . optimise the time of the PLHA in the clinic. or to a friend. We also found that PLHA socialise less because of stigma. The choice of a technology platform has significant implications in this ecosystem. and should certainly not cause an accidental disclosure. and manage follow-ups. Given the advances in mobile technology. the system can improve the efficiency of the clinic. A few clear areas emerged where intervention was required: PLHA need support and reminders for daily pill-taking and they need help to track their adherence. rather it should closely complement the ongoing efforts in the clinic. but also develop a conceptual understanding of the same. usercentred interventions in management of antiretroviral therapy (ART) [1]. Section 5 shows the results and the last section presents the discussion and conclusions. We therefore decided to use the IVRS platform for our solution. PLHA occasionally face symptoms such as side effects– systems could support PLHA to report symptoms and look up medical advice. [11]. it would be tempting to develop a solution for phones with a modern technology platform such as Android or iOS. these platforms do not support languages in developing countries. but also can learn a lot from each other. Even if language support could be added and funding could be found to give away such phones. where they can communicate securely. However. Our recent study of the ecosystem of PLHA in private HIV clinics in India establishes that there is a need and an opportunity to make technology-based. Many PLHA need contextual repetition of information since much of it is new to them. Section 4 explains the method of our evaluation. later studies have shown promising results [8]. it could add to the stigma – the new mobile phone model may quickly become associated with HIV treatment. independent activity. [9]. [10]. without the fear of any stigma. secure health records. this would need additional expense for the PLHA to buy such a phone. 2 2. The solution should be grounded in the reality of a resource-limited setting and it should not add to the financial burden of the PLHA. this may not work in resource-limited settings for several reasons. opinions were mixed about whether HIT interventions would work for PLHA in the resource-limited settings of developing countries [7].Healthcare IVRS for Non-Tech-Savvy Users 265 design of our system. There is an opportunity to enable anonymous socialisation amongst PLHA. it would be an intrusion in the life of a PLHA as he or she struggles to learn to use a new device. in another context. We found that PLHA do not disclose their HIV status to their family. On the other side. It is important that the PLHA not only know the facts and procedures about HIV and ART. We concluded that the solution should not be a stand-alone. At the very least. Firstly. Further.

privacy and security were a concern while providing personal information over the IVRS. promoting regular physical activity. a menu could contain symptoms such as fever. in most studies. the users reacted positively to a frequently used IVRS for healthcare. [25]. However.2 IVRS in Healthcare Unlike applications on smart phones. This makes IVRS suitable for conveying health information to wide range of patients. audio is ephemeral. [22]. or informational lectures [12]. Automated speech recognition (ASR) technologies have enhanced the user experience of IVR systems in many languages by reducing the need for hierarchical menus substantially by creating a dialogue. and users cannot remember too many choices presented in an audio form. There could be specific problems associated with reporting symptoms and getting feedback in IVRS. users with lower levels of literacy can potentially use IVRS more effectively than applications that require the users to read text. low-literate users. [18]. For example. improving adherence. smoking cessation. IVRS have been found to be more effective means of collecting sensitive personal data (such as sexual behaviour) than traditional interviews [21]. In some studies. many of these users speak languages that do not yet have a robust ASR technology yet. and vomiting. or mobile services. While evaluating ASR against DTMF touch-tone in IVRS. Rashinkar et al. Further. [16]. IVRS applications can be used ‘everywhere-whenever’.266 P. By nature. [16]. [15]. Conventional menus in touch-tone IVRS could have the problem of overlapping choices for symptoms. and increasing mammography screening [17]. 2. instructions. reports that low-literate users face difficulty in abstraction [23]. which need internet connectivity and specific handsets. it is not clear which option he should select. However. Medhi et al.G. IVRS are relatively simple to realize. [14]. [13]. To overcome this. [13]. [20]. a personal identification number (PIN) has been used to protect the data [22]. none of these studies was in resource-limited settings of developing countries or targeted to lowtech-savvy. It is not clear whether such users will be able to navigate hierarchical menus in IVRS. Though IVRS are often perceived to be associated with occasionally used applications such as travel. If the patient is suffering from both rash and fever. rash. headache. This often leads to a hierarchical menu system in IVRS. Attempts have also been made to provide personalized health-related messages over the IVRS over a long period [13]. Although the IVRS have been used in providing healthcare support. modifying dietary behaviour. touch-tone based IVRS were preferred by the low literate users [24]. Results suggest a positive impact of IVRS on the patients. IVRS were used to deliver recorded messages. Researchers have been using IVRS as a simple and effective way of delivering healthcare information. with choices of 3-5 items at a time. banking. . [19]. reminders. Friedman reports a feasibility study of IVRS in the diagnosis and management of chronic diseases. IVRS have been used to deliver counselling to patients cheaply [18]. which may have specific usability challenges. The users can access such a system with any mobile phone. Users need to be capable of certain level of abstraction before they can start navigating such a hierarchy.

the patient can call the system. realising these opportunities may not be easy. medical advice for common symptoms. relevant information. exposure to technology. .Healthcare IVRS for Non-Tech-Savvy Users 267 Critical tasks in IVRS are often backed up by agents from a call centre. To solve the problem of overlapping menu items. low-tech-savvy patients in resource-limited settings to manage their treatment better. In case the patient does not call the system. behavioural aspects. because it was assumed that probability of such an instance would be rare. In this section. five minutes after the scheduled dose time. low literate. The system presents only three menu options – report that the dose was taken. report a delay in taking the dose. he can select it immediately. and information overload. healthcare to chronic patients in developing countries is often provided by small clinics and nursing homes. rural users so that we can confidently provide HIT services to support treatment of chronic diseases in a resource-limited setting? Which strategies can be used to overcome the issues related to abstraction? How should frequent applications for such contexts be designed? How should infrequent. the system gives the patient a call and presents him a short menu. In this paper.3 Objectives While touch-tone IVRS present opportunities for helping chronic. we describe only the elements of the design relevant to the objectives described in the previous section. we investigate the issues related to usability of HIT for supporting treatment of chronic diseases for low-tech-savvy patients over IVRS. two styles of menus were designed. This input is also used to collect adherence information. 2. This scenario can happen in two ways. At the time of the dose. If the patient has taken the dose. but critical applications be designed? What would be the extent of training required before these users can start using these applications confidently? 3 Design of the IVRS An IVRS was designed to provide daily pill-time reminders and adherence feedback. In the other scenario. the first item of which is to report the dose. which may not be able to afford such a call centre backup. 3. Can we make touch-tone IVRS usable enough by non-tech-savvy. given the usability problems and information-seeking behaviours of such users. The system is protected with a PIN to avoid accidental disclosure.1 Frequent Task – Pill-Time Reminders The system provides daily reminders at the time when patients are supposed to take their dose. The design was prototyped and evaluated through a formative pilot evaluation. and report that the patient is going to miss the current dose. and anonymous socialisation amongst PLHA. The system presents a menu. the options to report a delayed or missed dose is not provided. Issues relate to low education. However.

This task is a frequent activity. .268 P. During an incoming call. This was used to leverage the trust of the patient in the doctor and to emphasise the importance of adherence. In the initial instances of missed doses. the patient is given feedback about the missed dose in the voice of the treating doctor. Additional messages (such as appointment reminders or health tips) are provided after this. The system calls back the patient after a period of 30 minutes. If the adherence drops below a certain threshold. The patient may listen to them. the importance of taking pills on time is reiterated. done several times a day (depending on the regimen). The feedback is titrated according to the adherence status. 2. such calls are repeated until a ‘pill time window’. If the patient delays further. An important design consideration was that this task should be finished as quickly as possible. Therefore.G. In such a case. Fig. After the feedback. or if the adherence of the patient has been otherwise good. Rashinkar et al. all these messages are optional. the doctor’s voice advices the patient to meet him in the clinic. In the last call. the patient is provided with an option to record a reason for the missed dose. The patient may also report a missed dose. In this case. the feedback is gentle. the patient may report a delay in the dose. feedback about his or her current adherence is provided. or may hang up immediately after reporting the adherence. On the other hand. the feedback gets gradually firmer. Pill-time menu navigation If the patient reports that he has taken the current dose. the patient is warned that his pill time window is over. and warns the patient about potential negative consequences. if the adherence has been poor.

we explored two styles of interfaces. Based on the information such as medical pre-disposing factors. there has to be a mechanism to select multiple symptoms from a menu. it was decided to push information through personalized health tips and quiz. while others may require urgent medical attention. the next menu (set of options) is presented. It would be interesting to investigate which structure – a flat structure or the quiz . medical reports. and to resolve misconceptions. Hence. In addition. It encourages the user to try understand the question and guess the answer.4 Overlapping Menu Items – Two Interface Styles Like any IVRS. The user is expected to listen to all the options and choose one of them. The system provides first level of triage and immediate advice when the clinic may not be operational. Health tips are pushed as a part of a feedback in daily pill reminders. When the user calls the system. While deciding the style of interface. the user can call the system and hear the relevant health tips. issues related to adherence. the entire menu is repeated once again. For IVRS navigation. and the facts and procedures about the HIV/AIDS. each option in the menu is assigned a distinct number on the keypad. It could be due to the side effects of the medicines. If the user chooses an option. pre-recorded medical advice in the voice of the treating doctor.2 Infrequent but Critical Task – Looking up Medical Advice During the early days of ART initiation. the system gives an appropriate. 3. Quiz is the other medium to push the information. CD4 etc. PLHA may experience symptoms and an apparent deterioration of health. doctors figure out the list of most likely occurring symptoms.. To save the time of the user. conceptual knowledge about the disease. the system asks him if he is “not feeling well”. it is important to understand that there are high chances of co-occurrence of more than one symptom. or an indication of a treatment failure. 3. it presents all the options at once. the user would get confused while reporting the symptom. Some of these can be managed by over-the-counter medication or slight adjustments to lifestyles.achieves a better retention of information by the users. A and B. If two or more of such symptoms appear in a single menu. Interface A Interface A is the traditional IVRS style: In a menu. When the user chooses one or more symptoms. ART regimen and current symptoms. ART regimen. The system also stores Information like user demographic.Healthcare IVRS for Non-Tech-Savvy Users 269 3.3 Accessing Information Interactively – Quizzes It is observed that most PLHA are unaware about the terminology such as ART. They were made contextual. . namely. The system presents the user with a list of likely symptoms. opportunistic infections. the list of options is sorted in the decreasing order of likelihood of expected usage of an option. To build the understanding about the disease. If the user does not give any input.

press 1”. Mapping of keys to meanings in Interface B Key 1 3 2 9 Meaning Yes No Maybe Go back Examples “If you have taken your current dose. Else. Interface A Interface B Table 1. “If you have fever. press 3”. press 1”. press 2”. press 3”.G. Fig. --- . Rashinkar et al. “If you have not taken your current dose yet but planning to take it later. “If you have not taken your current dose.270 P. “If you have fever. press 1. 3.

The implementation of interface B requires the user to use only four keys: 1. This helps in habit formation. While doing so the user has to remember all the options in the menu and has to keep a track of the input number associated with it.Healthcare IVRS for Non-Tech-Savvy Users 271 Interface B presents one option at a time. except for the sequence of the options in a menu. The user is supposed to answer the question with a ‘Yes’ or with a ‘No’. Interface B overcomes the difficulty of selection of multiple options from a menu in which options overlap e. A ‘No’ is an explicit rejection of an option (unlike in interface A. which in turn speeds up the process of user input and increases the performance. In interface B. 4. He can decide his selection after considering all the options in the menu. Interface B does impose a hierarchy. where the selection of one option does not necessarily imply a rejection of another). The interface does not impose its bias or hierarchy.. All the options in a menu in interface A are available at the same point. without having to give any input. user can listen to all the options in a menu.g. 2. 3. the user does not have to remember any option and has to simply select or reject the current option. This reduces the search space of possibilities and makes the search efficient. Fig. when it is possible to have both fever and rash . The input keys in interface B have the same meaning across all the menus as shown in fig. 4. Each input is processed at a new level of hierarchy in the menu structure. Interface B Comparison of the two interfaces In case of interface A. and 9.

provide the facility to undo the last selection and to go back to the previous menu. Forgivingness: Allow the users to correct the input they just gave e. 2. in the ‘most-likely-first’ order.G. on frequently used systems.5 Other Design Considerations Prioritization of menu items: Decide the priority considering the usage. .g. Present each menu in a short form. Repetition of menu on no input: The usability evaluations revealed that until the users became acquainted with the system. urgency. In such a case.e.g.g. press 1. Consistency: Throughout the system. In both the cases. 1 2 3 4 5 6 7 Issue Memory load Cognitive load Processing load Freedom of selecting multiple options Input options Introduction of bias Description of all the options before selection Interface A High Considerable Considerable Not allowed 10 Little Allowed Interface B Low Little Little Allowed Unlimited Considerable Restricted Better B B B B B A A We expect interface B to take longer than interface A to navigate. expecting user input. It would lead to habit formation and better performance in the long term.272 P. and the importance of the menu item in the context. To compensate this. we suggest the following two strategies: 1. 3. assign the same key to a menu item e. Both the interfaces provide the option to barge-in. Rashinkar et al. a menu should be played at least five times consecutively on no input. sorting the menus according to the priority and context improves the performance. interface B can have unlimited options in a menu. if ‘A’ is mapped to key ‘2’. and then the same menu in the full form e. then each occurrence of ‘A’ should be mapped only to key ‘2’. Table 2. followed by a pause. Comparison of Interfaces A and B No. Else. independently or together. interface A does not allow the selection of both the options. press 3”. while theoretically. A limit of 10 input options (keys 0-9) is imposed on interface A. “Headache? [Pause for user input] If you have headache. Sort the options in each menu in the decreasing order of likelihood of expected usage of an option i.

To give the context. the doctors and usability professionals could navigate through interface B much faster as compared to A without errors. This also helps users realise if they have landed on some unexpected menu on previous input. users participating in the usability evaluation were not PLHA as the current study is in collaboration with private clinics and these clinics usually have . 3. This means that though interface B introduces a new structure. The experts were explained the basic functionality and purpose of the system and then were asked to perform the tasks that were considered crucial in terms of usability of the system. However once started. and most of the evaluators did miss the first word of every option due to frequent key inputs. it should work very comprehensively with the highly educated and fairly tech-savvy users.1 Method Protocol Figure 1 shows that there is a large population falling within the category of illiterate and low literate (until primary school. 4 4. we have breadcrumbs to let the user know where he is in the interface. difficult to understand. and educated up to a maximum of fourth standard. we give a feedback of the type: “You said <user’s selection>”. the feedback received is to consider the gradation in the adherence feedback given to the PLHA. Accordingly. Heuristic evaluation was conducted with a group consisting of2 usability experts. the system’s voice should be sympathetic and the menus can be bilingual. Giving the context is even more important in an IVRS since there is no visual support in an IVRS. the changes were made to the system.6 Heuristic Evaluation The goal of heuristic evaluation is to find the usability problems in the design so that they can be attended to as part of an iterative design process. it becomes easier as one starts using it. This is useful when user gives an incorrect input but does not realise it. only the serious problems needs to be escalated to the doctors. However. Early evaluation helped in focusing on the key parts of the system and improving the system as a whole. 2 doctors and 1 Psychologist who is also a HIV counsellor. owner of a mobile phone. Evaluators appreciated Interface A for considering IVR patterns with an explicit nature of options. following parameters were followed while selecting users for usability evaluation: age between 30 and 50. We assumed that if the solution could work for such a group of users.Healthcare IVRS for Non-Tech-Savvy Users 273 Context: In a web-based application. The first reactions on interface A were good as against interface B. They found interface B to be non-humanistic. fourth standard). To summarize. In an attempt to target low tech savvy users within this band of ‘illiterates’ and ‘low literates’. All the selected users were native Marathi-speakers. The HIV counsellor liked the idea of quiz and considered it an indirect way to educate people.

etc. Script and the language were not appropriate and thus needed an improvement. During the activity. no training was provided to the users and the system was tested on the same tasks and the same interface that they had tested a week prior. after a gap of 1 week from the first round. quite a few users matching the key demographics (age. Rashinkar et al. It had the task description sheets. It was kept in front of the user so that the user could . understanding his role and duties during the test. The training included some generic tasks. immediately followed by seven pre-designed tasks on the system.2 Pilot Twelve pilot tests were conducted to finalise the protocol for the final usability evaluations. education. All the usability tests were conducted at the choice of user’s location but in a controlled environment. Users tended to forget the task to be performed. it was decided to do the formalities at the time of user recruitment itself. User spent more time in completing the formalities viz. A further analysis revealed the following reasons for failure: 1. and mobile usage) of the users targeted for the usability tests. he was already exhausted. and years of mobile phone usage) pertaining to individual user was noted. To deal with the delay in the formalities before the usability test. years of education. A second round of evaluations was conducted with the same user. The usability evaluation results of round one and two were assessed separately to find out whether the above stated objectives are met or not. This was not surprising since most of the users were exposed to an IVRS and a testing scenario for the first time.G. The users were asked to rate their experience of using the system on a 5-point scale from ‘very difficult’ to ‘very easy’ at the completion of the test. The experiment started with approximately 20 to 45 minutes training of IVRS. a small booklet was created. The objective of second round was to check whether the speed of use and the error rates are inversely proportional to the frequency of usage. The system was modified based on the findings of the pilot studies. the success rate was recorded at around 30%. 4. as well as a couple of infrequent and time-critical tasks taken from the designed system itself. gender. Demographic information (age. 3. 2. One of the interface types (A or B) was assigned to the users trying to keep user demographics relatively balanced on each style of interface. demographics. informed consent. To reduce the cognitive load of remembering the task.274 P. users were probed to get their reactions and perceptions. Users were carefully briefed about the purpose of the study and the activities involved. In round two. by the time training finishes. We used a post-test questionnaire to get user’s feedback for further improvements and to estimate the usability of the system. They were requested to provide an informed consent to participate in the study. After each task. Hence.

Long training: Half the users that were chosen were given long training. this activity was included in one of the training tasks. the practical. and upon the diagnosis. These functionalities of the system can be life-critical at times. The second activity chosen for the training is rare but time-critical and one in which accuracy matters the most. at this point we decided to conduct actual tests with two protocols: protocol 1 (P1): short training and protocol 2 (P2): long training.Healthcare IVRS for Non-Tech-Savvy Users 275 refer to it anytime during the tasks.g. it was decided to train the users on a small number of frequent and critical aspects of the system. He can do it either by calling the system proactively. Hence. These steps were introduced to keep the traditional metaphor of learning: to begin with the theory. First. it becomes very important for the user to give timely and correct input to the system and requires users to be well acquainted with the system right from day one. Short Training: We expect the most frequent activity on the system to be a user reporting that he has taken the current dose. the site maps were created to use during the training to give visual support to the users. user has to report that he has some kind of illness (e. Considering users’ first interaction with the IVRS. Therefore. Since the pilot study did not point out the need of an extra training but to have a clear understanding about the amount of training required for such setting. the training had always been divided into three steps: 1. Hence. cold) and receive the prescription from the system (by listening to the system and by reading the SMS sent by the system). Therefore. 2. training was considered a variable in usability testing. Things from user’s day-to-day lifestyle were brought in to give a clearer conceptual understanding of the IVRS. or reporting when system gives a call. it was a concern whether the unique setting.3 Training Users of the system often visit clinic for their regular checkups. and finally. Half the sample size was trained on longer training and half on the shorter. A demonstration was shown by putting moderator’s phone on loudspeaker. then the demonstration. which is under trial. The user was asked to perform the same task on his phone. needs more training. 4. In addition. Apart from the above reasons. In this task. 3. The extended training includes following: . the users were given tasks that were not related to the system but demonstrated the functioning of IVRS. medical advice is given to the patients over the IVRS. the system helps doctors to diagnose the side effects. Menu structure was explained verbally with a justification for every input.

1.) 1. F: Female This group is a good representative of a section with the lowest level of education. After completing the tasks successfully. 5 Users All users had a very little exposure to the technology and to an urban environment. Mobile Usage (y. reactions were recorded which helped us to understand the issues and users’ perception towards the system. Though people had numeric literacy. The third task takes this learning a step ahead – it has two levels in the menu. For example.: years. and vice versa. M: Male. Rashinkar et al. Therefore. Introduction to the concept of IVRS: The first training task was designed to acquaint the user with the mobile phone keypad and introduce him to the concept of listening to a machine and understanding the instructions properly.: Average.) 35. Most of the users had shared phones and a few were only acquainted with ‘Red’ and ‘Green’ buttons used to receive and disconnect the call. and errors during the task were recorded.9 Av. i. Teaching the concept of abstraction and hierarchical menu structure: The concept was built slowly using three tasks. users were asked to input the digits spoken over the IVRS. User’s statements. behavioural patterns. the user is asked to select a ‘fruit’ from a group of items and then ‘Banana’. and then answering the question ‘how many?’.92 Education 0-2 3-4 >4 14 17 10 Gender M F 20 21 Legend: Av. In the second task.276 P. For quantitative analysis. selecting Vegetable. etc. time taken for successful task completion. she used to press ‘4’ while trying to press ‘6’. then Brinjals.e. the user has to select a ‘Banana’. 6 Findings The 42 usability tests were conducted with seven predefined tasks. which is straightforward and appears as the second option. y. This data helped us in judging the factors that affect the performance on the IVRS. Age (y. In the first task. Initially.G. 2. Users’ responses were documented to analyze the usage. In this task. users were given the system-specific training that is the short training. from right to left. people failed to do so. when it came to punch in the keys to dial the number. Table 3. User demographics # Users 41 Av. one woman from Junnar could not locate the button ‘6’. It was observed that she used to count the numbers manually from left to right and then. number of attempts. we believed that the factors that affect the performance would only be the interface and .

M: Male. However.9 68.66 94. users tended to lose their concentration and faith in the interface as they said ‘No’ to more and more options and their desired option did not appear in the menu. Table 4. CT: Critical Tasks.47 71.00 Interface Time (m.9 73. the two versions (short and long) of training lead to two distinct protocols for usability evaluations. Users of interface A learnt to barge in on their own.11 Time (m.: minutes.00 76. FT: Frequent Tasks Length of the menu: Although interface B has no visible constraint on the depth of the menu.1 42. Table 5. (i.) 32. it became clear that location (which implies the language) was the most critical factor that showed the significant diversity in the success rate.42 16.1 FT1 FT2 FT3 CT1 CT2 IT1 Legend: Av. “When would the menu end?”) c.: Average. Interface A worked in most cases independent of location. through the detailed analysis.1 68.1 40.19 76.Healthcare IVRS for Non-Tech-Savvy Users 277 the protocol. gender.19 76.09 71. to speed up the task. b.4 67.2 77.9 # Users 21 21 21 21 18 17 B % Success 90.e. Data with respect to interfaces Task # Users 21 21 21 21 20 18 A % Success 100. User is not sure whether .3 27. and protocol. m.) 33. End of the menu was not known. It was observed that . However. length of menu. even though they were supposed to answer to one question at a time. As stated above. The two protocols have been summarised below. It became stressful to keep taking decisions at every option. Reasons for this behaviour could be: a.90 100. and the dialect (of the language of the IVRS) being different from one’s own. it was observed that users found it difficult to answer the questions asked in interface B. Comparison of protocols Protocol P1 P2 Interfaces Extended Training X  Short Training   Site Maps X  Average Time (in minutes) 20-25 40-45 The major reasons for failing to perform the tasks were inability to understand abstraction.5 25.4 37. F: Female. it was observed during the usability testing that in interface B.42 38.19 65.

However. etc. In addition.00 50.8 # Users 25 25 24 25 22 20 P2 % Success 96. Table 6. the first-time users of IVRS were observed speaking to the system.00 100.278 P. acknowledging the system verbally (by saying ‘hello’.) 26. Keystrokes and frequency of usage: Considering the number of keystrokes required to reach to the intended menu item. This led them to listen to the menus multiple times.00 Time (m. The quantitative data shows that the extended training of 35-40 minutes is not required. interface B has been proved more efficient.) 39. It is interesting to note that though the interface A has shown significantly higher success rates. The combination of 1-3 was used to avoid unintentional input of 2. ‘no problem’. while explaining the interface details. while trying to press ‘3’.6 80. Interface B is good if the desired option is found among the initial few in a menu.7 37. it is not advisable to use interface B style menu for routine and frequent tasks. Data with respect to protocols Task # Users 17 17 17 17 16 15 P1 % Success 94.2 FT1 FT2 FT3 CT1 CT2 IT1 Another thing introduced in protocol 2 was the site map. interface B should be used. for the selection of multiple and potentially overlapping options from a menu. when put on protocol 1.2 26.6 80. ‘ok’. Site map proved to be very useful in training.6 20.However.00 62. people opted for an inappropriate option simply because the appropriate option was not presented and the user lost patience. Protocol The fundamental difference between the two protocols was the amount of training that was provided.70 31. It helped the first-time IVRS users to understand the concept of listening to voice and answering the questions by pressing a number. and while explaining the .25 93.G. Training users on TAMA tasks for 20 minutes is sufficient. The data does not show a significant difference between the success rates of the two protocols.8 60. Interface A does not facilitate this.50 80.11 70. Proximity of the buttons: We also observed that 4 users disconnected the phone by mistake at least once.3 86. it was clearly observable that the extended training had helped users in gaining confidence about the IVRS system. During the process.00 76.8 49. It also helped them in being acquainted with the number pad.3 53.33 Protocol Time (m. Such a menu style cannot be used for the main menu.). Rashinkar et al. they used to miss important words from the menu. which would land the user on a wrong track. as the major functionalities of the system might remain hidden from most of the users if one does not reject the earlier options.94 64.58 52.3 32.

Some issues regarding language were identified during pilot study as the reasons for a high failure rate. Location Table 7. Data with respect to location Task FT1 FT2 FT3 CT1 CT2 IT1 % Success by Location and Interface Junnar Pen A B A 100. it went up to 87%.00 88.Healthcare IVRS for Non-Tech-Savvy Users 279 abstraction used in the menus and the hierarchical navigation.62 Protocol P1 P2 17 22 59. With protocol 1 (keeping training the same).50 63. The users did remember the PIN correctly and also they remembered the music clue.63 90.66 58. It was observed that the users got familiar with the IVRS concept and had no issues navigating through it. Table 7 shows the statistical analysis of the IVRS based on location.00 88.33 16.00 100. Pune is known as a cultural capital of Maharashtra state and the Marathi spoken there is assumed the standard one. Although users did not refer to site map while performing the tasks. We selected the location Pen because it belongs to Konkan region. Analysis of SUS data # of Users Average SUS score Interface A B 19 20 60.66 87. The pill reminder tasks were executed successfully by the users although few of them could not comprehend the abstraction and menu hierarchy this time without training.00 90. User satisfaction ratings Table 8. The success rate in pilot studies was around 35%.00 58.50 Care was taken to include the regional diversities in the study.00 88.00 62. Junnar is a small town in Pune district. They were corrected before the actual usability evaluation started.11 60.01).78 58. it could be used as visual aid during the training.33 25. This difference was observed due to the difference in dialects of Marathi.80 60.88 100.54 100. it rose up to 90%.63 80. The success rate in Junnar was significantly higher than that in Pen (p=0.72 77.93 .11 Location Pen Junnar 23 16 58.With protocol 2 and the extended training. The success rate of round two when compared with round one were higher though not significant. where Marathi is influenced by Konkani.00 B 91.88 63.00 100.88 72.66 54.77 16.

but plan to take it later. While designing IVRS for the patients of chronic diseases. press 2”. diversity in terms of culture. We understand that the issues related to PIN would be better evaluated when the usability of the system is tested with the PLHA as the targeted audience had no stigma and hence they could not speculate the needs in such situations.280 P. but SUS results show that the users who were given long-term training were more satisfied with the system and their individual performance relative to users who were imparted short-term training. press 2”. We then expanded the menu to say. press 2”. users could not comprehend it well and failed to report that they would be taking their dose later. “If you have not taken your dose yet. “if you are going to take your dose later. This time the success rate was observed to be remarkably high. and the rest found that the PIN was an obstacle to access the information. we have designed two distinct menus: pill time menu (frequent) and the symptoms menu (non-frequent). users were probed for the need of PIN. Although which of the above two affects more is an unclear problem. One option is one can customise menus based on time. Hierarchical navigational problems associated with conventional IVRS designs can be minimized at the cost of brevity in the menu items. The system designed needs users to be trained before they are exposed to the system. 7 Conclusion and Discussion The usability study confirms that the HIT services can be made usable to provide treatment support for chronic diseases to non-tech-savvy and low literate patients. one needs to segregate frequently used modules from non-frequently used modules by observing usage patterns. The resource-limited setting that has been chosen. Rashinkar et al. language and the geography. A similar observation was recorded while we transformed “if you are not feeling well. For example. navigation using the hierarchical menus. We thus believe that the issues related to the abstraction in case of IVRS. One need to consider that navigation should be reduced to minimise the time for frequent tasks. 7 users were undecided. The experiment of using two voices . However the task success rates out of short-term training and long-term training are not significantly different. In our study. during the pill time. We speculate that this perceived enhancement of satisfaction and performance in individual tasks completion is due to the nature of the long term training which is based on user’s dayto-day lifestyle. The low literate and non-tech-savvy users understand the expanded menu items better. consider one of the menu items we had as a system’s voice (female voice) and the other for doctor’s voice (male voice) was welcomed by the users and 39 out of 42 could recollect the two different voices. For example. can be tackled by training users on the things from their day-to-day lifestyle and by making the hierarchical menus more expansive. press 2” to “if you are not feeling well or have any health related issues. Some users associated the female voice with a nurse and the male voice with a doctor. As many as 17 users reported that PIN should be eliminated. deals with some of the inherent problems viz. user is navigated to pill time . During SUS (the post-test questionnaire). Such a prompt sounds very simple but during the pilot study.

Evaluation of the combination of two interfaces is a beyond the scope of this study.. Heidelberg (2011) 2.) INTERACT 2011. D. M. http://censusindia. 2011) 5. A. Nunes. Saple. N. We found that for sensitive and critical health care systems utmost importance has to be given to content localisation as well as voice localization. The interface B is seen to have worked in such situations where only one option is presented to the user at a time.. Winckler. doctors would want to know the complete set of symptoms. Thus. usability of the system is correlated with the dialect of the users apart from other S. This project was funded through a grant from Johnson & Johnson Limited. Van Dam. J. Part II. Springer. We thank the doctors. LNCS. The time lost in repetition and expansivity can be minimised by incorporating a functionality to barge in. and the people living with HIV/AIDS for participating in this project and sharing their insights. In: Campos. It is concluded that interface A can be effectively used for presenting a short list of menus.. one cannot use the traditional menu style of IVRS because it does not allow multiple selections from the same list. one might not listen to the options. http://en. Graham. P. Palanque.htm (accessed July 31. Sali. We found that even untrained users barge-in. D. Kumarasamy. vol.G. 2011) ..internetworldstats. as one would get habitual to the menu soon and at some stage.wikipedia. The usability tests showed that the first-time IVR users were comfortable using the system and could successfully complete their tasks in both types of interfaces... Whereas in frequently accessed modules.trai. Solomon. es/837/Press_Release_July-11.. N. Interface B is especially useful in case of multiple selections. where aakadi is a Marathi word for fit. 2011).. Users were found to be satisfied and this is reflected in their SUS scores. one needs to follow the principles explained above such as expansivity and training. N. In order to obtain complete set of symptoms. While diagnosing a patient’s symptoms over the IVRS. Roy. N. Jorge. A... For example “aakadi or fit”. The customization for dialect can be achieved through introducing redundancy and bilingualism in the menu items.. H. Rutten. R. M. J. Acknowledgements. Diamond Sharma. pp.Healthcare IVRS for Non-Tech-Savvy Users 281 menu if he has not reported the dose earlier. In case of IVRS. Internet World Statistics: Internet Users in the World. http://www. 2011) 3. Census of (accessed 2011) 4.pdf (accessed September 9.: Design Opportunities for Supporting Treatment of People Living with HIV/AIDS in India. Ganju. http://www... References mobile_phones_in_use (accessed September 12. TRAI: Telecom Subscription Data (July 31. Joshi. Wikipedia. 6947. although it will be interesting to see the results and user’s reaction against the use the two interfaces together. S. P. 315–332. D. In case of infrequent but time-critical modules. We propose interface style B for dealing with overlapping symptoms where as interface A for all other menus. this brings all the possible symptoms exhibited by the patient.... Bharshankar. Pujari. Menu repetition can be used to offer a better comprehension of the content. brevity is expected. (eds.

A. S. Kagaayi. K. W. Friedman.: Participant reactions to a computerized telephone system for nutrition and exercise counseling. S. M. S. drug use.E. Pariante. Bonnie. Bernardine. In: Computers and Advanced Technology in Education.: Adolescent sexual behavior. Pleck.: Can the ubiquitous power of mobile phones be used to improve health outcomes in developing countries? (2006) 8. A. Raghu Menon.: Interactive technology applications for behavioral counseling: issues and opportunities for health care settings. 235–237 (2004) 21. N.D.. Glanz. P. Journal of Medical Systems 22(2). Nakigozi. F. Serv. A.. D.J.. 10(3). Leire. 313–323 (2006) 23. J. K.. IEEE Transactions on Information Technology in Biomedicine 8(3).. J. Rashinkar et al. 6.. 49(2). Counsel. R.: Interactive voice response systems in clinical research and treatment. B. F. Ramesh. V.. Friedman. Glasgow. Chang. Karanja. 847–848 (1998) 22. Kuun. Bollinger.: New Research Challenge: Persuasive Technology to Motivate Healthy Aging. T. Welankar.. and HIV Care in Rakai. D. 157–163 (2003) 20. Turner. M. Pat.: Responding to the Human Resource Crisis: Peer Health Workers. American Journal of Preventive Medicine 17(4). Sharma Grover.C.... E. Beck.. Quinn.. Mumbai (2010) 7.H. L.. 277–283 (2003) 15. J. AIDS and Behavior 11(2)...: Beyond Strict Illiteracy:Abstracted Learning Among Low-Literate Users. Doha.S. J. R.L..282 P. Qatar.. Pract. Gray.: Interactive Voice Response System (IVRS) in Health Care Services.. In: mHealth potential in South Africa: The Experience of Cell-Life. 157–163 (2003) 16. Thomas (2009) 25. G.O. http://www. Kaplan.. D. Lester. Shigaki. Mobile Phones. Toyaman.: Participant reactions to a computerized telephone system for nutrition and exercise counseling.. G.... Science 280(5365). C. Benjamin. C.. R.: Automated Telephone Conversations to Assess Health Behvior and Deliver Behaviorl D. J.G. Uganda (2008) 9. The Cerontologist 31(4). Farzanfarb.cell-life. Cukor. Lindberg. S. Glanz. L. Sonenstein. I. S. S.: HIV health information access using spoken dialogue systems: Touchtone vs. Medhi. on ICTD. St. K. Ca.: Interactive Voice Response Technology applied to sexual behavior self-reports: a comparison of three methods... R. Barnard. and violence: increased reporting with computer survey technology.: Project Masiluleke. B. K. P. Tanke.: Mobile phones: exceptional tools for HIV/AIDS. Mundt. Ku. Morrow. Fabricant. Speech. R. 95–107 (April 2007) . R. Conf. India. and crisis management (2008) 10.. L. Cutrell. K. 48(5).. Interactions 16(6) (2009) 11. K. 514–520 (1991) 13... Reynolds. Ahern. In: HCI. E. R. K.. D. health. R. pp. Kanitkar... Patient Education and Counseling 49(2). In : ICTD. H.. Pintoc. Packer. Noell..: Designing Interactive Voice Response (IVR) Interfaces: Localization For Low Literacy Users. Psychi. 611–612 (1997) 14. Kapland. R.E. P.: Telephone-linked care for cancer symptom monitoring: A pilot study... Shigakia. C. Friedman.. London (2010) 24. Farzanfar. Johnson. Schroder. Friedman. Plauche. Edu.. Mooney... R. Intille. 269–274 (1999) 19. Rogers. Stewart. Lubensky. Lee.. A. 147–154 (2002) 17.: Cellphones 4 HIV.. O. Wiebe. Nursing Outlook 51(6).M.. Friedman.F.: Principles for Simplifying Translation of Marathi Terms in Mobile Phones.. R.pdf (accessed 2010) 12. In : 3rd Int. Joshi. Sharma Grover. D.: Elders’ Nonadherence: Its Assessment and Medication Reminding by Voice Mail. E. Serwadda. 95–102 (1998) 18.

Sign up to vote on this title
UsefulNot useful