# Evaluating mHealth Apps Using Affordances: Case of CommCare Versus DHIS2 Tracker

Amrit Chhetri, Mari Iversen, Jens Kaasbøll, Chipo Kanjo

► To cite this version:

Amrit Chhetri, Mari Iversen, Jens Kaasbøll, Chipo Kanjo. Evaluating mHealth Apps Using Affordances: Case of CommCare Versus DHIS2 Tracker. 15th International Conference on Social Implications of Computers in Developing Countries (ICT4D), May 2019, Dar es Salaam, Tanzania. pp.619-632, 10.1007/978-3-030-18400-1_51 . hal-02285306

HAL Id: hal-02285306

https://inria.hal.science/hal-02285306

Submitted on 12 Sep 2019

**HAL** is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
Evaluating mHealth Apps Using Affordances: Case of CommCare Versus
DHIS2 Tracker

Amrit

Chhetri¹, Mari Iversen¹, Jens Kaasbøll,¹ [0000-0001-9666-0887] Chipo Kanjo² [0000-0002-6939-6168]

1University of Oslo, Norway

amritchhetri@gmail.com, mariive@ifi.uio.no, jensj@ifi.uio.no

2 University of Malawi, Malawi

chipo.kanjo@gmail.com

**Abstract.** CommCare and DHIS2 Tracker are two software packages which were configured for community health workers (CHW) in Malawi and evaluated and compared. To capture a wide scope of aspects including possible developmental ones, the Affordance concept was applied as an analytic frame. Being configurable software packages, concept of Platform Affordance was considered but abandoned, since its domain could be covered by the configurer's affordance. To operationalize the concept, usability concepts from HCI were applied for the evaluation and comparison of end-user and configure affordances. Organisational Affordance, based on structuration theory modalities, was used to characterize affordances not attributed to specific people.

The study revealed that much as CommCare is more specific to CHWs, hence having more weight on the configuration (where configuration was quicker) and end-user affordances (with an ability to display images which could be used for health promotion) compared to DHIS2, it had weak organisational affordance mostly due to license fees. Further, DHIS2 had the ability to produce reports summarizing health indicators and comparing the data generated with data collected outside the DHIS2 App.

In addition to usability issues, the CHWs perceived that any of the systems would relieve them from bulky registers to carry and time-consuming reporting, hence affording more time for other tasks. Observations of their slow typing speed point in the opposite direction. While the Affordance concept emphasizes the relationship between users and technology, the case points to the need for not making users' first impression the only basis for judging affordances.

**Keywords:** Affordances, Usability, mHealth App, CommCare, DHIS2 Tracker.

# 1 Introduction

The two mHealth Apps namely: CommCare and DHIS2 tracker are used by Community Health Workers (CHWs) in Malawi. Since we could not find any comparisons of the two systems, our practical research question was: what are the pros and cons of the two?

While CHWs were the end users, the softwares had to be configured by others, hence the comparison should also include their perspective. Third, the Ministry of Health would be the manager of the information systems, so the software needed to be considered also in that respect. Since the Affordance concept has been used when studying development [1], we chose this theoretical frame. It captures technology seen from individual users' point of view, hence it enables assessing the technology as experience by CHW and the configurers. To address the organizational perspective, we adopt an extension of the concept into organizational affordance as presented in [2]. Pushing the theory beyond its previous usage, we ask the research question; how we operationalize the affordance concept cater for such a mixed evaluation?

## 1.1 CommCare and DHIS2 Tracker Applications

