1 Introduction
-
We carried out automated extraction and translation of over 5 million user reviews for mHealth apps;
-
We carried out automated classification of these over 5 million mHealth app user reviews into 14 aspects;
-
We compared users’ satisfaction levels across different subcategories of mHealth apps, identifying key areas of user problems and satisfaction;
-
We validated our results via manual analysis of a sample of 1000 reviews for each classified aspect (14,000 reviews in total);
-
We identified where significant issues and problems are raised in user reviews among different aspects of mHealth apps; and
-
We provide a set of recommendations for mHealth app developers based on the analysed aspects of these apps in our study.
2 Motivation
-
RQ1 - Based on user reviews, what aspects of compliments and criticisms do mobile users have for mHealth apps? – We wanted to find out to what extent do different app aspects and app subcategories affect an app’s ratings. Users can express positive or negative assessments of different mHealth apps by submitting reviews. In this RQ, we analyse user reviews for different mHealth apps and classify them into different aspects. This allows us to identify aspects of compliments and criticisms in these reviews related to different app aspects. Additionally, we investigate user assessments and perceptions of these reviews in relation to different mHealth apps’ subcategories and how they affect star ratings.
-
RQ2 - What are the key issues and problems raised by the users for each analysed aspect? – Different aspects have a different impact on users’ usage and ratings of mHealth apps. In this RQ, we analyse app reviews and classify them into the different aspect(s) of the mHealth app that the user is commenting on. We investigate the frequency of these issues/problems that affected their usage for different aspects and mHealth app sub-categories. This allows us to identify frequent issues and problems raised by the users and give some evidence-based recommendations to handle these issues. Our findings will allow developers to ensure better practises for mHealth apps design and development.
3 Study Design
3.1 mHealth Apps Dataset and Subcategories
mHealth apps subcategory | Apps that... |
---|---|
Fitness activity tracking | ... allow users to track their physical activities or movements, |
e.g.: “Strava: Track Running, Cycling & Swimming” and “Fitbit”. | |
Fitness and workouts | ... allow users to access fitness workouts and exercises, e.g.: |
“Home Workout - No Equipment” and “Mindbody: Home | |
Workout & Fitness App” | |
Diet and weight loss | ... allow users to access weight or improve their eating regimen, |
e.g.: “Simple: Fasting & Meal Tracker” and “Lose It! | |
– Calorie Counter” | |
Education and Information | ... allow users to access medical information and advice, e.g.: |
“Reflectly: Self-care journal” and “Motivation - Daily quotes” | |
Mental Health | ... allow users to adjust or improve their mental health, e.g.: |
“Moodistory Mood Tracker, Diary” and “Replika: My AI Friend” | |
Sleep and meditation | ... allow users to improve their sleeping or relaxation habits, e.g.: |
“Moshi: Sleep and Mindfulness” and “Sleep Booster - Sleep Better” | |
Patient health tracking | ... allow doctors to track, e.g.: “Instant Heart Rate: |
and self-monitoring | HR Monitor” and “HeartWatch: Monitor Heart Rate” |
Women’s health | ... allow women to improve their general health and habits, e.g.: |
“Flo: Health & Period Tracker” and “Clue Period & Cycle Tracker” | |
Emerging | ... are released by developers in a short time span as a result |
of unexpected event such as COVID-19 apps, e.g.: | |
“COVIDSafe” and “NHS COVID-19” | |
TeleHealth and telemedicine | ... allow users to have online appointments with their doctors |
and access their prescription, e.g.: “HealthEngine” and “Well | |
Pharmacy NHS prescription delivery” | |
Lifestyle Planner and | ... allow users to change their lifestyles and set goals, e.g.: “I’m |
Goal Tracker | Done Drinking” and “Shibboleth Lifestyle Journal” |
Scheduling and reminders | ... allow users to schedule or make reminders to healthy activities, e.g.: |
“WaterMinder” and “Workout Calendar - Motivation” |
3.2 Investigated App Aspects in User Reviews
App Aspect | A user review containing... |
---|---|
Privacy | ... privacy or security related issues, e.g collecting or accessing |
users data, information, location, etc. | |
Stability | ... stability or failure related issues, e.g. crashes, freezes, bugs, etc. |
Advertising | ... ads or commercials related issues, e.g frequent ad banners, |
pop-ups, etc. | |
Requests | ... user requests related issues, e.g. feature, bug fix, app updates |
requests, etc. | |
Uninstallation | ... users deleting or uninstalling the app because of privacy, stability issues, etc. |
Payments | ... billing or subscriptions related issues, e.g in-app purchases, premium upgrades, etc |
Compatibility | ... OS or HW related issues, e.g. unsupported versions, OS requirements, |
unsupported external devices, etc. | |
Resources | ... resources related issues, e.g. battery drainage, memory usage, etc. |
Connectivity | ... connectivity or networks related issues, e.g. Bluetooth, 3G, |
4G, WiFi, NFC, etc. | |
Account and | ... accounts or logging related issues, |
Logging | e.g. sign up, login, logout , etc. |
Resources | ... resources related issues, e.g. battery drainage, memory usage, etc. |
Notification | ... notifications or alerts related issues, e.g. too frequent or few |
alerts, notifications, etc. | |
Updates | ... app updates related issues, e.g. bugs or software issues after |
updates, etc. | |
Internationalisation | ... internationalisation related issues, e.g. language, culture, |
countries, etc. |
3.3 Automated App Reviews Analysis
-
The tool first uses GooglePlay and AppleStore open APIs to extract user reviews. If a review is not written in English, it uses the Google Translate API library (Translate 2021) to detect the language of all the reviews and translate them into English.
-
The tool then preprocesses each review by (i) correcting misspelt words, (ii) performing stopwords, and (iii) stemming the text.
-
It then classifies each review as addressing zero or more of our 14 different app aspects. To do this we use the keywords chosen based on our work manually analysing over 23,000 user reviews (Haggag et al. 2021).
-
Finally, the tool automatically generates various statistics for each app subcategory, app aspect, appstore, and overall.
mHealth App Subcategory | Number of Reviews | Number of Apps |
---|---|---|
Fitness Activity Tracking | 1,379,126 | 64 |
Fitness and Workouts | 1,420,762 | 47 |
Diet and weight Loss | 644,584 | 39 |
Education and Information | 216,429 | 23 |
Mental Health | 113,818 | 11 |
Sleep and Meditation | 558,997 | 34 |
Patient Health Tracking & Self-monitoring | 159,798 | 21 |
Women’s Health | 1,083,157 | 31 |
Emerging | 39,082 | 5 |
TeleHealth and Telemedicine | 19,387 | 12 |
Lifestyle Planner and Goal Tracker | 155,038 | 17 |
Scheduling and Reminders | 80,673 | 11 |
3.4 Step 4 – Manual App Review Analysis
4 Findings
4.1 UI and UX
4.2 Users Requests
4.3 Payments
4.4 Stability
4.5 Compatibility
4.6 Updates
4.7 Connectivity
4.8 Internationalisation
4.9 Account and Logging
-
Complex signup forms where users need to complete and submit too many details or information.
-
Buggy signup forms where users face errors while entering their data within the registration form.
-
Verification codes are not delivered to the email where users can not access the confirmation link to confirm their account and complete the registration process.
-
OTP (One-time password) codes are not delivered to mobile numbers where users can not complete the registration process.
-
Incorrect verification codes where users get errors when they submit the verification code they have received.
-
Since some phone number formats are not supported, some users may encounter errors when entering their phone numbers. This issue caused these users not to be able to complete the signup process to use the app.
-
Users forgot their users’ names, and they could not retrieve them. This issue leads users to not log in to the app anymore and force them to create a new account.
-
Forgot passwords functionality is not working properly where users can not reset their password if they forgot it. This issue is caused by either getting an error while filling out the reset password form or not receiving the reset email.
-
Apps send an OTP (One-time password) to the mobile number of the users where users do not have access to this number either temporarily or permanently.
-
The app keeps signing out, requiring users to log in each time, causing a great deal of inconvenience.
-
Users are trying to log in while the app is temporarily down. This issue happens when users receive no notification about the problems and outages of the app, so they reset their passwords; however, this does not solve the issues, and they are still not able to log in.
4.10 Notification
4.11 Privacy
-
Apps pasting user’s most recently copied text once they are opened.
-
Apps accessing users’ locations in the background.
-
Apps gaining access to users’ contacts.
-
Apps gaining access to users’ cameras.
-
Apps gaining access to users’ photo galleries.
-
Apps gaining access to users’ microphones.
-
Apps gaining access to users’ other devices that are connected to the local network.
-
Apps gaining access to users’ Bluetooth.
-
Apps tracking users’ interaction with other apps.
-
Apps asking for users’ private information such as date of birth.
-
Apps forcing users to accept their lengthy and complicated privacy policies before they can use.
4.12 Uninstallation
4.13 Advertising
4.14 Resources
5 Discussion
5.1 Implications for Practitioners
Key issues found | Recommendations |
---|---|
- Developers not implementing important | mHealth app users often use apps under very |
UI requests by elderly/disabled users | stressful conditions e.g. managing severe illness |
– key UI/UX issues reported need to be priori- | |
tised by developers | |
- Changing app interface frequently or | - Implementing simple designs for mHealth |
implementing complex designs | apps |
- One interface for all users | - mHealth users are very diverse – need to al- |
low users to switch between / configure inter- | |
face depending on their diverse needs and ex- | |
periences | |
- Issues with old firmware versions and | - Many mHealth users have old handsets – de- |
updates | velopers need to test UI thoroughly on differ- |
ent devices with different operating systems, | |
screen sizes, etc before releasing updates |
Key issues found | Recommendations |
---|---|
- Developers ignoring and not address- | - Some mHealth apps require frequent updates |
ing commonly reported issues in sub- | addressing repetitive feature and enhancement |
sequent updates | requests submitted by users to remain useful |
e.g. Goal planning, Lifestyle tracking, Educa- | |
tion and response by developers is essential | |
- mHealth apps not thoroughly tested, | - Testing the app thoroughly and ensuring the |
which leads to many users’ complaints | quality assurance (QA) phase before releasing |
and requests | updates to the users as these are health-critical |
apps – they are improving and saving lives | |
- mHealth apps not adhering to up- | - mHealth apps may become out-of-date when |
dated health advice/treatments | new medical research findings are released and |
need to be proactively updated to ensure they | |
are not unsafe/give wrong advice/implement | |
wrong interventions |
Key issues found | Recommendations |
---|---|
- Hidden app costs/Nontransparent to | - The description of any mHealth app should |
use full functionality of mHealth apps | clearly state if it requires extra cost to use all |
functions before users become dependent on it | |
for their health needs | |
- Incorrect and unclear mHealth app | - mHealth apps may be free for a certain trial |
free vs paid description | period to allow users to test functionality be- |
fore purchasing the app and becoming depen- | |
dent on it | |
- Sometimes viewing or analysing | - Users should be able to receive a refund using |
mHealth app user records leads to | a simple form and process |
unauthorised payments where users | |
are wrongly charged as an in-app pur- | |
chase feature | |
- Charging users after trialing some | - Automatically cancelling free trials and/or |
mHealth features although users are no | reminding users to cancel their free trials for |
longer using it | health features before being charged |
- Users are unable to unlock the pre- | - Careful testing to ensure that users who pur- |
mium mhealth features even after pur- | chased the app will have no issues to unlock |
chasing or subscribing to the premium | all premium mhealth functionalities |
version | |
- mHealth users are unable to restore | - Careful testing to have an in-app-purchase |
in-app-purchasing after changing their | restore button in a clear place in the app |
mobile or using a different device |
Key issues found | Recommendations |
---|---|
-users encounter bugs while analysing | - Developers need to proactively analyse user |
or processing their mHealth data | reviews and addressing key reported bugs to |
ensure health dependent end users are not se- | |
riously impacted | |
- Apps crashing/freezing when process- | - Ensuring the existence of enough computa- |
ing and mining specific mHealth tasks | tional power based on the users data size; test- |
ing practices need to include range of realistic | |
mHealth app user datasets and loadings | |
- Some mHealth functionalities get | - mHealth users become dependent on apps for |
buggy only after developer updates | health needs and hence all functionalities need |
stringent testing across multiple devices before | |
releasing updates |
Key issues found | Recommendations |
---|---|
- Developers not implementing impor- | mHealth app users often use apps under very |
tant UI requests by elderly/disabled | stressful conditions e.g. managing severe illness |
users | –key UI/UX issues reported need to be priori- |
tised by developers | |
- Changing app interface frequently or | - Implementing simple designs for mHealth |
implementing complex designs | apps |
- One interface for all users | - mHealth users are very diverse – need to al- |
low users to switch between / configure inter- | |
face depending on their diverse needs and ex- | |
periences | |
- Issues with old firmware versions and | - Many mHealth users have old handsets – de- |
updates | velopers need to test UI thoroughly on differ- |
ent devices with different operating systems, | |
screen sizes, etc before releasing updates |
Key issues found | Recommendations |
---|---|
- mHealth apps suffering from major | - Testing mHealth apps with realistic range of |
bugs after being updated | end user devices, usage scenarios before releas- |
ing updates | |
- Users requesting updates to add/re- | - Proactive monitoring, prioritisation and han- |
move mhealth features and function- | dling of update requests |
alities, fix some bugs with analysing | |
health data, or increase accessibility | |
- Repetitive update requests for the | - Better triage of requests to address common |
same issue from different users | update requests raised by different users |
Key issues found | Recommendations |
---|---|
- Some analysis and training mHealth | - Showing an internet connection indicator or |
features are dependent on the internet | status while processing. Also showing an error |
if not properly connect they will pro- | message and delete the data once the internet |
vide wrong outcome and recommenda- | is down so user an start again on recovery |
tion | |
- Apps not supporting different types | - Stating the supported external medical de- |
of external medical devices/trackers | vices/trackers in the app description |
- Apps not connecting with specific | - Testing top used external medical devices/- |
types of external medical devices/- | trackers properly before releasing app updates |
trackers after users update their apps | |
- Performing maintenance or updates | - Informing users about any scheduled main- |
for mHealth apps that may affect | tenance or updates that may affect their con- |
users’ connectivity without informing | nectivity within the app, that way they can |
them earlier | reschudule work and appointments with clients |
Key issues found | Recommendations |
---|---|
- Some mHealth functionalities suffer | - As mHealth app users are diverse in terms of |
from some translation issues | language, more thorough internationalisation |
including medical terms and health expecta- | |
tions of divere users before releasing updates | |
- Users request updates to add lan- | - Developers should ensure that the devel- |
guage support or medical/health ex- | oped app supports the widely used lan- |
pressions from their own language to | guages, including using the most common |
make the app more accessible | medical/health expressions in different lan- |
guages | |
- Some apps target a specific age or | - Developers should ensure that the app tar- |
gender, which benenefits a particular | gets users of wide range of ages and genders, |
type of user and is a concern for others | unless the app is targeting a specific health is- |
sue relevant to a particular group |
Key issues found | Recommendations |
---|---|
- Complex or buggy signup health | - Implementing simple sign up health forms |
forms where users need to complete | and ensuring that the form is bug free. Along |
and submit too many health details or | with some integration to get the latest and |
information or face errors while enter- | most accurate users health details which comes |
ing their health data within the regis- | from other areas such as hospitals and GP clin- |
tration form | ics |
- Verification codes or OTP are not | - Implementing different ways for users to ver- |
properly delivered | ify their accounts besides OTP |
- Incorrect verification codes where | - Ensuring sending unexpired verification |
users get errors when submitting the | codes to users to complete the signup process |
verification code they have received | |
- Users not being able to retrieve their | - Allowing users to retrieve their user name in |
users’ names | case they forgot it |
- Users cannot reset their passwords | - Allowing users to sign in to the app using a |
since forgot passwords functionality is | passcode or face id |
not working properly | |
- The app keeps signing out, requiring | - Allowing users to keep being signed in as long |
users to log in each time | as they did not sign out |
- Users are trying to log in while the | - Allowing users to access the app status in |
app is temporarily down without hav- | case the app is down |
ing any information about the app er- | |
ror, so they end up resetting their ac- | |
count information |
Key issues found | Recommendations |
---|---|
- Non-useful and non-personalised | - Testing with variety of end user groups to |
health notifications | ensure useful, timely, personalised and relevant |
notifications to users | |
- Large number of notifications pushed | - Allow users to control notifications; design so |
that less pushed notifications to users | |
- The inability to choose health notifi- | - Allowing users to manually select the type |
cation content by users | of health-related notifications they wish to re- |
ceive | |
- Notifications containing poor/inap- | - Testing processes focusing on detecting |
propriate content | poor/inappropriate content and use of too |
generic notifications |
Key issues found | Recommendations |
---|---|
- Apps gaining access to non-essential | - Only request access to essential health data |
health data or features such as users’ | or features that massively affect and enhance |
contacts, cameras, photo galleries, mi- | the app’s usage and allowing users to grant |
crophones, location, local network de- | or reject permission and to have the option to |
vices, Bluetooth, and interaction with | change their minds later on |
other apps | |
- Apps asking for users’ private infor- | - Do not ask users to provide personal infor- |
mation, such as their date of birth | mation unless it affects the app’s functionality |
- Apps forcing users to accept their | - Simplifying privacy policies and data user |
lengthy and complicated privacy poli- | agreements for users |
cies before they can use them | |
- Apps frequently accessing users’ lo- | - Accessing user’s location only if needed |
cations in the background |
Key issues found | Recommendations |
---|---|
- Inaccessible mHealth apps | - Including diverse user personas, focus groups |
and testing with diverse end users to ensure | |
better accessibility within apps | |
- Poorly described mHealth apps | - Testing app descriptions with diverse end |
users as well as app itself | |
- mHealth Apps having major stability | - as mHealth apps may be critical to quality |
issues or bugs | of life / health, rigorous testing processes be- |
fore release is arguably more important than | |
in many other app domains |
Key issues found | Recommendations |
---|---|
- Inappropriate ad content unrelated to | - Ensuring that all content of the ads shown in |
Health issues | their app is appropriate for the target users of |
the app; Allowing op-out of some ad domains | |
- Ads that do not match mHealth app | - Ensuring that the content of the ads appear- |
goals/purpose | ing in their mHealth app matches the goal of |
the app | |
- Frequent and lengthy Health im- | - Decreasing ad frequency and length as much |
provement medication ads | as possible |
Ads affecting functionality of the | - Showing ads in the right position and min- |
mHealth app | imising ad size |
- Health and medical ads that are non- | - Ensuring that ads do not affect functionality |
skippable | of the app |
- Health and medical ads position and | - Allowing users to skip ads |
style | |
- Health and medical ads covering large | - Minimising size of ads |
space of the screen | |
- Health and medical ads volume and | - Allowing user control of ad volume |
distraction |
Key issues found | Recommendations |
---|---|
- mHealth apps do processing and | - Allow the mHealth app to work in the back- |
analysis in the background cause slowing down of phones and increasing battery drainage | ground only if needed |
- mHealth apps that regularly perform | - Ensuring that the mHealth app only performs |
functionalities and high computations | tasks that may cause battery drainage only if |
that lead to fast battery drainage, such | required |
as accessing user location, pushing lots | |
of notifications, etc | |
- mHealth apps that need large free | - Release apps’ updates with a small size so |
space to be downloaded or updated | that all users owing phones with different free |
space can download them | |
- mHealth apps consuming massive | - Ensure that the app does not consume high |
memory while being used | computational resources before releasing the |
mHealth app to users |