While all vendors and providers put an increased focus on patient data privacy, they can sometimes overlook other significant goals to achieve successful user acquisition and retention. As mobile users are quite demanding when it comes to robustness, usability, and access, even the safest app may fail if it doesn’t live up to patient needs.
In particular, TechRepublic featured a report stating that a whopping 60% of users uninstalled an app or abandoned a website after a single failed attempt to access it because of performance problems. Even more, a total of 80% of respondents expressed their intent to delete the underperforming apps in future uses. Additionally, the users can just leave the apps on their devices without deleting them. Statista reports that 21% of mobile apps were used only once in six months since their installation.
Healthcare has a long history of users forced to suffer from cloggy and low-performance systems. Such solutions were intended at health specialists, who weren’t decision-makers in most cases and were unable to initiate the changes in the system functionality or influence a transition to another solution.
The mobile realm is way more flexible though, and patients as one of the key end users of mHealth apps can decide what works for them and instantaneously get rid of apps that lag, crash, or freeze.
Potential pitfalls in mHealth apps performance
To bring in tangible results, mHealth apps need to process extensive inbound and outbound data continuously, for instance:
- Objective and subjective patient-generated health data (PGHD): temperature, blood pressure, blood glucose, mood, sleep, menstrual cycle, pain
- Pattern analysis based on PGHD: physical activity, nutrition, water consumption, menstrual cycle, etc.
- Symptom-based analysis: headache, rash, pain, heartburn, fever, etc.
- Video content: workouts, physical rehabilitation, recipes, etc.
- Treatment plan updates
- Therapeutic education for particular conditions: guidelines, explanations, FAQ, etc.
In case mHealth applications are launched without considering performance and load testing, both vendors and providers risk failing users’ expectations of the app accessibility and robustness.
While some vendors can postpone the performance testing phase and thus accelerate the app’s time-to-market, the consequences can affect user adoption and retention as well as increase churn rate. Down the road, missing performance optimisation certainly creates the risk to undermine the significant effort put into renovating chronic care management, behavioural health assistance, preliminary diagnostics and general wellness improvement with mobile technologies.
Are chatbots replacing doctors? Its not what people want
Good news: performance testing and optimisation are achievable at any stage of software development, even after the release. In fact, it should be repeated continuously after the app launch to ensure that the updates and growing adoption rate won’t affect the application’s accessibility.
Navigating mHealth app performance testing and optimisation
While mHealth app performance and load testing should be similar to mobile performance testing across industries, there are some critical bottlenecks that should be addressed firsthand in order to build user trust.
Unifying user experience across devices
An mHealth app can be native or hybrid and designed to work on a single or multiple platforms. In any case, the application will be used across different versions of operating systems, because a patient’s device may not have the newer OS. If the performance testing is conducted only to cover the most recent OS version of a particular platform, the app can fail in other cases, burning the battery, clogging the memory, or freezing the device itself due to zero compatibility.
Apart from conflicting with the OS and causing device setbacks, an app can become underused by patients. If they notice that the application, for example, drains the battery, they will avoid using the app on the go, eventually forgetting about it altogether. So, regardless of the app platform preferences, it’s recommended to broaden the scope of the targeted OS versions to ensure smooth user experience in different configurations and encourage the users to access the app whenever they need it.
Prioritising crash monitoring
Crash monitoring is an essential part of ensuring users’ uninterrupted interaction with the app and keeping them satisfied with their experience. But beyond mere satisfaction, maintaining your mHealth app crash-free becomes critical if the solution offers any tools for initiating medical assistance in emergencies. Such tools may include automatic notifications and alerts if a patient logs any events (e.g. falling), severe symptoms, or abnormal vitals. If the app crashes at an attempt to record any PGHD, this can lead to extremely negative consequences.
Being a CTO for a healthcare technology company
Providers and vendors can monitor and report fatal and non-fatal errors within their apps over different time periods, tracking particular user actions and system responses leading to crashes. It’s highly recommended to carry out this continuous process at the early stages of performance testing, to eliminate most errors prior to beta testing.
Maintaining cross-network usability
Many mHealth apps are designed to help their users build a particular habit, such as tracking their vitals or physical activity. Therefore, users should have access to their apps whenever they need it and regardless of the current network’s speed.
Providers and vendors need to test their app performance on different connections and during transitions from Wi-Fi to mobile data and back. Moreover, they should enable network type autodetection with a set of rules so that their app can respond to network changes accordingly.
For example, video content could be made inaccessible for slower connection by default to avoid hindering user experience. In this case, app users should be cautioned that this feature is inaccessible. It is also desirable to add the refresh button and a pop-up suggesting going back to the faster option.
Performance above all
Whereas some mobile users are patient with apps that take a long time to load, tend to freeze or unexpectedly crash, such loyalty is more of an exception. Maybe it’s a user’s favourite game or unique tool they need for work, in which case the user tolerates any inconveniences unless they are frequent or severe. However, if the app is more on the service side and a user is new, they can be way less understanding.
AI and machine learning needed to improve the healthcare industry
For example, if an mHealth app offers general wellness services, such as running or walking guidance, workouts, nutrition tips, and more, the user can easily switch to another solution if the first installed app failed to meet their accessibility and performance expectations.
In case the app is dedicated to helping patients cope with behavioural health issues or manage a chronic condition, any performance problems can be potentially more harmful for both the patient and the healthcare organisation. If a patient can’t effectively use a particular app, they may lose trust in the full category of similar mHealth solutions and resort to more traditional or convenient tools. In the worst case, patients can even start questioning the provider’s expertise.
While no one expects impeccable app performance at all times, providers and vendors just shouldn’t disregard testing it on a continuous basis, focusing on device compatibility, cross-network usability, and crash monitoring.
Written by Maxim Chernyak, head of test automation and performance testing lab at A1QA
