Stakeholder engagement, proper planning and modular design for mHealth apps: lessons from QuestExplore and working toward standards for mHealth app design

Introduction

With the exponential growth of technology over the past century, individuals engaging with some form of technology in their daily lives is fairly ubiquitous. A subset of the broader technology advancements involves the growth of mobile health (mHealth) applications (apps) that typically engage individuals in learning about, tracking and/or managing some aspect of their health and wellness. The rate of mHealth app creation and engagement has outpaced regulatory management, creating dead-end or one-hit wonder apps that are specific for a certain population and time, lacking malleability and iterative plans for future versions of those apps (1). Additionally, without much regulatory guidance, questions and concerns regarding the privacy and security of data recorded in mHealth apps are often raised (1). The rapid pace of mHealth app development and release has been known for over a decade with almost 6,000 health and wellness apps in 2010 and nearly tripling to 17,000 health and wellness apps in 2013 (2). More recent estimates cite 350,000 mHealth apps that are currently available to consumers (3).

Subramaniam and colleagues took advantage of a long-needed opportunity by completing and subsequently outlining a rigorous qualitative approach of their app’s development in the recent mHealth article “Careful considerations for mHealth app development: lessons learned from QuestExplore (1).” Additionally, they review how the app they developed could be modified for future use and further adapted or scaled in different populations (1). Their iterative development process highlights the importance of engagement with an interdisciplinary team of stakeholders, heavy planning and beta testing phases, and modular app design (1). Using this approach as guidance for the creation of future mHealth apps will make mHealth apps more standardized in their development, improve data safety and security, and allow for broader use (1).

Importance of stakeholder engagement

With the rapid pace of technology growth and pressure to create and publish research, it is tempting to design and release what is considered the next best mHealth app as fast as possible. This quick design-and-release risks the development of an mHealth app with low acceptability and usability. As Subramaniam and colleagues note, both the breadth and frequency of stakeholder engagement throughout app design and development as well as involvement in initial beta testing results in an app that is more likely to be accepted and usable (1). Similar to Subramaniam and colleagues, our research group has experienced the benefits of engaging a variety of stakeholders, including patients, caregivers, and healthcare providers over time in the design and development of an mHealth app, Roadmap, used in the setting of hematopoietic cell transplantation (1,4,5).

In addition to maximizing stakeholder engagement, standardizing guidelines that optimize stakeholder engagement and feedback on mHealth app development should be considered. First, storyboarding was used a technique for the development of QuestExplore (1). Storyboarding has historically been used in the film as well as the advertising industry (6). When used in the setting of app design, storyboarding provides a graphical and narrative series with sketches or other visuals to illustrate interactions different users may have with the app (6). As described by the authors, storyboarding served well across different professions and learning styles to facilitate engagement of all stakeholders (1). Additionally, Subramaniam and colleagues utilized qualitative interviews as a method to further enrich feedback for app design and development considerations (1). Extensive feedback and reflection with this thoughtful approach resulted in “gamification” features for the app, emojis and animations added to further optimize user readability and understanding, as well as a thoughtful color scheme that avoided bright colors (1). Additionally, Subramaniam and colleagues incorporated positivity and encouragement through their “Symptom Journal” with positive and encouraging words as well as tailoring the amount of questions to how the patient is feeling (1). Our app, Roadmap, also incorporates “gamification” and avoids bright colors (Figure 1) (4). Further, encouraging positivity for caregivers is central to our current Roadmap mobile randomized-controlled trial (4). QuestExplore was also evaluated by stakeholders using the Mobile App Rating Scale (MARS) Questionnaire, a validated, quantitative rating that has been used for evaluation of thousands of mHealth apps to date (1,7,8). Similarly, our group has begun to integrate the MARS Questionnaire to gather quantitative user feedback on the mHealth platform, Roadmap (unpublished data).

Figure 1.

