# Technical ICTD - A User Centered Lifecycle

Joerg Doerflinger, Tom Gross

## ► To cite this version:

Joerg Doerflinger, Tom Gross. Technical ICTD - A User Centered Lifecycle. Third IFIP TC6 International Conference on Wireless Communications and Information Technology in Developing Countries (WCITD) / IFIP TC 6 International Network of the Future Conference (NF) / Held as Part of World Computer Congress (WCC), Sep 2010, Brisbane, Australia. pp.72-83, 10.1007/978-3-642-15476-8_8 . hal-01054734

HAL Id: hal-01054734

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

Submitted on 8 Aug 2014

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
Technical ICTD - A User Centered Lifecycle

Joerg Doerflinger¹ and Tom Gross²

¹ SAP Research, CEC Karlsruhe, Vincenz-Priessnitz-Strasse 1, Karlsruhe, 76131, Germany, joerg.doerflinger@sap.com

² Faculty of Media, Bauhaus-University Weimar, Bauhausstrasse 11, Weimar, 99423, Germany, tom.gross@medien.uni-weimar.de

**Abstract.** Technical Information and Communication Technology for Development (ICTD) lacks appropriate research methods along the entire development lifecycle spanning design, development, deployment, and evaluation. Many ICTD projects have failed meeting the challenges of technical ICTD because of inappropriate research methods which often left frustrated end users alone with unusable research results. Successful technical ICTD research needs a shared methodology that involves the end user in all research lifecycle phases. With User Centered Design and Action Research the Mobile Human Computer Interaction (HCI) research field offers concepts with a clear end user focus. However, applying Mobile HCI research methods unchanged in technical ICTD will fail due to the specific cultural, infrastructural and governmental context of ICTD research. In this paper we present a set of Mobile HCI research methods adapted for technical ICTD research based on results and lessons learned of a research project in rural South Africa.

**Keywords:** User Centered Design, Action Research, ICTD, Mobile HCI

# 1 Introduction

People in rural areas of emerging economies lack appropriate access to Information and Communication Technology (ICT) which is a key mechanism for socioeconomic development in those regions that need it most. In a globalized world, economical, social, and political life will be more and more digital, and those without access to ICT will be increasingly excluded [1]. Many previous approaches of providing ICT access in developing countries failed because of an often applied "copy&paste" approach of 1st economy concepts in regions with different governmental, cultural and infrastructural contexts [2]. To improve technical ICTD research, the methodologies utilized along the entire development lifecycle need to be adapted from a technology centric top-down approach towards a user centric top-down/bottom-up combination taking into account the specific ICTD context. In this paper we present a set of research methods adapted towards the specific requirements of technical ICTD, which refers to ICTD topics specifically relevant for computer scientists and engineers.

Technical ICTD research today is not yet a well established research field because of missing metrics and tools [3]. Metrics clearly define the research goal
and make research measurable and comparable. The tools represent agreed-upon
research processes and methodologies. Today there is no shared set of research
methods supporting researchers in technical ICTD research. With our proposed
set of research methods for technical ICTD we contribute exactly to this part.
Our proposed research approach combines and adapts existing research methods
from the Mobile Human Computer Interaction (HCI) research field along the
entire technical ICTD development lifecycle. The adaptation takes place on two
levels - the overall research approach and at the individual lifecycle elements.

The overall approach is to move from the technology centric top-down ap-
proach of former technical ICTD research, which often led to design versus re-
ality gaps, towards a user centric approach involving end users in all research
lifecycle phases. Ignoring end user needs and their potential to contribute valu-
able insights most probably will lead to inappropriate research results. Technical
ICTD could be more effective when involving end users along the entire research
lifecycle.

On the second level, the methods used in the individual lifecycle phases
need to be adapted to cope with the cultural, infrastructural and governmental
challenges of ICTD research like the language barrier, cultural lack of under-
standing, missing requirements definitions, end user trust creation, low literacy,
low computer literacy, spatial separated researchers and end users, and difficult
infrastructure and governmental setups.

The following chapter provides information on related work and underlines
the need for user centered technical ICTD. In chapter 3 we describe the pro-
posed methodology on an overall and individual lifecycle phase level. Chapter
4 provides lessons learned during our research work, necessary to execute valu-
able technical ICTD research. With a conclusion and possible future research
activities we conclude the paper in chapter 5.

