Simplicity and Reliability: An Analysis on the Usability of TBCare Mobile Application
For a few months, a non profit organization named Persatuan Pemberantasan Tuberkulosis Indonesia (PPTI) have been working with University of Indonesia to develop an app called TBCare. It is pretty uncommon — at least for me — for nonprofit organizations like these to invest in a digital app. So, hearing about the existence of this app for the first time is quite shocking for me.
Let me indulge you in a scenario: PPTI has a lot of volunteers that are being dispersed across the region to track TBC patients. These volunteers are responsible to log new cases and track the treatment of patients in their respective areas. For a while, this process has been recorded and reported using paper. However, the time overhead of this method is becoming unbearable.
To alleviate this issue, PPTI has considered moving it’s administration of cases to electronic devices. Logging cases using an electronic devices is faster and more time-efficient than using paper and ink. They call this app TBCare.
TBCare follows a client-server model. Each volunteers will have an app installed in their mobile devices, which will communicate with the server database. The purpose of this mobile app is mainly for data entry.
There are four scenarios that this mobile app is supposed to handle. I have been tasked to test the existing TBCare app and check if these scenarios can be done. Considering the purpose of the app — which is to reduce administration overhead — , I will focus on the accessibility of the application itself: How intuitive it is to use, and how fast it is to perform these scenarios.
Downloading the Mobile Application
So, there is an artifact already published in the Google Play Store. It requires 23 MB of space, which is reasonable for modern smartphones. Bonus points for portability there.
Scenario #1: Authentication
After opening the app, I was greeted with a log in screen. The screen has your standard authentication page layout: One username input, one password input, and two button each for Sign In and Log in. If you do not have an account, you can ask for one by clicking Sign In. This will direct you to a standard Create New Account page. You can add your personal information here. However, you will need manual approval from an admin to get an active account.
If for one reason or the other, the application cannot perform a connection with server, you will be given a friendly yet concise error message
Interestingly, this error message does not appear if you fail to create a new account.
I logged in with a dummy account, and was given this main page.
This homepage in my opinion represents an important aspect that I like on this kind of app: simplicity. It is very important for this kind of app to be concise and simple. Each object that appears on your screen serves a purpose, and that purpose can be inferred just by looking at that object alone. There are two buttons, each for creating new cases and tracking existing ones. There is also one list view of your recent activities, and nothing else. No scrolling, no unnecessary navigation drawer, and no buttons that have to be explored in order to find out every feature of this app. This prevents a lot of possible confusion, and may very well reduce the overhead time required to be able to use the app.
A significant portion of TBC cases happens in rural or remote areas. This means that the volunteers — the user of this app — will likely be appointed locally. One cannot assume that these users will be adapt to technology to the point that they can use a regular mobile application properly. In this light, any measure that can reduce the learning time for our volunteers will mean a lot. Moreover, uncluttered user interface implies more direct activity flow, which will reduce the time needed in operating the app. Granted, there are apps that focuses on keeping user retention for commercial purpose, but in our specific cases here, a minute spent in using our app is a minute not spend in doing important works and helping people.
Scenario #2: Tracking Cases
After admiring the simplicity of the main page, I clicked the right button on the page, and was directed to the tracking page.
The first thing to be shown is the list of patients, and I was prompted to pick the one I wish to track. Intuitive enough. I picked one, and was shown this form.
The patient I had picked has the status of “Taking Medicine”, so it’s pretty safe to infer that “tracking” this patient means checking if they have taken their pills. The next page confirms this with the question “Has the patient drink their medicine today?”. Now, if I clicked the submit button after picking an option, I can still change the status whenever I want. However, there is one button that is located uncomfortably close to the submit button which says “End tracking”. After I click this button, this patient’s case will be marked closed. There is no confirmation nor a way to undo this operation from the mobile app.
This is problematic, since people can quite easily miss click the finish button and will probably wait for 24 hours for an admin to rectify the situation. A simple confirmation modal will go a long way to reduce the risk of incorrect data entry.
Scenario #3: Creating New Case Form
With the right half of the main page truly explored, I turned my attention to the left button and clicked the “Create New Case” button. I encountered a mediating form which is not so intuitive. It says “Select Reference Case”, which is quite ambiguous. The entries already shows each patient’s name, age, and sex. But in the next form, I was required to enter full name, age, and sex again. Why do I need these “References Case” then? Furthermore, the cases selected does not disappear after I entered a new case using that reference case. So, where did these “Reference Case” come from, and what is it’s purpose? Perhaps an actual volunteer would know what “Reference Case” means, but it’s confusing nonetheless.
Here, I was presented a new screen. The progress bar at the very top implies that there is a three step process in creating new entry. This is a nice feature in my opinion since it allows the user to know and prepare all the necessary data before performing data entry.
The first form asked for full name, sex, age, and address. The layout is standard, and there is no component beyond the “Next” button, which increases clarity. However, drop down entries for district does not match the sub-district entries. This means you can enter “District A, Sub-District B” even though B is not located in A. So, minus points on data integrity.
The next form asks for symptoms and risk factor of the patient. The layout is consistent and clear.
The last form asks whether this new cases requires further investigation.
Overlooking the data integrity issue, the interface on these three forms looks simple and clear. However, I find it difficult to double-check the data I have entered, since clicking “Submit” will immediately create new entries without my confirmation.
Scenario #4: Editing Case Data
There is one last feature that is supposed to be in the app. It is to edit the data of patients. The problem is, there is no editing screen. At least nothing obvious. There is one way to perform data editing, which is through the “Track Patient” and update the status of the patient. But that is a very limited editing ability.
It is only after 24 hours that I got notified by one of my colleague that Ican actually edit an entry by clicking the log entry on the bottom of the home page. After which, you will be redirected to an edit form.
I can see the justification of putting the edit feature in the home page, but I think it is not intuitive and counterproductive. Firstly, a log typically should only function as a trace of what has been done. It is not supposed to be a link to some edit form. I do not think anyone will expect an edit form to be accessible this way. Secondly, there is no search bar in the log list and the list is ordered chronologically. This is good if the log is used as a “quick overview” of the most recent events. But if a list is also used as a gateway towards an edit page, you will need to implement a searching/filtering method. Searching for a specific patient on a list ordered chronologically is going to be time consuming, and the necessary feature to make this searching easier is simply not implementable on the home page.
Conclusion
Overall, the TBCare mobile application has followed the general user experience principle accurately. Each screen looks like it is built for simplicity and intuition. However, there are some data integrity issues such as the inconsistent address form and the risky “End tracking” button without confirmation, which might create unnecessary overhead. Furthermore, the editing feature is placed inappropriately.
I would suggest creating a more sophisticated form, build an extra scene on the “create new case” feature where the recap of the form is presented for confirmation, add a confirmation modal for risky operations such as “End Tracking” or submitting a new case, and create a separate page for searching and editing cases.
Furthermore, the current build of the application is a bit too dependent on internet connection. Consider a case where our brave volunteers are serving in an area with internet access only in select areas. It will be impossible for them to open the app at all. Instead, I suggest an offline mode where users can log new cases on their devices locally until they can get internet access. This system will allow all data logging to be a lot easier and more reliable.
Reference
https://www.who.int/news-room/fact-sheets/detail/tuberculosis