The CHWs in Malawi work under the Environmental Health Department. They play an important role in connecting the communities and the national health sector. CHWs make 30 % of the health workforce in Malawi with the responsibility of providing curative, promotive and preventative care. Their job activities range from provision of primary health care, to household visits, disease surveillance, and health promotive talks. The CHWs are overburdened, and as a way of easing their work load, there is a new global interest focusing on the CHWs, providing mobile health (mHealth) applications as a solution for data capturing, including CommCare and DHIS 2.
CommCare is an open source mobile health platform used in more than 50 countries and consist of two components; CommCare mobile and CommCare HQ [3]. The CommCare platform offers as set of modules including data reporting, worker monitoring, analytics dashboards, decision-making support and tracking of individual data records and is configurable through the CommCare HQ web-interface without any programming. The data collected using CommCare Application is stored in their HIPAA compliant [4] server. CommCare offers multimedia options such as pictures, audio records and videos and also supports offline data storage. However, CommCare is not free to use and you have to pay for extra features. CommCare Application is tailor made for CHWs.

DHIS2 is also a free and open source software with several modules used for validation, collection, analysis, and presentation of aggregated and patient-based statistical data. It is currently in use in more than 80 countries. The DHIS2 allows configurers to customize information systems through an open meta-data model without coding. The data is stored in a database set up by the owners of the data on a server of their choice. In this research the DHIS2 Tracker capture module for Android was used. Tracker capture is a configurable multiple event program that allows to capturing client data. Tracker capture does not support multimedia options. DHIS2 is not developed for any particular user group, it was developed as a general application for statistical reporting in hierarchical organisations and is also used in other domains like education and agriculture. DHIS2 Android can also operate offline, thus fitting places where there is no internet connection; hence, useful for CHWs.

We chose CommCare [3] as a representative for systems designed for CHWs and DHIS2 as a general application and set up an experiment to compare their usability and examine if there are design aspects that the two systems could learn from each other. The comparison is based on user preferences and usability; aiming to understand why one application is possibly more preferable than the other.

## 1.2 mHealth Experiences

Mobile health (mHealth) refers to the usage of mobile technology to promote and support healthcare activities such as data collection, health promotions, etc. By using mHealth services we can potentially increase and improve on affordability of interventions for health promotion. There have been several studies on mHealth in an African context. Example of this is a study done in Uganda where Chang, Njie-Carr [5] looked at perceptions and acceptability of an mHealth application at a community-based HIV/AIDS clinic. However, this research did not look at usability but it discussed other important aspects such as mHealth features, benefits and potential challenges such as security concerns and patients confidentiality. Overall, there was great enthusiasm amongst the CHWs in the study for using the mHealth tool as part of their interventions [5]. Thondoo [6] also explored potential benefits of using mHealth tools with the CHWs cadre with a focus on functionality of the mHealth tools. Further, a systematic review of 44 mHealth projects in Africa identified several factors that contributes to having successful implementations [7]. The factors include accessibility, acceptance and low-cost of the technology introduced, effective adaption to local contexts, strong stakeholder collaboration, and government involvement. They also identified challenges that could affect the implementation as follows: dependent on funding, unclear healthcare system responsibilities, unreliable infrastructure and lack of evidence on cost-effectiveness.

# 2 Theoretical Approach

Affordance concept was coined by Gibson [8] and has been used in information systems literature for characterizing the functions of the IT system which enables (or restricts) the user to carry out their actions. Later, Norman [9] introduced the affordance concept to the HCI community. This led to two perspectives on affordances; one stemming from Norman's view of properties in the IT systems enabling and guiding the user [1, 10]; the other viewing affordances as emerging in users' practice [11]. However, the Norman's perspective of affordance has been contested, arguing that it has ambiguity [12]. Aiming at evaluating the IT support for CHWs, we opted for the alternative used in ICT4D literature [1] and which considers properties of the technology. A good number of researchers have used Affordance Theory to assess the uses and consequences of such IT artefacts [12].
Using a methodology that combines qualitative methods of document analysis, interviews and observation with an experiment; this paper evaluates the configuration, end-user and organisational affordances of two mHealth Apps (CommCare and DHIS2 tracker) used by Community Health Workers (CHWs) in Malawi. The two applications were designed for home visits. In this study, CHWs were used to test the two systems and give feedback.