## 2 Related Work

In this chapter we provide an overview of current ICTD and Mobile HCI research
literature, its individual weak points and how they could benefit from each other.
We present possible innovation models in theory and with practical examples.

Jonathan Donner's review [4] of roughly 200 studies on mobile phone usage in the developing world reveals the huge variety of different ICTD studies which underlines the broadly interdisciplinary field of ICTD compared to the much more narrowed field of technical ICTD. His review shows that there is still a separation of ICTD and non-ICTD research, which in real life doesn't exist: "people's lives cannot be compartmentalized into separate categories such as economic, social, religious and cultural ... they are all part of the same person's experience and concerns" [5]. Technical ICTD research could be much more effective without this distinction but taking into account the non-technical factors, which are the people and their environment.

In a review of 102 publications on Mobile HCI [6], Kjeldskov and Graham
revealed that only very few studies have been done in real settings, using studies
of situated use. Most of the studies focused on the technical aspects of prototyp-
ing. If at all, prototype evaluations have been executed in artificial environments,
often without any information on success, failure or shortcomings of the utilized
methods. This clearly depicts a lack of use of end user involvement and real en-
vironment methods like action research, case and field studies which are of most
value for technical ICTD research. Whereas technical ICTD could benefit from
methods for mobile research, Mobile HCI could benefit from a new research field
using research methods that are currently not frequently used and thus limit the
effectiveness of the research field itself. Due to the huge opportunities of mobile
computing in developing countries, Mobile HCI research methods perfectly fit
into the technical ICTD research focus.

In the ICT4D Manifesto [2] Richard Heeks addresses the need for new inno-
vation models and identifies three of them. Pro-poor innovation is done outside
the target community but on their behalf (e.g. OLPC laptop). This top-down ap-
proach contains the risk of design versus reality gaps that could be seen with the
initial telecenter model. In the para-poor model, which combines participatory
design and action research, the innovation is done with and within the target
community, leading to much more appropriate research results. Per-poor inno-
vation is done within and by the community itself. Even if this model might be
promising in future and first mobiles, then computers, and now the internet be-
gin reaching the poor communities it will need more time to let the communities
themselves innovate on a large scale. Thus, currently the para-poor innovation
model seems to be most appropriate for technical ICTD research.

One project that made a successful shift from a failing pro-poor start towards
a successful para-poor development is the Warana Unwired [7] research project.
It started with the installation of 54 PC kiosks in rural India with goals defined
without detailed on-site requirements analysis. In 2005 an ethnographic study on
the Warana project revealed that none of the initial goals have been met because
the people had completely different demands. With these study results the use
case was re-designed towards the real requirements using appropriate technol-
ogy and content resulting in an appropriate frequently used solution. Another
para-poor project is CAM [8], which provides an architecture for developing and
deploying mobile services in the rural developing world. To gather the system
requirements an extensive field study with all use case stakeholders was con-
ducted. The tight interaction with the end users led to a system appropriate to
run in the specific ICTD context. Techniques like ethological studies and field
studies to gather the requirements, and evolutionary design or rapid prototyping
have been used successfully in a project on HIV/AIDS in South Africa [9]. Due
to an extensive stakeholder analysis, requirements gathering and the utilization
of a so called "local champion", the project started with a clear definition of the
use case scenario. The local champion is a person out of the target community
with a high interest in driving the research. He is the local contact and maintains
enthusiasm in the target community.

A majority of technical ICTD research today already utilizes user centric
methods, but only partially along the entire lifecycle. There is hardly any in-
formation on projects covering the complete technical ICTD lifecycle with user
centered research methods. This might be a) because of the high costs and time
consumption of User Centered Design (UCD) and action research in natural
settings b) because of a lack of information on how to efficiently utilize those
methods. New combinations of existing methods can make technical ICTD re-
search much more efficient [9]. In the following chapter we describe our proposed
set of appropriate research methods to support a user centered approach along
the entire technical ICTD research lifecycle.

3 User Centered Technical ICTD Lifecycle

The User Centered Technical ICTD Lifecycle describes a set of research methods with a clear focus on end user interaction and action research. In this chapter we describe our proposed overall approach and the adapted Mobile HCI research methods utilized during the individual technical ICTD research lifecycle phases.

