Keywords

1 Introduction

In social interactions, citizenship, political awareness or public services, the use of Information and Communication Technologies (ICT) solutions to facilitate the communication and spread of information may play an important role in the development of a given community. Gathering people around one topic or gathering the necessary information about a city, being it about a community problem, market prices, health or other public services, may strongly contribute to human development. Still, access to ICT is not available for all citizens, with the problem being further aggravated in developing countries [1].

Despite of ICT increasing popularity (e.g., mobile broadband access is cheaper; half of world population is online; 7 out of 10 youngsters are connected), there is much to do in what concerns to Internet access (Percentage of disconnected are: 33% in developing countries; 70% in least developed countries; 90% of non-connected youngsters are in Africa or Asia and the Pacific; women access is 25% lower than men in Africa) [2].

Upon this, the development of community tools should promote social and digital inclusion of these citizens located in underserved communities. These tools are expected to combine the use of new technologies and digital education, bringing the interactivity, innovation, and inclusivity for underserved groups, which are still put aside due to the digital divide.

In this paper, we present IZIDoc and OurMoz. A pair of community tools, developed to improve the quality of life of the citizens. Based in a scalable and widely used framework - i.e., Material Design [3] from Google – these tools aims to reduce the gap between the western interface design pattern and the purposed solution, which was created, designed, tested, and validated with users from a community with different levels of digital literacy, namely in Mozambique.

The paper is structured as follows. Section 2 describes the context in which the community tools shall be used, considering the profile of the Mozambican citizens, the areas they live in, and the technology they have access to. Section 3 presents the user-centric design process used in the development. Section 4 details the validation tests and obtained results from the testing methods used. Section 5 describes the relevant redesign work carried out after the validations tests. Finally, Sect. 7 concludes the work, providing insights on the future next steps.

2 Contextual Description

The context in which IZIDoc and OurMoz applications could be applied considers the profile of the Mozambican citizens, the areas they live in, and the technology they have access to. As aforementioned, we reduced the scope of the work to Mozambique, but at a later stage we want to further consider other countries and validate the tools with the respective users as further explained in Sect. 7.

Since Mozambique comprises different provinces and municipalities, we built the profile of the citizens of Maputo city and its surrounding, based either on accounts from the citizens or on field visits to Mozambique, as described next.

2.1 Setting

The most common settings of Maputo and surrounding areas where citizens find themselves can be divided into urban and suburban areas.

Urban areas are parts of the city with better conditions such as pavement roads, tall buildings, better availability of services and overall better quality of life; Internet connectivity is available by subscription at homes, and for free at universities.

Suburban areas tend to be more humble, often with large numbers of people living in small houses built with little planning and bad materials, precarious sanitation, difficult access by car to some parts due to narrow pathways that do not accommodate cars, no pavement on the roads, creating a mix that results in overall worst quality of life; Internet may be available at Internet cafés in these areas, but users may resort to their mobile data plans, which can be less costly.

2.2 Users

Regarding the users, we observed that the community tools should consider different characteristics from which we highlight in Table 1, considering different aspects.

Table 1. Observed aspects and characteristics of the target user.
Full size table

It is worth noting that the list is not meant to be exhaustive, and we may have left out aspects/characteristics that can be as relevant as the aforementioned ones. However, our main goal is to understand the community and respective users to meet their needs and expectations throughout the development of the proposed solutions.

3 Proposed Community Tools

The community tool IZIDoc aims at improving the process of requesting a document from an official entity, e.g., requesting a new ID card from the registry office.

Often citizens find themselves losing significant amount of time in long queues to perform tasks that could be easily simplified, using a smartphone. IZIDoc was designed to reduce the time spent in those queues, allowing the user to request a document or provide information about all the process and needs to acquire such document.

For documents that have been requested and are yet to be issue, the user is able to check the status of the request and details about the document in case. Once the document is issued, the application notifies the user of its readiness and the user shall proceed to collect the document in the near service point. Saving time of both citizens and entities, since the application overcomes the need of requesting documents in person.

Regarding OurMoz, the citizen is expected to have a more proactive behaviour within society. This proactiveness relates to the fact that the user will have the possibility to report on any issue (e.g., a broken pipe, an unattended garbage bin) that may affect his/her community’s quality of life. Upon an issue (e.g., broken pipe), the user may add it to the city’s repository, and once the issue reaches (i.e., it is posted to) the authorities (e.g., Water department), they will send a team to fix what has been reported. Location, small description, and picture can also be added to the reported issues, which can be used by authorities to assess such issues and even prioritize the order of work to resolve them. Keeping the process of reporting as simple as possible, in order to encourage users to participate in the process of improving their communities. The user can also search for specific issues or items related to issues of interest (i.e., to find out for instance if there are any other reports on the same issue).