## 2.1 Individual Affordance

When designing a system, the designer makes sure that the client's needs are well represented and the relevant functionality is perceivable for one to be able to continue with development. When a developer sees a system design, they are able to perceive it and translate it into programs; similarly, it should be the case that when a user sees the program interface, they should have a hint on how to use it. When you first see something you have never seen before, how do you know what to do? Norman [10] argue that the appearance could provide the critical clues required for its proper operation. A good number of researchers have used Affordance Theory to assess the uses and consequences of such IT artefacts [12].

Affordances are relational properties between user and technology, thus the technologies can only be evaluated related to users. Given that two users who share roles nevertheless may differ in their relationship to the IT, an ethnographic study of all users should have been carried out. For practical reasons, two distinct user groups were identified and their experiences formed the basis for the evaluation.

For a systematic approach to individual affordance, we borrowed the usability concept from the HCI literature, where one definition of usability [13] "the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use" reflects the affordance view. Once a product is useable, it has three main outcomes: first, it is easy for the users to become familiar and competent with the system. For example, a useable application in a health facility should allow a health worker to easily understand how to enter data and register a client. Second, the system should make it easy for its user to achieve their objectives. The system should guide the user throughout the process. Lastly, it should be easy to recall the user interface. Ideally the users should learn from the first usage of the application and recall how it was done subsequently. To identify usability, usability testing is done; this is based usability goals which include: effectiveness, efficiency, safety, utility, learnability and memorability [14]. For the sake of this research we have extracted three usability goals that we found more relevant. These goals are effectiveness, efficiency and learnability. Effectiveness concerns the accuracy with which the user can achieve specified goals. For instance, a health worker's ability to effectively register a client. Learnability concerns the ease in which users develop competence. For instance, health worker ability to effectively learn to use the system. Efficiency refers to the way a product or system can support users in carrying out their tasks.

Configurers use the software platform to tailor the system to local needs. Hence, we could, in line with Koskinen, Bonina [15], who considers innovation platforms for ICT4D, use the expression *platform affordance* to characterize the affordance for configuration. An important aspect of platform affordance is that the platform should enable designs not foreseen by the platform developers, however, we did not evaluate this aspect of the systems. Since configurers are also individual users of the software, usability was also chosen as the basis for evaluating the softwares for both for them and for end-users of the systems.

## 2.2 Organisational Affordance

Information systems have non-functional qualities like cost, support, security and more, which the whole organization or unknown stakeholders may have to relate to. These qualities may fall completely outside of usability concept. An approach to organizational affordances has been built [2] through adding the three modalities from structuration theory [16]; norms, power and meaning; to the technological dimension. This is in line with calls made in literature to broaden the focus of affordances to organisational level in order to study IT-Associated organisational change

The system cost will be one of the qualities that has to be considered, and this falls under the power mode of the organizational affordances. Security is another aspect of patient information system for which there can be norms, and for which resources (power) and meaning are also relevant.
# 3 Methodology

This study uses a methodology that combines qualitative methods of document analysis, interviews and observation with an experiment to evaluate the end-user, configurer and organisational affordances of two mHealth Apps (CommCare and DHIS2 tracker) used by Community Health Workers (CHWs) in Malawi. Initially, document analysis, interviews and observation were carried out to gain an understanding of the CHWs roles to help us configure the apps. The outcomes of the initial investigations showed that the CHWs spend majority of their time on household visits. In between, they also conduct outreach clinics for specific health services like immunization. Another semi-structured interview was conducted to map the background of the CHWs, their experience with technology, their work role and their educational background. Following which the apps were introduced (this will be explained in the next section) and finally the researcher observed the participants using the apps and take notes. Where participants were stuck or taking too long to complete capturing data for a particular case, the researcher would intervene and assist them.