## 3.1 Overall Approach

The results presented in this paper have been produced during a three year
research project in the ICTD context called Collaboration@Rural (C@R) [10].
The focus of C@R was on a procurement use case supporting small shop owners
in rural South Africa with only basic mobile phones and erratic network access
[11]. The overall framework in which the research took place was the Sekhukhune
Rural Living Lab (RLL). The Living Lab concept itself is built upon two main
principles: a) involve end users as co-creators and b) experimentation in real
world settings [12]. The combination of these two principles makes the Living Lab
a suitable playground to investigate the appropriateness of Mobile HCI research
methods adapted towards UCD and action research in context of technical ICTD.

The purpose of UCD is to serve the user, not to use a specific technology, or
to produce a scientific piece of software. In UCD the user needs dominate the
entire design and this is what technical ICTD should be about as well. UCD,
or participatory design, has been successfully used in Mobile HCI research [13],
and due to the huge opportunities of mobile technology in emerging economies
[14] will also be used in technical ICTD research. However, up to now Mobile
HCI methodologies haven't been utilized appropriately for technical ICTD re-
search which led to a number of failing projects [1][15]. Many ICTD projects
utilized UCD methods unchanged, grounded them on assumptions about end
user requirements and failed. The tight interaction with real end users within
the Sekhukhune RLL solves this problem and enables UCD based on real facts
[9]. Since the Sekhukhune Rural Living Lab approach covered the entire lifecycle
from requirements gathering to evaluation, all utilized research methodologies
have been used within a UCD and action research setup (see Fig. 1). This ensures
to be in natural settings all the time and eliminates the danger of losing focus on
real world problems and end users. The combination of top-down knowledge of
<table><caption>Fig. 1. Research methodologies per technical ICTD lifecycle phase</caption><thead><tr><th></th><th>Requirements</th><th>Design</th><th>Development</th><th>Deployment</th><th>Evaluation/Monitoring</th></tr></thead><tbody><tr><th>Case Studies</th><td>●</td><td>●</td><td></td><td></td><td></td></tr><tr><th>Field Studies</th><td>●</td><td>●</td><td></td><td></td><td>●</td></tr><tr><th>Lab experiments</th><td></td><td>●</td><td>●</td><td>●</td><td>●</td></tr><tr><th>Normative writings</th><td>●</td><td></td><td></td><td></td><td>●</td></tr><tr><th>Action Research</th><td>●</td><td></td><td></td><td>●</td><td>●</td></tr><tr><th>User Centered Design</th><td></td><td>●</td><td>●</td><td>●</td><td></td></tr></tbody></table>

researchers together with the bottom-up real world knowledge of the end users provides an effective way to conduct appropriate technical ICTD research.

The UCD approach was used during design, development and deployment realizing an iterative development in collaboration with the end users. Action research was utilized in the requirements, evaluation and monitoring phase. During the utilization of Mobile HCI research methods in our UCD and action research setup we have collected lifecycle phase specific issues necessary to adapt existing Mobile HCI research methods for the use within technical ICTD research.

## 3.2 Requirements Analysis

To avoid the flaw of previous failing ICTD projects that based their research on assumptions, a detailed requirements analysis needs to build the foundation of valuable technical ICTD research [16]. Current technical ICTD literature concentrates on presenting solutions only and lacks descriptions of research problems, requirements and definitions. Thus there is hardly any data available to ground new technical ICTD research on [3]. This enforces ICTD researchers to do expensive and time consuming on-site requirements analysis. But to avoid doing inappropriate research this is a mandatory requirement, or like Raj Reddy puts it: "If you want to develop new technologies or innovate old technologies for different contexts, you're crazy if you don't go to those contexts" [17]. During our research we did extensive on-site requirements analysis using Mobile HCI research methodologies adapted towards the ICTD specific requirements.

**Field Studies and Case Studies.** *Local contact.* During our research we've had the help of the Infopreneur™[18] - a trusted person within the rural community who offers basic IT services. A local contact is necessary for field and case studies since he often provides much more detailed information about cultural issues, he knows the people, the use case and the scenario. A foreign researcher easily could step over an important requirement just because of a lack of understanding of the local context.