3.1 Design Approach

Based on the context and profile of the target community, we followed a user-centric design approach while developing the IZIDoc and OurMoz applications. An iterative methodology, which began earlier by analysing and understanding the context of the user, followed by the specification of user requirements, creating personas and scenarios that are suitable for users’ needs and expectations.

We prototyped possible solutions using storyboards and mockups allowing us to quickly design, discuss and redesign ideas, considering the user, its context, and its tasks within a framework that ensured a present-day user interface [3].

However, the validation tests have proved the need of several adaptations in the user interface as further detailed next (cf., Sect. 4).

4 Validation Tests

The process of designing suitable solutions for the context of the target user considers the evaluation of the designed prototypes, in order to discover if there are usability problems in the user interface regarding IZIDoc and OurMoz applications.

Both applications were submitted to two validation phases, considering Human-Computer Interaction experts and potential users, respectively. Our goal with these two validation methods was to gather feedback from experts and potential users, using quick and effective tools to evaluate the user experience of both applications, and to further improve both applications upon those issues.

4.1 Heuristic Evaluation

For the first validation phase, we used heuristic evaluation for mobile computing [4] to help development team members to identify and estimate the impact of each issue found during the development process, and a severity rating scale [5], a well-known method that allows to allocate the resources to fix the main problems and provides an estimate effort for additional usability resolutions.

Heuristic evaluation was carried out by three researchers with a wide working experience in user testing. However, we ensure that two of them had no contact with the project, in order to ensure an independent and unbiased evaluation for comparing purposes. The results were recorded as written reports, summarizing all issues from the evaluators. As for the severity rating, the evaluators were asked to estimate each usability issue found, in order to understand their impact in the user experience.

Gathering the results from the researchers, we analysed and discovered a total of twenty-seven reported issues in IZIDoc (nine issues with severity level 1; eight issues with severity level 2; and ten issues with severity level 3), from which the most relevant are summarized in Table 2, along with the proposed solutions.

Table 2. Reported issues and implemented solutions for IZIDoc.
Full size table

As for OurMoz, the researchers identified twenty-one issues (two issues with severity level 1; fourteen issues with severity level 2; and five issues with severity level 3). Table 3 presents those issues that required more attention and respective solutions.

Table 3. Reported issues and implemented solutions for OurMoz.
Full size table

Regarding this analysis and its importance to the development cycle, these were the most relevant issues and that led to meaningful changes to the user interface (UI). It is worth noting that, independently of the severity level, all the reported issues were considered during the UI improvement process for IZIDoc and OurMoz.

4.2 Field Tests

On a second validation phase, we followed the usability test protocol [6], which uses three usability metrics: (i) effectiveness, expressed in terms of unassisted and assisted completion rate, number of errors, and number of assists; (ii) efficiency, measured in terms of task execution time, i.e., time taken to successfully complete a task; and (iii) satisfaction, expressed in terms of a usability score, obtained by a System Usability Scale [7] questionnaire which all participants completed after each test session.

This validation phase was performed in Mozambique and driven by two native administrators, which recorded all tests for later analysis. These tests (cf., Fig. 1. Field tests regarding IZIDoc (on the left) and OurMoz (on the right). Fig. 1) considered 21 users (IZIDoc: 10; OurMoz: 11), where 6 were women and 15 were men.

Fig. 1.
figure 1

Field tests regarding IZIDoc (on the left) and OurMoz (on the right).

Full size image

The target user population was broad in terms of age and gender, aged between 18 and 41, and one of the inclusion criteria for the test was that they were required to know how to use a smartphone. Each user performed 4 tasks for both IZIDoc and OurMoz (cf., Table 4). The overall system usability score, for both applications, was between 77 and 87, which is above the suggested reference value [7] regarding applications that meet the minimum usability requirements.

Table 4. Tasks performed by users with IZIDoc and OurMoz.
Full size table

During the tests with the IZIDoc application, the users had no issues with Task A. Regarding Task B, the users were uncomfortable with the scrollable tabs, which hid part of the document categories and that most of the users did not realize it was a scrollable component display.

In Task C the users have difficulty on finding the refresh action to update the current list which was hidden in a menu in the action bar, and, lastly, in Task D many of the users did not notice the notifications regarding the status of the requested documents. Regarding OurMoz application, the administrators identified the following events: the users had no issues related with the Task E; in Task F, the floating button (plus icon) which provided the main action of the application - Adding an occurrence – appeared obfuscated due to the background images, and, even so, the plus icon was too abstract to be related with activation of the main action.

As for Task G, the results were apparently better than those from the IZIDoc’s Task C. This was due to the fact that some of the users had already participated on the similar task on the IZIDoc’s application usability test, or they discovered the functionality of the button during their attempts on the OurMoz’s Task F.