To address the core of their work, we chose to set up the two softwares to capture the data that the CHWs collect on household visits. This includes demographics of the household and status of latrines, water source and other facilities the household may have. The two health programs contained the exact same data elements in the same sequence. The difference between the two being the interface as well as the multimedia option in CommCare. Pictures for guiding how to build latrines and hand-washing facilities were added to CommCare to assist the CHW. Figure 1 illustrates the user interfaces of CommCare and the DHIS 2 Android App. The CommCare system has been set up with some illustrations.

## 3.1 Setting up the Experiment

The experiment mostly involved configuring the two systems for use. In total, 12 CHWs drawn from three clinics in Zomba district in Malawi participated in the experiments. All of the CHWs tested both apps, however half of the participants tested the DHIS2 app first before testing the CommCare, while the other half tested the CommCare app first before testing the DHIS2 app. A set of guiding questions regarding user preferences was developed to guide the CHWs.

<figure><img src="image_2.png" /><figcaption>Figure 1. User Interfaces of the two mHealth Apps</figcaption></figure>
## 3.2 Cases

Cases used in the testing of the health app were created in advance to allow participants use similar case for each of the two health apps. The participants were expected to tick off data elements if they were present in the case or type in some text into the health app based on situation. An example of a case used: "household is not using two-cup system". The participant should then indicate in the health app that two-cup system is not being used. This is done by clicking on the "no" radio-button belonging to that data element.

Three groups of participants took part in the experiment. The first batch comprised three CHWs and they all had previous experience in using CommCare. The second batch had four participants, all had no prior mHealth experience; and the last two batches had a total of 5 participants.

# 4 Results

We explain the results based on the participants previous experience with the system (considering that some of the participants had already had a chance of using one of the systems) and configuration variations of the two systems i.e. with CommCare, it is possible to set it up with one data field per page or with multiple fields per page; whereas with DHIS2, you can only have multiple fields per page. Secondly, CommCare App allow for images whereas DHIS2 does not. It was also found that CommCare App requires licensing, whereas DHIS2 does not require any form of license.

## 4.1 Application Preference (CommCare vs. DHIS2)

Preference of the two applications varied for different reasons. For example, the first group comprising three CHWs preferred CommCare since they had had previous experience using it. The second group which had four participants, without any prior experience with mHealth applications were given the two systems as shown in Figure 2 where CommCare App was set up with one data field per page and DHIS2 with multiple fields. The CHWs reacted to this comparison by saying that they preferred DHIS2 because having several data entry fields/ questions on a single page makes it easier to track and recheck them. CommCare also supports multiple questions per page, but the default setting is one question per page as shown in Figure 2(a).

<figure><img src="image_3.png" /><figcaption>Figure 2. CommCare with one data field per page, DHIS2 with several fields</figcaption></figure>

Another finding was that much as participants were happy with the possibility of having images in the CommCare App, the nature of image used mattered to them. For example, participants were not happy with the image for latrine that was initially set in the CommCare App in the first experiment as illustrated in Figure 3 (a). The
impression was that this was too abstract for health promotion in the villages. In the second round, the image was changed to one which the community could relate with as shown in figure 1(a).

It was also found that the participants were not happy with some text which they thought was unnecessary. For example, they did not make any sense of the text in the DHIS2 App “Enter positive integer” see Figure 3 (b).

<figure><img src="image_4.png" /><figcaption>Figure 3. Drawing of latrine in CommCare (a). Placeholder text in DHIS2 (b).</figcaption></figure>

In the last two evaluations, with a total of five CHWs, both applications were set up with the same data fields on each page. CommCare's ability to display images was exploited, and images like that of latrine shown in Figure 1 were included. The CHWs were given the applications to test in opposite order (i.e, if previously participants started with CommCare, while in this round participants would start with DHIS2 and vice versa).

All participants in the experiments agreed that the image functionality in the CommCare App added value. For the DHIS2 App, participants preferred the function of tagging mandatory fields with an asterisk and explained that it was value adding. Otherwise, they observed that there were no major differences between the two Apps. The CHWs were of the opinion that the two applications did nearly the same thing and were very similar so much so that choosing one over the other seemed rather strange.

