This is an open-access article distributed under the terms of the Creative Commons Attribution License (https://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work, first published in JMIR Formative Research, is properly cited. The complete bibliographic information, a link to the original publication on https://formative.jmir.org, as well as this copyright and license information must be included.
A challenge facing researchers conducting mobile health (mHealth) research is the amount of resources required to develop mobile apps. This can be a barrier to generating relevant knowledge in a timely manner. The recent rise of “no-code” software development platforms may overcome this challenge and enable researchers to decrease the cost and time required to develop mHealth research apps.
We aimed to describe the development process and the lessons learned to build Pathverse, a no-code mHealth app design platform.
The study took place between November 2019 and December 2021. We used a participatory research framework to develop the mHealth app design platform. In phase 1, we worked with researchers to gather key platform feature requirements and conducted an exploratory literature search to determine needs related to this platform. In phase 2, we used an agile software framework (Scrum) to develop the platform. Each development sprint cycle was 4 weeks in length. We created a minimum viable product at the end of 7 sprint cycles. In phase 3, we used a convenience sample of adults (n=5) to gather user feedback through usability and acceptability testing. In phase 4, we further developed the platform based on user feedback, following the V-model software development process.
Our team consulted end users (ie, researchers) and utilized behavior change technique taxonomy and behavior change models (ie, the multi-process action control framework) to guide the development of features. The first version of the Pathverse platform included features that allowed researchers to (1) design customized multimedia app content (eg, interactive lessons), (2) set content delivery logic (eg, only show new lessons when completing the previous lesson), (3) implement customized participant surveys, (4) provide self-monitoring tools, (5) set personalized goals, and (6) customize app notifications. Usability and acceptability testing revealed that researchers found the platform easy to navigate and that the features were intuitive to use. Potential improvements include the ability to deliver adaptive interventions and add features such as community group chat.
To our knowledge, Pathverse is the first no-code mHealth app design platform for developing mHealth interventions for behavior. We successfully used behavior change models and the behavior change technique taxonomy to inform the feature requirements of Pathverse. Overall, the use of a participatory framework, combined with the agile and hybrid-agile software development process, enabled our team to successfully develop the Pathverse platform.
Advancements in internet-enabled digital devices (eg, smartphones and wearables) and improved access to these devices have led to the rapid growth of mobile health (mHealth) research [
One of the challenges facing researchers conducting mHealth intervention research is the cost and time required to develop and maintain mobile apps [
An innovative solution to overcome these mHealth app development challenges facing researchers has recently arisen: “no-code” development platforms [
We used a participatory research framework to develop a no-code mHealth app design platform called Pathverse [
Development phases of the web-based program.
Phases | Activities | Dates |
(1) Determine feature requirements | Determine features required for the “no-code” mHealth design platform, Pathverse | Nov 2019-Mar 2020 |
(2) Develop the platform | Use the Scrum development framework to design the Pathverse platform | May 2020-Dec 2020 |
(3) Gather user feedback | Usability and acceptability testing | Feb 2021-May 2021 |
(4) Implement user feedback | Revise the Pathverse platform based on usability and acceptability testing | Sep 2021-Dec 2021 |
mHealth researchers (n=13) with various levels of research experience (eg, students, early career researchers, and senior researchers) and software developers (n=4) were involved in identifying key software features for the no-code app design platform, Pathverse. The team members’ demographics are presented in
We used the Scrum framework to develop the Pathverse platform [
We used a 4-week sprint cycle in this project. We aimed to produce a working version of the platform in about 7 months (ie, 7 sprint cycles). The key members in the Scrum team were an mHealth researcher (the product owner, SL), the Scrum master (HL), and the software development team. End users with various levels of mHealth research experience (researchers, research assistants, and students) were involved during each sprint. The Scrum team presented the completed platform features and discussed goals for the next sprint with the team at the end of each sprint.
Similarly to our previous studies [
Based on user feedback, our team planned for an additional phase of development. During this phase, we used the V-model software development process. This method combines traditional sequential development methodology (eg, the waterfall method) with feedback mechanisms in the agile development process (eg, Scrum) to ensure that the new features added work appropriately [
Informed consent was obtained from participants completing the usability and acceptability testing. This study was approved (17361) by the Human Research Ethics Board at the University of Victoria.
Our multidisciplinary team of researchers and software developers met regularly to determine requirements and features for the Pathverse platform. A summary of the activities conducted at each meeting is shown in
Our team generated a list of potential Pathverse features by building a mock-up app using the M-PAC framework as a template theoretical framework and physical activity as the behavior change outcome. Similarly to our previous study, our team then matched the BCTs required to implement the physical activity app using the M-PAC framework [
The final platform features included the ability to (1) design customized and interactive multimedia content in the app; (2) set flexible content delivery logic (eg, delay the time release or only show new lessons when completing the previous lesson); (3) deploy customized surveys to the participants; (4) provide personalized self-monitoring trackers (ie, daily steps); (5) enable participants to set goals; (6) implement customized app notifications to remind participants of any new mHealth intervention content; (7) provide gamified points and badges; and (8) enable participants to share progress made on their social media accounts (eg, Instagram and Facebook).
A summary of the activities conducted during the meetings.
Date | Activities |
November 8, 2019 |
Discussed common features used in current popular mHealth lifestyle promotion apps |
December 12, 2019 |
Brainstormed potential mHealth content and features required for the platform based on an example physical activity promotion app that used the multi-process action control framework Received feedback from researchers on app mock-ups and discussed the user journey for researchers to create apps Provided feedback on potential app logic needed to deliver multimedia content in an app |
January 10, 2020 |
Compiled a wish list of features for an mHealth app builder platform, which included multimedia content delivery, messaging, online community, self-monitoring tools, wearable integration, adaptive intervention delivery logic, gamification features (eg, awards, points, and competitions), diaries, virtual lockers to store memories of accomplishments, surveys, reminders and notifications, goal setting, team challenges, quizzes, the ability to customize the app UIa (eg, color, fonts, and layout), a means of tracking app usage, and a mechanism for online consent |
January 30, 2020 |
Created several UI designs of a “no-code” app design platform Received design feedback from end users |
February 14, 2020 |
Further refined UI designs and discussed the user journey and potential ways researchers could interact with the no-code app design platform to create mHealth apps Discussed potential privacy and security measures that the platform needed to consider Brainstormed and finalized the name of the no-code app design platform: Pathverse |
March 12, 2020 |
Finalized a list of features that our team would attempt to include for the first version of the no-code app design platform Estimated software development timeline and the number of software developers required |
aUser interface.
Behavior change techniques that can be implemented using the identified Pathverse features.
Pathverse features | Potential behavior change techniques that could be implemented using the proposed Pathverse features. The numbers in parentheses refer to behavior change techniques in the Coventry, Aberdeen & London—Refined taxonomy [ |
(1) Ability to design customized multimedia content (eg, text, pictures, video, and interactive quizzes) on various app pages; the content can be organized into “lessons” depending on the intervention curriculum (for example, lesson 1 might discuss the benefits of physical activity and lesson 2 might provide information on setting graded goals) |
Provide information on consequences of behaviour in general (1) Provide information on the consequences of behaviour to the individual (2) Provide information about others’ approval (3) Provide normative information about others’ behaviour (4) Barrier identification/problem solving (8) Set graded tasks (9) Prompt review of behavioural goals (10) Prompt review of outcome goals (11) Prompt rewards contingent on effort or progress towards behaviour (12) Shaping (14) Prompting focus on past success (18) Prompting generalization of a target behaviour (15) Prompt self-monitoring of behavioural outcome (16) Provide information on where and when to perform the behaviour (20) Provide instruction on how to perform the behaviour (21) Model/demonstrate the behaviour (22) Teach to use prompts/cues (23) Environmental restructuring (24) Fear arousal (32) Prompt self talk (33) Prompt use of imagery (34) Relapse prevention/coping planning (35) Stress management/emotional control training (36) Motivational interviewing (37) Time management (38) General communication skills training (39) Prompt identification as role model/position advocate (30) Facilitate social comparison (28) |
(2) Set program delivery logic for the content created (for example, a new program lesson can be delivered every week) |
Provide feedback on performance (19) Use of follow-up prompts (27) |
(3) Deploy customized surveys to the participants; the surveys can include multiple choice answers, Likert scales, and drop-down or open-ended questions |
Barrier identification/problem solving (8) Prompt self-monitoring of behavioural outcome (16) Facilitate social comparison (28) |
(4) Track physical activity–related outcomes from participants’ fitness trackers; data will be automatically synchronized from trackers connected to Apple or Google Health |
Prompt self-monitoring of behaviour (16) |
(5) Enable participants to set personal goals; participants can also receive reminders about the goal due date |
Goal setting (behaviour) (5) Goal setting (outcome) (6) Action planning (7) Set graded tasks (9) Prompt review of behavioural goals (10) Prompt review of outcome goals (11) |
(6) Implement customized app notifications to remind participants of any new mHealth intervention content |
Prompt review of behavioural goals (10) Prompt review of outcome goals (11) Prompt practice (26) |
(7) Provide gamified points and badgesa |
Prompt rewards contingent on effort or progress toward behaviour (12) Provide rewards contingent on successful behaviour (13) Shaping (14) Stimulate anticipation of future rewards (40) |
(8) Enable participants to share progress made on their social media accounts (eg, Instagram and Facebook)a |
Provide information about others’ approval (3) Facilitate social comparison (28) Plan social support/social change (29) Prompt identification as role model/position advocate (30) |
aThese features were not developed in the Pathverse app (version 1.5).
The Scrum team met with researchers throughout the sprint cycles to gather user feedback and plan the tasks to be completed by the end of the next phase. A summary of the activities completed in each Scrum phase is described below. The commit history of the software development process can be found in
The first sprint started with determining the Pathverse platform architecture required to implement the key features identified in phase 1. The platform consisted of 3 main components: the Pathverse researcher web portal, the Pathverse participant app (available in both the iOS and Android app stores), and the backend application program interface (API) server and databases (
Pathverse platform architecture.
The programming team simultaneously coded the components of the Pathverse platform. At the end of this sprint, the programing team developed a prototype version of the dashboard of the Pathverse researcher web portal using React.js, a JavaScript library licensed from the Massachusetts Institute of Technology [
The main priorities for this sprint were to finish developing the feature that enabled researchers to upload customized multimedia content for an mHealth intervention and set the delivery logic for the intervention. This was the first time the integrated platform was tested collectively. After sharing a working prototype at the end of this phase, researchers tested the prototype and provided feedback on system bugs and design issues, and they also suggested other features that would improve their experience. The top-priority suggestions included the need to optimize multimedia content (eg, font size and color) for various screen sizes, organize the order of the intervention content delivery using drag and drop, and provide real-time visualization of the multimedia content added to the Pathverse participant app in the research portal.
The programming team attempted to implement the suggestions made by the end users from the previous sprint. Additionally, the programing team completed the customized survey feature. This feature enabled the researchers to collect various types of survey responses (eg, multiple choice, ratings or Likert scales, drop-down questions, and open-ended questions). These features were tested, and various system bugs, UI design issues, and additional features were discussed. Specific main feature modification requests included providing options to enable participants to complete the survey multiple times and randomize the order of the questions. Due to the large quantity of feedback received (for UI and feature requests) and the slower than expected feedback implementation, our team decided not to develop 2 features: gamified points and social sharing. This was to ensure that a working prototype of the Pathverse platform could be delivered on time.
The programming team developed and implemented the self-monitoring tool for step tracking in the participant app. This allowed the Pathverse app to connect to Apple or Google Health wearable devices and display a user’s daily step data. The end users worked with the development team to provide feedback on how the wearable data were displayed in the app. The end users provided the feedback that participants should also be able to display other health metrics, including blood pressure, weight, and daily active minutes.
The programming team completed the development of goal setting and customized app notification features during this sprint. The goal-setting features enabled the participants to set customized personal goals and customized reminders for goal due dates. The customized app notification enabled researchers to set personalized app reminders whenever new app content became available to the participants. At the end of this phase, the programing team presented the first beta version of the platform to the end users. Due to time constraints, the programming team could not implement the feature that allowed the participant app to display all the health metrics requested, such as blood pressure and weight. A prototype of the daily active minutes feature was added. Our team decided that the next sprint would focus on conducting quality assurance (QA) testing.
The primary goal of this sprint was to conduct QA testing prior to launching the Pathverse platform and submitting the app to the Apple App Store and Google Play Store. The end users and programming team generated a list of system bugs while testing the various features that were developed (eg, multimedia tools, survey tools, and self-monitoring tools). The programming team and the end users met weekly during this sprint to discuss solutions to resolve known system bugs. The app (version 1.0) was officially submitted to the iOS and Android app stores at the end of this sprint.
Pathverse researcher portal for creating mHealth app content.
Screenshot of the Pathverse participant app.
We invited 5 participants to provide feedback on the Pathverse platform. The demographic characteristics of the researchers are shown in
The most helpful features identified by the users included easy navigation for both the research portal and participant app and the ability to download app usage and survey data. Potential improvements included the ability to deliver multiple surveys throughout the day, add the ability to deliver adaptive interventions, and add features such as community group chat. A summary of the feedback received is shown in
Summary of feedback received in phase 3.
Questions | Summary of feedback (illustrative quotes) |
What did you like about the app? |
|
What did you dislike about the app? |
|
What changes do you think can help improve the app? |
|
What did you like about the research web portal? |
|
What did you dislike about the research web portal? |
|
What changes do you think can help improve the research web portal? |
|
We applied the V-method of software development. The requirement analysis phase occurred in September 2021. Based on the user feedback from the previous phase, our team determined three main requirements that we would implement given the availability of resources: (1) expand survey functionalities so that multiple surveys could be delivered throughout the day, (2) improve the data download format (eg, allow a longer data structure format) for easier analysis and postprocessing, and (3) provide the ability to customize whether to use the self-monitoring features, as not all mHealth studies require this feature. The system and architecture design and the module design phase took place during the last week of September 2021. The programming team determined the main modules to be developed to meet the program requirements. These modules included customized survey release times in the researcher web portal, a display of the various surveys in the participant Pathverse app, the ability to download survey data in .csv format, the ability for researchers to choose whether to collect wearable and survey data in the researcher web portal, and revision of the UI design for the participant app to not display self-monitoring tools. Based on these module designs, the software team initiated the coding phases from October to November 2021. The validation testing to resolve system bugs took place in December 2021. Pathverse (version 1.5) was released to the app stores at the end of this phase. Video demonstrations of the functionality of the platform were made available online [
This study describes the development process of a no-code mHealth app design platform for researchers. To our knowledge, this platform (Pathverse) is the first no-code mHealth app design platform for developing mHealth behavior interventions. This platform has the potential to enable researchers with no previous software programming skills to design mHealth intervention apps. Consequently, this should help reduce the time and cost required to develop mHealth interventions. Our team used a behavior theory framework (M-PAC) and the BCT taxonomy to inform the design of the various software features in the first version of the Pathverse platform. These features can offer researchers the flexibility to design mHealth interventions with various BCTs, depending on the behavior theory or the mechanisms of action. The participatory development methods used in this project allowed our team to ensure that feedback from end users (researchers) was incorporated throughout the development phases. Despite receiving helpful feedback (eg, the social wall, gamification, and app color and font customization) from the researchers, our team could only address the most important issues given resource availability. However, we plan to address all the feedback received in future development.
Similarly to previous mHealth software development studies [
The software development methods (eg, Scrum and the V-model) used in this study were effective in delivering the product on time. However, our team found that the Scrum method easily led to scope creep, resulting in a buildup of backlog tasks and feature cancellation. For example, after completing the customized survey feature, the research team requested additional survey functionality (eg, randomization of survey choices) in sprint 4. Similarly, they requested additional self-monitoring trackers (eg, for weight and blood sugar) in sprint 6. We also spent a significant amount of time optimizing and making changes to the app UI throughout the Scrum cycles. Future development should set a limit on the number of UI changes that can be made after the initial designs have been approved. Scope creep is a known challenge in agile development environments [
Finally, we learned the need to implement QA protocols throughout the software development phases. We did not designate a specific QA analyst role during the rapid sprint cycles. Thus, some QA issues were not discovered until the product was launched. Adopting QA testing early in the development cycle could help avoid users experiencing software bugs following deployment. An advantage of using the V-model was the systematic approach to QA testing throughout the development stages. Thus, future Scrum software development might consider incorporating a dedicated QA analyst as part of the team.
The end users identified several useful features (eg, the online community, adaptive intervention features, and gamification features) that could be implemented in the future to further expand the capabilities of the no-code mHealth app builder tool for researchers. A strength of the study was using the participatory framework throughout the development of the Pathverse platform. This process enabled our team to gather valuable insights into ways to improve the platform. A limitation of the study is that the end users who were involved in designing and testing the platform were mHealth researchers; this may limit the generalizability of our findings beyond this population. Furthermore, the end users provided feedback about platform feature development throughout the development phases. Due to our limited sample size during usability testing, it remains unclear how these features would be used in a larger group of users. Future studies are warranted.
In summary, this study describes the development process of Pathverse, a no-code mHealth app design platform. The process reinforced the importance of involving end users (eg, researchers) and demonstrated the use of agile and hybrid-agile software development methods to develop mHealth research tools. Our participatory research approach enabled our team to clarify the feature requirements of the Pathverse platform. Overall, we believe that our no-code mHealth app design platform will help researchers decrease the resources required to leverage mHealth technology.
Supplementary Tables S1 S2 S3.
Platform Commit History.
application program interface
behavior change technique
multi-process action control
mobile health
quality assurance
user interface
SL is supported by the Michael Smith Foundation of Health Research. We also would like to acknowledge Utkarsh Patadia, Rafay Chaudhry, Kahvi Patel, and Parambeer Johal for helping design the platform.
After the development of the Pathverse platform, SL and HL cofounded Pathverse Inc to commercialize the platform described in this paper.