*Local language and Trust.* During the workshops, interviews, and questionnaires it became clear that using the local language is mandatory. This was done with the help of the Infopreneur™. Since he is a trusted person, the answers he gathered have been much more precise and without distortion due to the fact of people not telling private or "bad" things to foreign researchers. People felt much more comfortable talking to him instead directly to us.
*Purpose of individual research methods.* Using workshops to gather insights into problems of an existing use case or to get feedback from the users about issues with use case stakeholders might provide misleading answers. People will not talk about governmental or community issues while sitting in a workshop together with other people from the same community. This kind of questions is much better elaborated in person-to-person interviews executed by a trusted person like the Infopreneur™. Workshops work fine to collect general feedback about a use case and especially for prototype testing and feedback rounds because of the community effect. People are much more willing to test a prototype when they are together with known people showing them how to use it instead of a researcher explaining a prototype in a top-down approach. Testing a prototype together with the community members also enables a more natural behavior and might reveal scenario issues that have not been on the researchers list before. Workshops are a well suited for initial design and prototype feedback rounds.

**Personas and Scenarios.** During the requirements gathering phase not only information on the required functionality of a piece of software is collected but also a lot of information about the end users and use case scenario itself. This information needs to be documented in a comprehensive way to provide basic research input for the technical ICTD community and to give project members that have not been on-site a clear understanding of the end user and use case environment. Personas and Scenarios [13] (pp.160-165) are an effective way to give for example the developer of a prototype, sitting thousands of kilometers away from the end user, a clear view of the end user. It helps researchers to understand that they build something for people within a completely different infrastructural, cultural and governmental environment.

## 3.3 Design Methodology

The design phase creates the first prototype mock-ups based on the requirements analysis and input from the end users and represents the starting point for the continuous prototype improvement during iterative development cycles.

**Participatory design.** *End user input.* After an initial design sketch continuous interaction with the end user takes place to create a prototype appropriate to the end users needs. Since it is difficult to keep in contact with end users in the rural areas with limited network access, again the Infopreneur™ serves as local contact for participatory design. Since he lives in the end user community and has basic IT knowledge he is a valuable information source during design phase. The Infopreneur™ is able to collect information from users during private talks, which often provides much more critical input than guided interviews. He also provides input to the design not possible to gather by a researcher visiting the area for two month and thus bridges the important cultural gap.

*Without any assumptions.* During design developers often tend to use well known concepts (e.g. semantic, syntax, designs) in their prototypes. However, these concepts might fail in the different context of technical ICTD. For example, today GIS (Geographical Information System) applications are a well known concept in the 1st economy, but there is no evidence to assume people in rural
areas of developing countries might ever have been exposed to a geographical map at all. Every detail needs to be questioned and tested in collaboration with the end users.

**Mock-ups and Functional prototypes.** *Paper based mock-ups.* The first mock-ups will be most probably paper based sketches that can be easily changed during end user interactions. Paper based prototypes are also effective to test basic concepts in rural settings since they are independent of electricity and connectivity and thus can be discussed also with end users in very remote areas without additional equipment.

*Functional prototypes.* In our research, functional prototypes directly followed paper based mock-ups without any other prototyping technique in between. Due to the lack of computer knowledge end users in developing countries have difficulties to understand concepts like "wizard of oz" where a human acts as a computing device. An example out of our research is that they had problems to understand why to use a specific syntax in a structured SMS (Short Message Service) message (e.g. 2xProductA) instead of clear text (e.g. Two times product A), if even they as a human could understand it - and a computer should be much more clever. Functional prototypes avoid those metaphors and can be tested in real settings. For effective tests, functional prototypes always have been exposed to end users during a workshop, using the community effect, and with the support of the Infopreneur™. However this approach makes functional prototype testing a very expensive and time consuming task - for both, researchers and end users since they need to travel to the workshop venue.

**Rapid Prototyping.** *Different context.* Rapid prototyping tests in natural settings are necessary to get end user feedback and to only rely on hardware and infrastructure available in the target scenario. In context of ICTD, the available infrastructure and hardware might be considerable less powerful than available resources in which the developer creates the prototypes. Thus testing on virtual machines reflecting the target environment is a good practice before testing the prototype in the real environment.