Overall, all CHWs who participated preferred using an app to using a paper-based system. Reasons given were that it will ease carrying bulky books around as they move from one household to the other. Another reason was that time spent (a day or more) to compile reports at the end of the month will be reduced.

The researchers observed, that the CHWs spent twice the time filling the electronic forms compared to the paper registers. This was due to their slow typing speed, which reflected their unfamiliarity with computers (or typewriters).

## 4.2 Applications Use

CHWs found the two applications to be very similar, and equally easy to use. They indicated that both applications were effective. The CHWs considered effectiveness as key. The fact that we were able to change the abstract latrine image in CommCare application to a more realistic latrine picture based on their context was considered as a good example of changing ineffectiveness of the images included to an effective image. Since the two health applications had the same data elements the CHWs were rather confused on why they should choose one over the other. The fact that CHWs preferred using the applications over the use of paper registers also attested that the applications were effective. Four of the CHWs used the DHIS2 Tracker application for two weeks after the experiment. While the researchers noticed that these CHWs spent around twice as much time on regist
tering data in the application versus the paper registers, this time consumption was never mentioned by the CHWs. It may be that they will gain speed over a period, with more practice.

During observation, a trend emerged where most participants would most of the times forget which button to press to start registering a new client. This was considered to be a result of lack of sufficient IT competence as they were unable to explain what the different icons meant and what they were used for.

## 4.3 Application Configuration

Both DHIS2 and CommCare are configurable without coding, and configuration is carried out in another module than the end-user application. This allows for change in configuration to suit end-user needs if the set-up is not optimal or preferred. The only drawback is that, the configuration is not done by end-users. One of the researchers (the first author), a computer scientist, was the configurer. It was actually the first time he did this and he reported on the configuration processes as follows: In the version of DHIS2 used, the meta-data and other configurations of the health programs are done in different parts of the system. For instance, there is one module to create the data-elements, another module to create programs rules and a third module to put the data-elements in the right order. In CommCare, everything is done in the same module of the system. Further, CommCare also support drag and drop of data elements, allowing one to change the order of data elements simply by clicking on one of the elements and drag it to the right position so as to have data elements in the order one wants them to appear on the screen. In DHIS2 changing the order of the data elements is done by selecting the data element to be moved and then use on-screen arrows to move the data-elements up or down. However, when having a long list of data-elements one scrolls up and down through a small view, as only seven data elements are visible at a time.

The experience of the configuration show that CommCare configuration was quicker and easier to learn and use. Despite the fact that the default configuration only allowed for one data field per page, the end result of the configuration of the two applications were very similar as confirmed by the CHWs.

## 4.4 Data Storage and Reports

One more functional issue became apparent. DHIS2 patient data is stored in the national DHIS2 database at the Ministry of Health in Malawi. There, the data is aggregated to obtain indicators of different programs such as: immunization coverage, counts of pregnant women, etc. With paper reporting, the CHWs summarize the data on a monthly basis. With the introduction of the application, the calculations are done by the software. In addition, the CHWs can get reports from the national database in a Dashboard app on their phone/tablet on health for their catchment area and they will be able to compare their data with data from other catchment areas and also be able to see time trends. illustrates the different DHIS2 components and how they relate to each other.
<figure><img src="image_5.png" /><figcaption>Figure 4. DHIS2 Environment</figcaption></figure>

CommCare data on the other hand is stored at a server outside the country. This data does not feed into the national aggregates, hence the data captured through CommCare application does not have any data repositories at national level. No record of this data is available locally. To obtain an aggregate report, a request has to be sent to CommCare's software vendor, and the report is delivered in pdf format. This report will go to the District Health Office and not directly to the CHWs, see Figure 5 for an overview.

<figure><img src="image_6.png" /><figcaption>Figure 5. CommCare modules</figcaption></figure>