Finally, in Task H, it was noted that many times users shifted the right order for the fields corresponding to ‘De’ and ‘Até’. In other words, they selected the actual date for the field ‘De’ (from) and the previous date for the field ‘Até’ (To).

5 Redesign Approach

After the validation tests, we analysed its outcomes and, considering the common findings on the two applications, the redesign team proposed the following.

In order to overcome the difficulty in updating the documents status list (Task C) and the occurrences list (Task G) which involved finding the ‘Refresh’ action, we incorporated a direct icon placed in the action bar (Fig. 2a) instead of having the refresh action within a hidden menu. We also decided to highlight the search bar when activated by adding a lighter background colour to the text input field in order to focus the search intention (Fig. 2b).

Fig. 2.
figure 2

(a) Update/refresh icon placed in the action bar (left: IZIDoc; right: OurMoz); (b) Search form emphasized (left: IZIDoc; right: OurMoz).

Full size image

Secondary actions and its ‘text buttons’ needed to be emphasized and distinguished from the normal text, for that purpose we added a light background colour as if the button was focused (Fig. 3a). Another relevant resolution was about the layouts’ update throughout the app, providing a continuous data actualization and that is crucial for this type of tool, which relies on the updates by the server side.

Fig. 3.
figure 3

(a) Emphasised ‘Text buttons’ (left: IZIDoc; right: OurMoz); (b) IZIDoc: Tile navigation with documents’ categories; (c) IZIDoc: List navigation with the requested documents status.

Full size image

One of the main improvements was enabling the user to request documents or report occurrences being offline (as connectivity may be intermittent) with requests and reports being sent automatically when connectivity is restored.

Regarding IZIDoc’s specificities and the usability issues pointed out in the validation tests, the redesign solution aimed to tackle the following constraint, seeking improved alternatives. Concerning the users’ difficulty on using the scrolling navigation tabs, which organized the documents by category, we solved by suggesting a new display screen to navigate through the documents’ categories with tiles (Fig. 3b), avoiding hidden tabs/categories.

To ensure consistency along the interface, the navigation through two fixed tabs which organized the documents by its status (‘A processar’ and ‘Pronto’), was also replaced by a full list of documents organized by request order. The document status and a related icon were placed beside each listed document (Fig. 3c).

Considering OurMoz’s findings, we started by improving the obfuscation of the application main action, replacing the floating button component ‘+’ by a persistent footer button entitled ‘Adicionar Ocorrência’ (Fig. 4a).

Fig. 4.
figure 4

(a) A ‘Persistent footer button’ for the main action instead of the floating button component; (b) Image picker with a straightforward interface; (c) Dates older than the one selected on the ‘De’ field are disabled for the ‘Até’ field.

Full size image

To provide a straightforward interface related with the image picker, we opted for a ‘call to action’ display by adding the sentence ‘Adicione uma foto’ followed by the two options: adding a photo taken by the phone camera or a photo stored at the photo gallery (Fig. 4b).

Then, to better guide and simplify users’ date input, using restrictions, the allowable dates for the ‘Até’ field are now newer than the one selected on the ‘De’ field.

Finally, we also included a map view with (i) pending occurrences enabling a different experience on the perception of the issues per area; and (ii) with location of a specific occurrence helping the user on better understand the mentioned location.

6 Discussion

The validation tests proved that a widely used user interface design framework [3] may still entail usability constraints depending on the users’ level of digital literacy. Some of the proposed components may not be easily recognized by the users in their associated action. Thus, they require a level of abstraction that may trigger a rejection during the initial contact with both applications.

We followed with a redesign work, as described in the Sect. 5, avoiding abstract and unfamiliar concepts in order to provide a straightforward user interface, still considering the Material Design guidelines from Google.

7 Conclusions and Future Work

This paper presented two solutions – IZIDoc and Ourmoz – to users from underserved communities, identifying their main characteristics, settings and commonly used technology. Following a user-centric design methodology, requirements, user tasks, personas, and scenarios were identified, allowing the development of prototypes that were tested iteratively, throughout several usability tests – heuristic evaluation and field trials. This process allowed us to identify multiple usability improvements in both applications, leading us to a stable version of both community tools.

As future work, we have planned to extend the validation test beyond the Mozambican context, including other countries, in order to increase the usability of the tools. Moreover, we want to make both systems more inclusive by allowing (digitally) illiterate users to perform the proposed tasks. At the time of the writing of this paper, our experts were on a field trip to Mozambique interacting with technically challenged and illiterate users, to understand their needs so we can update the proposed community tools from this perspective.

Finally, we want to further extend these community tools: OurMoz can include different types of reports; and IZIDoc can be updated to include other institutions offering other types of services/documents. This is possible since both applications were built on top of a flexible and modular architecture.