*Tests are not only about software.* Rapid prototyping not only provides feedback about human-prototype interaction but also about the entire system environment the prototype is deployed in. Rapid prototypes reveal all aspects of context specific limitation in the target area like infrastructural, cultural and governmental issues. There are many specific limitation 1st economy developers initially might not be aware of (e.g. some countries don't allow Voice over IP, limitations of telecom providers, different payment models, different usage of symbols, different infrastructure).

**3.4 Development Methodology**

Technical ICTD research often involves researchers creating solutions for a user community in another environment, even on another continent. To support this setup, additionally to the issues mentioned in the requirements and design phase, the following adaptations need to be made on the development methodologies.
*Iterative Development.* Especially in the difficult infrastructural and cultural environment of technical ICTD research, iterative development ensures appropriate and end user driven development. Developing something just top-down might be much cheaper and faster in the beginning, but contains the risk of producing just another piece of code no one will or can use. Then, redeveloping things quickly exceeds costs and time efforts for iterative development.

*First prototype iteration to build trust.* With iterative development and action research, the first development cycle needs to provide a robust prototype, ready to run stable in the target use case. This is necessary to build trust between the end user and the new system introduced by "foreign" researchers. People are skeptical towards innovations brought in by people not known in the community. If now, in this fragile setting, the first deployment of the prototype fails the end users will hardly continue to support the research work. For them the research influences their real life business.

*Context simulation.* Simulating the context of use during development ensures effective iterative development. It enables early prototype debugging and avoids spending money for a field trip just to find out that something is missing to run the prototype. We've learned this the hard way travelling 400 km to the end user just to recognize that the required flash player was not installed and there was no chance to download a few megabyte over the slow, expensive and erratic GSM (Global System for Mobile Communications) network.

*Environment setup as early as possible.* Due to the infrastructural and governmental context in which ICTD research takes place simple issues might become much more complicated. This might be governmental processes, infrastructural limitations, or interoperability issues specific to developing country regulations. One example within our research was the setup of a telecom service provider in South Africa. Sorting out the contract details and setting up the mobile phone numbers took much longer than anticipated.

## 3.5 Deployment Methodology

During our research in the Sekhukhune RLL we came across some important issues that need to be taken care about to ensure a successful deployment of prototypes within the iterative prototyping approach.

*Real Use Case - challenging but beneficial.* In a Living Lab setup, like the Sekhukhune RLL, prototypes are deployed and tested within a productive real use case. This requires prototypes to be very robust right from the beginning to avoid disappointed end users. Even if it is more challenging to deploy prototypes in a real use case it provides much more valuable results than laboratory tests. A real world deployment immediately provides feedback about appropriateness, acceptance and business value and thus the prototype iteratively becomes a productive system.

*Non-technical issues.* Before deploying a prototype in the target use case it is necessary to get all use case stakeholders informed and convinced. Since the deployment of an iterative prototype, following our approach, is deployed within a real use case, it is influencing real life business. In the C@R procurement use
case we had some issues with one use case stakeholder (delivery truck drivers) because they haven't been seriously trained about the new use case structure and thus felt threatened by the new technology. They are not the end users and have not been the focus of our technical ICTD development but since they belong to the use case they influence the entire research work as well.

*Support and Administration.* Iterative development with prototypes deployed in a real use case requires support for the end users. In our case the support was mainly done by the Infopreneur™, helping end users coping with the new system. The Infopreneur™ as local contact is an effective way to continuously provide support to the end user. Beside the end user support, system administration capacities need to be set up to monitor the deployed system and to solve problems immediately. During our research work this was done by the prototype developers themselves using an administration interface to the system. Administrative access to all system components is an important feature when deploying components in rural areas far away from any system administrator. Even if it is just a prototype a broken system always endangers the important trust relationship between end user and system.

## 3.6 Evaluation and Monitoring Methodology

The evaluation phase is the last step of one iteration within an iterative development approach providing input for the next cycle. The final evaluation phase takes part in the end of the entire development work to evaluate the final system in productive use. The monitoring phase utilizes the same methods but with focus on cheap long term options like log file analysis or the Infopreneur™ collecting information during regular chats with the end users.

*Direct observation.* Direct observation is used to get feedback from the end user using several observation technologies - usability expert, human observer and questioner, screen cam, web cam. In 1st economy prototyping it might make sense to utilize this methodology in an early stage already to reveal major design faults. However, in the ICTD context direct observation only makes sense at a late prototype stage since the costs and time efforts to transport the equipment and researchers to the use case scenario and to facilitate the evaluation workshop are high. We've used direct observation to test a very late prototype stage deployed in natural settings and executed it as a scenario based contextual walkthrough. Even in this late prototype stage which was created using iterative development and continuously end user input the direct observation still revealed some valuable usability issues.

*Questionnaire and Workshops.* Since the prototype evaluation via questionnaires often fails because of low end user literacy we've again used the support of the Infopreneur™. When using workshops for evaluation there is often the problem that the participants follow the comments of the person with the strongest voice or try to guess what the researchers want to hear and provide faked answers. When using the Infopreneur™ as workshop host users felt much more comfortable talking to him instead of talking to foreign researchers. Users also feel less "watched" and act much more natural when observed by the Infopreneur™ since
he is "just another guy from the community". Workshops provide a good en-
vironment for open questions. In an environment with so many differences in
infrastructure, government and culture these kind of open minded questions
might bring up completely new topics.

*Log Files.* The most simple but very effective way to evaluate a system is to analyze the system log files providing accurate information on system acceptance and usability issues. We’ve utilized log files to evaluate the usage of a mobile client within the procurement use case. The log files revealed several usability issues regarding the mobile client user interface and also provided insights in the usage characteristics (e.g. times of order placement). In the ICTD context log files also can be used to find out more about the end user behavior like, how many SIM cards a user has or information on the literacy level.

4 Lessons Learned

During the three year research project in the Sekhukhune RLL we adapted re-
search methods from the Mobile HCI research field towards a UCD and action
research approach for technical ICTD. These lessons learned provide practical
information for technical ICTD researchers and serve as input for the technical
ICTD research body of knowledge. In this chapter we summarize lessons learned
necessary to conduct valuable technical ICTD research.

Building trust with the target community is a major requirement. Without the trust of the users in a new use case design, the prototypes and business value the ICTD research falls flat - no user, no research. Action research and UCD significantly impact the daily business of end users and thus ICTD research comes with a huge footprint right from the beginning.

For effective technical ICTD research a local contact person with a good knowledge of the target community and environment, some IT knowledge and English language skills (e.g. Infopreneur™) is required. This person is important for a valuable execution of workshops, interviews, prototype tests, evaluation and for trust building in general. Using the Infopreneur™ to observe end users provides much more relevant information since they don't feel observed by a foreign researcher but just have a chat with the well known community colleague.

An effective solution for conducting technical ICTD research is user centered
iterative development in a real scenario. Beside benefits like the immediate val-
idation by real users it also comes with some requirements like: when deploying
a prototype in a real use case it becomes a running productive system and thus
needs to be handled as such. Iterative development ensures the appropriateness
of the solution regarding infrastructure, culture and governmental regulations.

Beside the technical challenges also human factors play an important role es-
pecially in ICTD research. The acceptance of a new technology or the adaptation
of an existing use case often requires the "community effect". When introduced
by a community member (Infopreneur™) end users are much more willing to
trust in the solution and use it. During the user centered approach continuous
contact to the end users is important to let them be part of the entire approach.
Ignoring comments from end users might lead to frustrated end users endangering the entire research project.

On a research project level technical ICTD research needs to be consequent in what is promised and what gets delivered. A disappointed end user community will not support research activities anymore. ICTD research, if executed within a real use case, should have the clear goal of being self sustainable. In technical ICTD, this might not be the overall goal since it is only one part of the entire ICTD research. However, when conducting technical ICTD research in a real use case it becomes important to be aware of the risks and consequences of failure.

# 5 Conclusion and Future Work

In this paper we propose a user centered technical ICTD research approach utilizing adapted Mobile HCI research methods in the individual research lifecycle phases. The proposed methodology set has been successfully used within the C@R research project. The presented methodology set is an initial step towards a clear methodology outline for technical ICTD. We want to encourage other ICTD researchers to evaluate and contribute to this kind of literature to establish a shared information source about technical ICTD research.

Since there was almost no literature available providing guidance on how to execute effective technical ICTD research, most of the research results have been gathered by a "try and error" approach. The missing literature knowledge together with the action research approach in a real use case imposes a huge responsibility on the researchers not to make mistake. The wrong research methods not only could lead to inappropriate research results but also have a real negative impact to the end users.

The presented research results are based on one use case, which is representative for many other developing country research scenarios but however, it is only one example. To prove and improve the concept, the current approach will replicated and evaluated in another ICTD research scenario.

To make technical ICTD research more efficient, a next step will be to improve the currently inaccurate simulation environments in which developing regions contexts are simulated for prototype tests in laboratory settings. This will not replace iterative in-situ prototyping tests within the natural settings but it will decrease cost and time effort for those tests. The aim is to already eliminate most of the prototype bugs in laboratory settings before spending time and money for a field visit. With appropriate heuristics, laboratory simulations might become an effective "low-cost" technical ICTD prototype evaluation technique.

Beside the weak research methodology outline, to which this paper contributes to, missing definitions like "what defines a novice user" or "what is a common device in rural areas" are another weak part of technical ICTD research. Basic definitions like these could help finding a starting point for ICTD researchers. Future work will investigate in the creation of a set of definitions required to execute valuable technical ICTD research.
References

1. Heeks, R.: ICT4D 2.0: the next phase of applying ICT for International Development. *IEEE Computer* (2008)

2. Heeks, R.: The ICT4D 2.0 Manifesto: Where Next for ICTs and International Development? (2009)

3. Toyama, K., Ali, M.: Computing for global development: is it computer science research? *ACM SIGCOMM Computer Communication Review*, vol. 39(5), pp. 40-43 (2009)

4. Donner, J.: Research Approaches to Mobile Use in the Developing World: A Review of the Literature. *The Information Society*, vol. 24(3), pp. 140-159 (2008)

5. Horst, H., Miller, D.: The Cell Phone: An Anthropology of Communication (2006)

6. Kjeldskov, J., Graham, C.: A review of mobile HCI research methods. *Lecture Notes in Computer Science* (2003)

7. Veeraraghavan, R., Yasodhar, N., Toyama, K.: Warana Unwired: Replacing PCs with Mobile Phones in a Rural Sugarcane Co-operative. *Proceedings of ICTD* (2007)

8. Parikh, T.S., Lazowska, E.D.: Designing an architecture for delivering mobile information services to the rural developing world In Proceedings of the 15th international conference on world wide web, Edinburgh, Scotland. ACM Press (2006)

9. Parikh, T.S.: Proceedings of the CCC Workshop on Computer Science and Global Development. In *Proceedings of the CCC Workshop on Computer Science and Global Development*, pp. 1-92, Berkeley (2009)

10. Friedland, C., Merz, C., v. Rensburg, J.: Stimulating the development of networked enterprises: the added value of Collaborative Procurement in rural South Africa (2008)

11. Doerflinger, J., de Louw, R., Friedland, C., Mengistu, M., Merz, C., Pabst, K.: Mobile Commerce in Rural South Africa Proof of Concept of Mobile Solutions for the Next Billion Mobile Consumers. In *WoWMoM 2009*, Kos (2009)

12. Ter Hofte, H., Lovborg Jensen, K., Nurmi, P., Froehlich, J.: Mobile Living Labs 09: Methods and Tools for Evaluation in the Wild. In *Mobile Living Labs 09 at Mobile HCI 2009 Conference*, page 48, Bonn (2009)

13. Jones, M., Marsden, G.: *Mobile Interaction Design*. John Wiley & Sons, Ltd (2006)

14. Toyama, K., Bernardine Dias, M.: Information and Communication Technologies for Development. *IEEE Computer Society*, vol. 41(6), pp. 22-25 (2008)

15. Heeks, R.: Information systems and developing countries: Failure, success, and local improvisations. *The Information Society*, vol. 18(2), pp. 101-112 (2002)

16. Doerflinger, J., Friedland, C., Merz, C., de Louw, R.: Requirements of a Mobile Procurement Framework for Rural South Africa. In *ACM Mobility 2009*, Nice, 2009. ACM Mobility (2009)

17. Baker, M.: The Challenges of Emerging Economies. *Pervasive Computing*, vol. 1536-1268, pp. 40-46 (2006)

18. van Rensburg, J., Veldsman, A., Jenkins, M.: From Technologists to Social Enterprise Developers: Our Journey as ICT for development practitioners in Southern Africa (2007)