## 4.5 Non-Functional Qualities

The list of non-functional requirements for an information system is long; and ISO 25010 [17] lists 31 sub-categories from accountability to user error protection. One quality which is not covered by ISO, but nevertheless found to be relevant in our case was cost, both initial and life-cycle. However, cost is included as one of the 58 categories in the Wikipedia list of non-functional qualities [18]. The systems utilize the same hardware. Differ-
ences in internet usage are unknown. The cost of setting up DHIS2 is probably higher than CommCare, as noticed by the configurer. However, while DHIS2 is free, CommCare requires licenses per user, and reports require additional payments. The three-month license for the experiment with a small number of users was USD1500.

# 5 Discussion and Conclusion

As mentioned earlier, of interest in this paper are *platform (configuration)*, *end-user* and *organisational affordances*. For these affordances, the following characteristics were examined: *affordance existence*, *perception* and *effect* for each of the two systems. Implications of these affordances are also included in the discussions below.

CommCare and DHIS2 have end-users and configurers, hence the systems were evaluated and compared relative to these groups. Being individual users, their experience can be expressed through the affordance concept.

Software license cost was identified as a distinctive factor at the organizational level. Cost belongs to the resources/power mode of the structuration theory and will therefore be characterized as such in the comparison, see Table 1. This research did not address other organizational factors like security and capacity for hosting servers.

<table><caption>Table 1. Affordances of CommCare and DHIS2</caption><thead><tr><th></th><th>CommCare</th><th>DHIS2</th></tr></thead><tbody><tr><th>End-User Affordance</th><td>Good for client data.<br>Good for health promotion due to illustrations.<br>Poor for Health data.</td><td>Good for client data.<br>Poor for health promotion due to lack of illustrations.<br>Good for Health data.</td></tr><tr><th>Configurer affordance</th><td>Good for effectiveness and efficiency.</td><td>Good for effectiveness.<br>Poorer for efficiency.</td></tr><tr><th>Oragnisational Affordance – Power</th><td>High license cost.</td><td>No license cost.</td></tr></tbody></table>

This study was aimed at evaluation of two software packages. To operationalize individual affordances, the usability approach from HCI was adopted. On the organizational side, other functional and non-functional requirements were considered. The comparison between the systems could have been done without using affordance concept.

Affordance has been used in ICT4D literature since it goes beyond usability to include people's innovations and applications of the technology outside its intended design. Such innovative use would be a strong indicator of *development* taking place. The results that CHWs preferred any mHealth app to the paper-based system lies outside of the usability and non-functional requirement comparison carried out. We could say that the mHealth systems would relieve the CHWs from other tasks. In this case, the CHWs are not afforded with new opportunities through the ICT, but being relieved from other duties by the technology may afford them time for other tasks.

Affordance-by-relief was based on the utterances of the CHWs, while the researchers observed that the apps actually occupied more of their time, at least before their typing speed increased. This contradiction points to the risk of basing conclusion on affordance increase only on the informants' statements. The novelty of the technology and its association with modernity may create initial enthusiasm which may fade after some experience with time consuming typing and the inevitable troubleshooting of software and hardware that will take place. According to [19], the CHWs may have perceived a false affordance, but [20] argues that this is rather a misinterpretation. Only a longer term study would reveal whether the mHealth apps save CHW time.

Instead of applying the concept of Platform Affordance [15], this was covered through analyzing the affordance of those doing the software configuration. Since Affordance is relational between user and technology, we found it more appropriate to talk about Affordance from the configurer's point of view.

While Affordance has been regarded as something which the actor can perceive directly, [20] also introduces Hidden Affordances. These are properties of the technology which users do not perceive. The configurer did not perceive the option of having more data fields in one screen immediately, thus this affordance was initially hid-
10