Screenshots from Roadmap caregiver user interface (4). ©Rozwadowski M, Dittakavi M, Mazzoli A, et al. Originally published in JMIR Research Protocols (https://www.researchprotocols.org/2020/9/e19288/), 18.09.2020. This is an open-access article distributed under the terms of the Creative Commons Attribution License (https://creativecommons.org/licenses/by/4.0/).

While stakeholder engagement takes both time, financial support and other resources, allowing all parties who engage with the app to provide feedback will increase the reach and longevity of an mHealth app. Moving forward, as mHealth apps continue to become integrated with provider dashboards and electronic health records, examining patient and provider engagement will remain essential. In addition to upfront engagement, iterative feedback at routine intervals will further improve mHealth apps.

Payoffs to planning

Fast creation and release of apps has largely been the norm to date, as alluded to above. Subramaniam and colleagues appropriately argue that time spent upfront will prevent additional time that could be needed later for a poorly planned and designed app (1). Initial app design planning (pre-Stage 1), followed by stakeholder engagement (Stage 1) and then followed by additional design modifications (Stage 2) as Subramaniam and colleagues present will decrease the likelihood of “bugs” in beta testing as well as increase acceptability and useability of the prototype app (1). Further, planning for possible “bugs” and adequate prototype testing and feedback (Stage 3) can prevent frustration and time following public app release (1). While app design, development, and release are exciting processes, proper planning will lead to maximal acceptability and usability and likely decrease time spent “debugging” after public app release. Subramaniam and colleagues outline what app development teams need to strongly consider using as standard practice for stakeholder engagement in app development going forward (1).

Modular mHealth

In addition to calling for and encouraging maximal stakeholder engagement and proper planning in app development, Subramaniam and colleagues’ work highlights the novel concept of modular app design. As discussed in their manuscript, mHealth apps to date have largely been designed for a specific population of individuals, often for individuals with a specific condition or disease (1). Even with significant stakeholder engagement and substantial planning, one will have an mHealth app that is highly acceptable and usable for a specific population, at best. As diagnosis and management of that specific disease or condition change over time, the mHealth app will no longer be relevant for that specific population (1).

While coding for a modular app will require advanced planning and time upfront, Subramaniam and colleagues suggest an important concept in that the modular design of an mHealth app will allow for rapid reorganization and coding to promote acceptability and usability in a variety of different populations after the initial modular mHealth app’s backbone has been created (1). Although the initial goals of technology expansion were not necessarily to improve the health and wellness of populations, mHealth apps by and large have this goal. In the design and development of QuestExplore, Subramaniam and colleagues were able to show the magnitude of adaptability and applicability of an mHealth app as QuestExplore has been used by multiple health systems and was easily modified for different populations (1).

Discussion

The swift expansion of mHealth apps to date has arguably not served to maximize the health and wellness of individuals to the greatest extent possible. With thousands of mHealth apps being developed each year, the field has not been as user-driven as it should be. Additionally, safety and security of data have not routinely been monitored or addressed, which may lead to unintended roadblocks as apps become more integrated with provider dashboards and the electronic health record. In the creation of QuestExplore, Subramaniam and colleagues took a very thoughtful approach, both reflecting on the problems with mHealth app creation to date and challenging the field to take more time, be more critical and standardize the way we develop, design and release mHealth apps (1). While stakeholder engagement, extensive planning and modular design will significantly increase the time from initial app brainstorming to public app release, the end product may be more acceptable, usable, and flexible to maximally support the health and wellness of the individuals the app was designed to serve (1).

Lastly, as a point of future direction for mHealth apps incorporating wearables like QuestExplore and Roadmap, we must be mindful of which phone platforms can utilize the app and wearable as well as which wearables we use. While not discussed extensively in their article, Subramaniam and colleagues mention the use of an Apple watch to record and track physiologic data as part of QuestExplore (1). Our group has incorporated use of Fitbits to our mobile randomized controlled trial and the Roadmap app is compatible with Android and Apple phones (4). Going forward, as we progress in making apps more modular and maximize usability and acceptability, we cannot forget the need to consider usability and acceptability of the devices mHealth apps function on and the usability and acceptability of different wearables. Device platforms and wearables may change based on the study or the population, but we all need to be cautious of not excluding certain populations and consider providing all devices as part of a study. With the progress to date in the area of mHealth and the thoughtful work of Subramaniam and colleagues, we are hopeful these concerns will be addressed and the field of mHealth will continue to grow and support the health and wellness of many individuals in the future.

Supplementary

The article’s supplementary files as

Ethical Statement: The authors are accountable for all aspects of the work in ensuring that questions related to the accuracy or integrity of any part of the work are appropriately investigated and resolved.