den. Thus, an actor may need to learn to discriminate the information in order to perceive directly. In this way
learning can be seen as a process of discriminating patterns in the world, rather than one of supplementing sen-
sory information with past experience [20]. But this does not resolve the situation. This distinction contradicts
Gibson's assertion that perception is 'direct' and yet still runs into the problem of what the 'relationship' be-
tween actor and environment consists of. It also renders affordances unknowable.

Norman [10] argues that the appearance should provide the critical clues required for its proper operation.
The design community adopted the concept of affordance arguing that the designer focuses on what actions the
user perceives to be possible. Even if this guideline might have made the configure avoiding the initial problem,
it would not address possible misconceptions about the efficiency of the apps for the CHWs' tasks.

The Affordance concept was not operational for comparing two softwares to be used for the same tasks.
However, it allowed for characterizing the users' comprehension of IT versus paper-based information systems.
While previous literature points to Affordance as the relationship between users and technology as perceived by
the users, the CHWs' belief in efficiency and the configurer's initial misconception point to the unanswered
question of who will decide which affordances that exist.

References

1. Thapa, D. and M.K. Sein, *Trajectory of Affordances: Insights from a case of telemedicine in Nepal*. Information Systems Journal, 2018. 28(5): p. 796-817.

2. Vyas, D., C.M. Chisalita, and A. Dix, *Organizational affordances: A structuration theory approach to affordances*. Interacting with Computers, 2017. 29(2): p. 117-131.

3. *dimagi*. 2018 [cited 2018; Available from: www.dimagi.com].

4. *Health Information Privacy*. 2018 [cited 2018; Available from: www.hhs.gov/hipaa/index.html].

5. Chang, L.W., et al., *Perceptions and acceptability of mHealth interventions for improving patient care at a community-based HIV/AIDS clinic in Uganda: a mixed methods study*. AIDS care, 2013. 25(7): p. 874-880.

6. Thondoo, M., et al., *Potential roles of mHealth for community health workers: formative research with end users in Uganda and Mozambique*. JMIR mHealth and uHealth, 2015. 3(3).

7. Aranda-Jan, C.B., N. Mohutiwa-Dibe, and S. Loukanova, *Systematic review on what works, what does not work and why of implementation of mobile health (mHealth) projects in Africa*. BMC public health, 2014. 14(1): p. 188.

8. Gibson, J.J., *The Ecological Approach to Visual Perception*. 1979, Boston: Houghton Mifflin.

9. Norman, D.A., *The psychology of everyday things.* (The design of everyday things). 1988, Basic Books.

10. Norman, D.A., *Affordance, conventions, and design*. interactions, 1999. 6(3): p. 38-43.

11. Leonardi, P.M., *When does technology use enable network change in organizations? A comparative study of feature use and shared affordances*. 2012.

12. Pozzi, G., F. Pigni, and C. Vitari, *Affordance theory in the IS discipline: A review and synthesis of the literature*. in *AMCIS 2014 Proceedings*. 2013.

13. Standardization, I.O.f., *ISO 9241: Ergonomics of human-system interaction*, in *Usability: Definitions and concepts*. 2018.

14. Rogers, Y., H. Sharp, and J. Preece, *Interaction Design: Beyond Human-Computer Interaction*. 2002: John Wiley & Sons.

15. Koskinen, K., C. Bonina, and B. Eaton, *Digital Platforms in the Global South: Foundations and Research Agenda*, in *Development Implications of Digital Economies*. 2018, Centre for Development Informatics, University of Manchester.

16. Giddens, A., *Agency, structure*, in *Central problems in social theory*. 1979, Springer. p. 49-95.

17. ISO, *ISO/IEC 25010 Software Product Quality*. 2018.

18. *Non-functional requirement*, in *Wikipedia*. 2018.

19. Gaver, W.W. *Technology affordances*. in *Proceedings of the SIGCHI conference on Human factors in computing systems*. 1991. ACM.

20. McGrenere, J. and W. Ho. *Affordances: Clarifying and evolving a concept*. in *Graphics interface*. 2000.