Considerations for mHealth development: lessons learned from two diabetes education apps

Introduction

Patient-oriented digital health technologies, such as mobile health apps (mHealth), have surfaced as a promising strategy to assist individuals in improving health outcomes (1,2). mHealth development is a complex endeavor and the existing frameworks for development constitute overarching conceptual guides that, although necessary, lack practical and actionable detail. For instance, Katsaliaki and colleagues delineate ten domains relevant to mHealth evaluations, including the health problem and current use of technology, technical description and characteristics, safety, ethical analysis, organizational aspects, patient and societal considerations, and legal implications (3). Similarly, Adnan and colleagues (4), Loo and colleagues (5), or Mertens and Van Gelder (6), without diminishing the value of their contributions, adopt comparably high-level perspectives, including an extension of the Technology Acceptance Model (4). These frameworks serve as guiding principles for broad-scope app intervention design, rather than offering detailed development considerations or standard best practices for development.

Other research outlines aspects such as user centered and equitable mHealth (7,8), application of Design Thinking approach (9), contextual adaptations of digital health interventions (10), user experience principles (11), usability testing recommendations (12), app attributes to guide clinicians’ recommendations (13), stakeholders’ involvement (14), dissemination strategies (15), program cost evaluation (16), or implementation and integration recommendations (17). Such frameworks and studies help establish a foundation for research teams to plan mHealth interventions. However, they do not consider the details and logistics of designing, prototyping, and developing mHealth apps as part of the process, both when the app development is outsourced to a third party (i.e., an external vendor) or done in-house. As a result, this work remains largely invisible.

Ku and Sim commend the sharing of resources aimed at aiding fellow researchers in streamlining app development processes (18). Building on this spirit of collaboration, Perrin-Franck and colleagues introduced the Guidelines and Checklist for the Reporting on Digital Health Implementations (iCHECK-DH) in 2023, which Liyanage and colleagues later expanded into an interactive toolkit (19,20). The checklist represents an important step toward enhancing transparency in reporting mHealth development, as it encourages detailed descriptions of elements such as blueprint summaries and technical design. Thanks to such initiatives, an increasing number of studies make their development processes visible. Summative accounts of best practices and lessons learned in mHealth app development process have also emerged, though it remains limited to a few notable examples, including Subramaniam et al. (21) and Holtz and Mitchell (22).

This paper contributes to the field in two key ways. Firstly, it introduces lessons acquired through the iterative process of re-designing, re-developing, and reevaluating an mHealth education app tailored for individuals with type 2 diabetes and those at risk of developing foot ulcers. Secondly, it consolidates these lessons with prior reports.

Methods

In this report, we use autoethnography, which unlike conventional participant observation, places the researcher explicitly as both subject and analyst (23), moving between introspection and outward contextualization (24). This work is grounded in a constructivist paradigm and recognizes the influence of the authors’ positionalities on the research process and outcomes. In health research, autoethnographic inquiry has proven valuable in moving beyond description to processes of sense-making and meaning-construction (25).

Overarching framework

We developed two education apps for people living with diabetes: Glow, which provides comprehensive type 2 diabetes education, and WellFeet, which focuses on foot care and self-care. The work followed a hybrid of two frameworks: Design Thinking framework (26) and Rapid Application Development (RAD) (27) (Table 1). The process model illustrating the research stages mapped onto the framework is shown in Figure 1.

Figure 1 An overview of the iterative process of (re-)designing, (re-)developing, and (re-)evaluating the Glow and WellFeet apps, following a hybrid approach that combines Rapid Application Development and Design Thinking principles.

Stage 1.1 Glow flat prototype development

Following the empathize and define phases, the team assessed user needs, available resources, and timelines to determine the app’s core requirements. Wireframes and mock-ups were iteratively developed in-house using Adobe XD. The user experience flow and branding elements were refined through internal testing. The low-fidelity prototype included two main components: education modules (featuring learning cards, quizzes, and self-reflection prompts) and a standalone chatbot, developed using Quriobot, designed for frequently asked questions and action-oriented conversations. Concurrently, the in-house team—comprising medical doctors, students, and copywriting and graphic specialists—developed the content, including the outline of topics and learning/behavioral/attitude outcomes, style guide, instructional templates and educational materials [details on content development are available elsewhere (28,29)].

Stage 1.2 Glow co-design

Participatory co-design methods were used to test and revise the prototype. Participants were recruited via social media and consented online to participate in this mixed-methods study. Four surveys and two interviews captured user profiles, diabetes experiences, content feedback, and usability perceptions. Insights guided subsequent iterations. Full description is available elsewhere (29).

Stage 2.1 Glow app development

The redevelopment process began with defining goals and creating mock-ups in Adobe XD, which were later refined using Figma (Figma, Inc., San Francisco, CA, USA). The developer—a company with a team of designers, front- and back-end engineers—was selected through a formal procurement process and built early versions of the app for both Android and iOS, along with a content management system (CMS). Corrections and improvements were handled collaboratively through iterative cycles. This included multiple layers of testing: functional testing (to ensure features behaved as expected), integration and system testing (to verify overall compliance with requirements), usability and user acceptance testing (to assess user-friendliness and intuitiveness), as well as interaction and exploratory testing (to uncover issues through both predefined and ad-hoc test cases). Vulnerability and cybersecurity testing were also conducted. The final version of the app included pre-module conversations, personalized content tailored to user roles and preferences, interactive quizzes, and different types of chatbot conversations. The system comprised a CMS for content and app managers, a simple platform for doctors, and an app for patients and caregivers—available via Google Play and TestFlight.

Stage 2.2 Glow randomized controlled trial (RCT)

A six-month RCT was conducted with 81 participants, including 73 patients and 8 caregivers, using a quantitative approach including diabetes health literacy measures. Although the study did not reach its targeted sample size and the final report was not published, app usage data collected during the trial provided valuable insights that informed subsequent refinements to the app. The protocol was registered at ClinicalTrials.gov (NCT05535842).

Stage 3.1 WellFeet app development

WellFeet, mHealth focused on diabetic foot ulcers prevention and management, was developed as an evolution of the Glow platform, incorporating new features such as a gamified dashboard, food and foot diaries, daily tasks, and two-factor authentication during onboarding via One-Time Password (OTP). The contract was awarded to Glow developer through a formal open-quotation procurement process. Lessons from earlier stages also informed design decisions, including a reduced emphasis on the app’s chatbot elements. Following a formal procurement process, design discussions with the vendor were supported by detailed slide decks. Figma mock-ups were iteratively refined through multiple feedback rounds and tested using a custom protocol and defined use cases. Project documentation was transitioned to a status-tracked Excel sheet for better oversight. An analytics framework was further developed to support evaluation. After undergoing IT governance review, the app was deployed via TestFlight and Google Play. Further details are outlined in a published protocol (28).

Stage 3.2. WellFeet feasibility study

A non-randomized, single-arm, mixed-methods study (N=40) assessed feasibility, acceptance and potential impact. Participants, recruited via endocrinologists, received the one-month intervention. The study design is detailed in the published protocol (28). The study was registered at ClinicalTrials.gov (NCT05564728).

Ethical statement

The studies were conducted in accordance with the Declaration of Helsinki and its subsequent amendments. The Glow Co-design study was approved by the ethics board of Nanyang Technological University Singapore (IRB-2020-04-010); the Glow RCT was approved by the ethics board of National Healthcare Group Singapore (NHG DSRB Ref: 2022/00214); and the WellFeet feasibility study was approved by the ethics board of National Healthcare Group Singapore (NHG DSRB Ref: 2022/00614). Informed consent was taken from all the patients before data collection.

Results

Glow and WellFeet are a result of a multi-phase development process guided by Design Thinking and RAD frameworks. The process of (re-)designing, (re-)developing and (re-)evaluating the apps yielded valuable insights in three areas: (re-)designing app features, adjusting to regulatory landscape, and synchronizing with the developer. Figure 2 sums up the insights gained in the process.

Figure 2 Overview of challenges and insights.

(Re-)designing app features

The integration of co-design study in the Glow app development process yielded recommendations for desired content and app qualities identified in co-design study. Due to the scope of the app developer’s contract and budget constraints, some of the design suggestions put forward by the participants could not be implemented in the RCT app built, some were developed in subsequent WellFeet build (see Table S1 in Appendix 1).

WellFeet app introduced tracking tools and gamified elements not present in Glow, including food and foot diaries, daily task checklists, a gamified dashboard, and congratulatory messages. These features supported symbolic incentivization and monitoring, leading to higher user satisfaction with the learning experience compared to Glow, where the focus was purely educational.

Low retention during the Glow RCT prompted the introduction of a more sophisticated notification system including automated spaced learning, inactivity reminders, and manual notifications connected to selected functionalities and targeting specific users. Additionally, WellFeet adopted a more tailored approach to learning. Glow RCT data showed that users often exited before engaging with adaptive learning conversations, indicating that the chatbot’s role was unclear. In response, WellFeet redesigned adaptive questions as quiz cards and introduced a more structured pathway. Additionally, the dashboard provided clearer guidance on the recommended learning journey. Appendix 1 shows screenshots of both apps.

Adjusting to regulatory landscape

In addition to following established guidelines on privacy, ethics, and user-centered design, we also needed to navigate a complex and dynamically changing regulatory landscape. During the development of Glow, institutional guidelines prioritized minimizing personal data collection due to security concerns. This led to the removal of features that required the collection of phone numbers and information such as date of birth. In contrast, WellFeet retained phone number collection to improve user experience for password retrieval, though it required extensive cybersecurity documentation and reporting.

Both Glow and WellFeet faced platform-related challenges. The App Store raised concerns about Glow’s business model and ownership. At that stage, the app was intended for testing and operated on a non-profit basis. Initially, the App Store account holder was the principal investigator; this was later changed to the app developer. The App Store recommended that the app be made available privately or as an unlisted version, and required that it be published under the university’s name rather than that of the principal investigator or developer. Publishing under the university’s name would have required a lengthy approval process; therefore, to avoid delays, the iOS version was distributed via TestFlight. Next, integrating step and sleep tracking through Google Fit in WellFeet required following Google Play’s strict verification process. Compliance required updating the app’s terms and conditions, creating a user guidance website, submitting security documentation, and clarifying study protocols.

Unexpected work also arose around OTP delivery. To prevent SMS messages from being flagged as spam in Singapore, the team had to register as a formal SMS sender according to country level regulations—an administrative task that required senior university authorization. While this process might be straightforward in commercial settings, it proved time-consuming in an academic context, as it involved obtaining signatures from high-level personnel, which delayed the start of the study.

Synchronizing with the developer

Synchronizing with the developer requires understanding their workflows and finding common language to allow clearer communication that supports requests and revisions (see Appendix 2). During Glow’s development, early design discussions felt mismatched. The research team expected a quick prototype, whereas the developer focused on the backend engineering. Misalignment stemmed from a limited understanding of the developer’s workflow and inadequate communication of app flow, which relied too heavily on academic terminology. In the WellFeet iteration, the team benefited from not having to build everything from scratch and could focus on describing add-ons or modifications based on an already existing product, using screenshots from the Glow app with graphic indicators of modifications. We also allowed for more creative freedom in design drafts. It was notably helpful that the same developer worked on both apps. Testing—in-house and before sharing the app with the end-users—was improved as well: a detailed Figma-based comments specifying screen behaviors and visual elements on the one hand, and bugs and requests in an Excel sheet, including feature association, priority, and status, on the other. Also, the conversation around expectations for user analytics became more concrete, informed by Glow’s RCT, which highlighted limitations in the initial usage data. This, in turn, helped clarify the level of granularity the team expected from future analytics. This streamlined communication, building strong rapport with the developer and enabled focused, efficient testing every two weeks.

Discussion

This paper presents the outcomes of an iterative design process involving two diabetes education apps, developed using a hybrid of RAD and Design Thinking approaches. The process included (re-)designing, (re-)developing and (re-)evaluating the apps with particular emphasis on (re-)designing app features, adjusting to regulatory landscape, and synchronizing with the developer. The paper contributes to existing mHealth development literature by extending lessons from prior studies (21,22) presented in Table 2 and described below. Collectively these could converge into the following: prepare in advance and act deliberately, yet remain iterative and embrace the unexpected with resourcefulness, adaptability, and humility—recognizing that success is never achieved in isolation.

Lesson learned: prepare to clarify the vision iteratively and in a multidisciplinary environment

Subramaniam et al. (21) emphasized that investing time in the design phase can significantly reduce delays later in development—captured in the phrase, “design twice, develop once”. Aligning on a shared vision with stakeholders, grounded in insights from the empathizing and defining phases, is essential for a streamlined prototyping process. Creating a low-fidelity flat prototype that visualizes nearly all app steps helps clarify the team’s vision and enhances understanding of the intervention’s finer details (21). During this phase, mock-ups are critical for identifying potential usability issues (30) or unmet user needs (31), guiding both the research team and developers in mapping out the user journey more precisely. However, as pointed out by Weber and colleagues, this might be a difficult act of balancing “between having an early prototype and specifying the technical implementation” (32).

Importantly, articulating the vision often requires repeated communication—from explaining it to your own team and stakeholders, to translating it for target users and developers, who may not share the same academic language. Roth et al. (33) noted that such communication challenges are common in mHealth development, where multidisciplinary collaboration can expose gaps in understanding—and this project was no exception. The structure of our multidisciplinary team was heavily dependent on external circumstances, including COVID-19 restrictions and limited manpower. The team included a principal investigator with clinical expertise, at the WellFeet evaluation phase succeeded by one with a background in psychology; graphic and product design, and copywriting specialists who led the development process with the developer [one during Glow’s conceptualization phase and another (A.P.) during Glow’s development, evaluation, followed by all phases of WellFeet project]; a public health specialist coordinating the conceptualization phase; research assistants supporting app testing; a diabetes specialist overseeing operational aspects; computer scientists involved in drafting the user analytics framework; and other researchers contributing to evidence-based searches on effective features and functions. Team composition and member responsibilities varied over time, as several individuals were engaged in concurrent projects or involved in the centre’s activities only temporarily. Weber and colleagues suggest allocating specific time to build a common understanding between the team members with various backgrounds (epistemic clashes and negotiations are unavoidable) as well as embracing flexibility (32). This is, of course, beyond liaising with other stakeholders, including community leaders (34). Considering our experiences, we recognise the value of this recommendation, while also acknowledging the challenges it presents.

As noted by Siegler et al., “there is an inherent information asymmetry between professional app developers’ expertise in coding and researchers possessing terminal degrees in unrelated fields” (35). It is imperative to leverage the data collected when the app is used in the evaluation phase (5,36). For this, a skilled professional, ideally equipped with cybersecurity knowledge, is essential to ensure alignment with data privacy regulations and build a data repository (21). Equally important is the level of detail of the data collection roadmap and a clear architecture of collected data (22). Communication with the developer needs to be clear and iterative, which might require the project team to adjust, as well as be appreciative of the developer’s specific expertise in market standards (36). It is similarly advantageous to specify the level of priority assigned to the desired feature for the developer to better plan the work. The vision will need further clarification when juxtaposed with prototype designs provided by the developer.

Lesson learned: remain flexible as the requirements and regulatory environment may shift, impacting your product and project plan

Adaptability plays a pivotal role in app development, given that anticipated results from tests and evaluations may not always align with expectations. This is especially true as there are multiple layers of requirements to consider: regulatory, market, design and societal (37) aside from research-focused intervention active ingredient, such as behavior change techniques (38). This often requires the incorporation of new features and adjustments to testing strategies that can evolve alongside the product. As a result, the ability to shift the design and development strategy to accommodate fresh insights obtained from ongoing research, end-user evaluations, or testing becomes essential. This readiness is critical, particularly considering that the mHealth development process involves multiple rounds of discovery (33). Moreover, following the recommendation of Pach et al. (39), it is advised to concurrently develop the app and its intervention as certain aspects of the app, such as integrating questionnaires, can influence the study protocol. Hence, notably, it is not only the technology that must adapt to the user, but also the team that must remain adaptable.

To alleviate the impacts of time pressure, engaging various decision-making bodies early in the process may facilitate, while also logistically complicating, the discovery or creation of novel procedures in the narrow and broad regulatory landscape. While anticipating shifts in the regulations, including organizational policies, governmental requirements, or Google Play and App Store prerequisites, is helpful, it may not always be feasible. One challenge arises from potential misalignments between the timelines of funded research, technological product development, and market dynamics (35). To address this issue, cultivating positive relationships with diverse regulatory bodies and fellow researchers engaged in similar projects can help mitigate the risks associated with prolonged delays resulting from attempts to adjust to regulatory changes. This becomes particularly relevant when considering post-research activities and further translation, which introduces its own set of operational challenges, such as the budget for maintenance or updates to mitigate technology becoming obsolete (5).

Conclusions

mHealth apps play an increasingly prominent role in healthcare system, offering scalable and cost-effective solutions. However, their design, development and evaluation remain complex, requiring more than high-level considerations. Drawing on lessons from past projects is essential to anticipate challenges, identify best practices, and improve future interventions. As mHealth continues to grow, sharing practical insights becomes key to driving innovation, supporting regulatory readiness, and ensuring meaningful impact across diverse healthcare settings.

Acknowledgments

The authors gratefully acknowledge Daniel Chew Ek Kwang and Liew Huiling from Tan Tock Seng Hospital for their invaluable contributions as Site Principal Investigators for both the randomized controlled trial and the feasibility study. The authors wish to also express their sincere appreciation to individuals whose efforts at various stages of the projects were instrumental in making the development of the app possible: Quah Jialong Josh (Glow preliminary wireframes, the first versions of flat prototype, ITQ text), Anne Claire Stona (Glow project lead), Yichi Zhang (usage analytics conceptualization), Ashwini Lawate (database management), Nandika Lodh, Kelley Goh (WellFeet testing), Daniel Mahadzir (liaising with IT stakeholders), Charlotte Sauter, Thai My Linh, Yuri Rykov, Foong Hui Foh, Lin Xiao Jing, Joel Lee Wen Peng, Sui Jing Lim, Victor Goh, Naren Surendra, Ivica Boticki, Iva Bojic. Thank you to all who contributed to the content development and review, which impacted app’s design and functionalities. Lastly, and most importantly, we would like to thank our app developers, Cognitive Clouds and Mahalo, for their hard work and patience, especially Prasanna Gopinath, Guruprasad Jayarao, Raghunandan Vasudevamurthy and Morsh Rajendran.

Footnote

Peer Review File: Available at https://mhealth.amegroups.com/article/view/10.21037/mhealth-25-60/prf

Funding: This research was supported by the Singapore Ministry of Health’s National Medical Research Council under the Health Services Research Grant (HSRG-DB17Nov002), and the Ministry of Health (grant number MOH/NIC/CDM2/2018).

Conflicts of Interest: All authors have completed the ICMJE uniform disclosure form (available at https://mhealth.amegroups.com/article/view/10.21037/mhealth-25-60/coif). The authors have no conflicts of interest to declare.

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. The studies were conducted in accordance with the Declaration of Helsinki and its subsequent amendments. The Glow Co-design study was approved by the ethics board of Nanyang Technological University Singapore (IRB-2020-04-010); the Glow RCT was approved by the ethics board of National Healthcare Group Singapore (NHG DSRB Ref: 2022/00214); and the WellFeet feasibility study was approved by the ethics board of National Healthcare Group Singapore (NHG DSRB Ref: 2022/00614). Informed consent was taken from all the patients before data collection.

Open Access Statement: This is an Open Access article distributed in accordance with the Creative Commons Attribution-NonCommercial-NoDerivs 4.0 International License (CC BY-NC-ND 4.0), which permits the non-commercial replication and distribution of the article with the strict proviso that no changes or edits are made and the original work is properly cited (including links to both the formal publication through the relevant DOI and the license). See: https://creativecommons.org/licenses/by-nc-nd/4.0/.

References

1. Chong CJ, Bakry MM, Hatah E, et al. Effects of mobile apps intervention on medication adherence and type 2 diabetes mellitus control: A systematic review and meta-analysis. J Telemed Telecare 2023; Epub ahead of print. [Crossref]
2. Okolo CA, Babawarun O, Arowoogun JO, et al. The role of mobile health applications in improving patient engagement and health outcomes: A critical review. Int J Sci Res Arch 2024;11:2566-74.
3. Katsaliaki K, Kumar S, Galetsi P. Patient and societal indicators for mHealth apps’ evaluation using Health Technology Assessment framework. Technovation 2025;140:103143.
4. Adnan A, Irvine RE, Williams A, et al. Improving Acceptability of mHealth Apps-The Use of the Technology Acceptance Model to Assess the Acceptability of mHealth Apps: Systematic Review. J Med Internet Res 2025;27:e66432. [Crossref] [PubMed]
5. Loo RTJ, Nasta F, Macchi M, et al. Recommendations for Successful Development and Implementation of Digital Health Technology Tools. J Med Internet Res 2025;27:e56747. [Crossref] [PubMed]
6. Mertens ECA, Van Gelder JL. The DID-guide: A guide to developing digital mental health interventions. Internet Interv 2025;39:100794. [Crossref] [PubMed]
7. Nadarzynski T, Knights N, Husbands D, et al. Achieving health equity through conversational AI: A roadmap for design and implementation of inclusive chatbots in healthcare. PLOS Digit Health 2024;3:e0000492. [Crossref] [PubMed]
8. Wilson S, Tolley C, Mc Ardle R, et al. Recommendations to advance digital health equity: a systematic review of qualitative studies. NPJ Digit Med 2024;7:173. [Crossref] [PubMed]
9. Schweitzer R, Schlögl S, Schweitzer M. Technology-Supported Behavior Change-Applying Design Thinking to mHealth Application Development. Eur J Investig Health Psychol Educ 2024;14:584-608. [Crossref] [PubMed]
10. Naderbagi A, Loblay V, Zahed IUM, et al. Cultural and Contextual Adaptation of Digital Health Interventions: Narrative Review. J Med Internet Res 2024;26:e55130. [Crossref] [PubMed]
11. Golubović G, Dedijer S, Kerac J, et al. UI/UX design and usage effectiveness of mHealth applications: review paper. Univ Access Inf Soc 2025;24:2091-104.
12. Sharma S, Kumar BA. A systematic review of user-based usability testing practices in self-care mHealth apps. Digit Health 2025;11:20552076251374184. [Crossref] [PubMed]
13. Caiani EG, Kemps H, Hoogendoorn P, et al. Standardized assessment of evidence supporting the adoption of mobile health solutions: A Clinical Consensus Statement of the ESC Regulatory Affairs Committee: Developed in collaboration with the European Heart Rhythm Association (EHRA), the Association of Cardiovascular Nursing & Allied Professions (ACNAP) of the ESC, the Heart Failure Association (HFA) of the ESC, the ESC Young Community, the ESC Working Group on e-Cardiology, the ESC Council for Cardiology Practice, the ESC Council of Cardio-Oncology, the ESC Council on Hypertension, the ESC Patient Forum, the ESC Digital Health Committee, and the European Association of Preventive Cardiology (EAPC). Eur Heart J Digit Health 2024;5:509-23. [Crossref] [PubMed]
14. Freitas L, Oliveira MD, Vieira ACL. Guiding stakeholder involvement in health technology assessment for medical devices: A novel approach for clarifying stakeholders’ roles and contributions. Health Policy and Technology 2025;14:101075.
15. Moungui HC, Nana-Djeunga HC, Anyiang CF, et al. Dissemination Strategies for mHealth Apps: Systematic Review. JMIR Mhealth Uhealth 2024;12:e50293. [Crossref] [PubMed]
16. Khan ZA, Kidholm K, Pedersen SA, et al. Developing a Program Costs Checklist of Digital Health Interventions: A Scoping Review and Empirical Case Study. Pharmacoeconomics 2024;42:663-78. [Crossref] [PubMed]
17. Tumuhimbise W, Theuring S, Kaggwa F, et al. Enhancing the implementation and integration of mHealth interventions in resource-limited settings: a scoping review. Implement Sci 2024;19:72. [Crossref] [PubMed]
18. Ku JP, Sim I. Mobile Health: making the leap to research and clinics. NPJ Digit Med 2021;4:83. [Crossref] [PubMed]
19. Perrin Franck C, Babington-Ashaye A, Dietrich D, et al. iCHECK-DH: Guidelines and Checklist for the Reporting on Digital Health Implementations. J Med Internet Res 2023;25:e46694. [Crossref] [PubMed]
20. Liyanage A, Irfaan S, Moonesinghe L, et al. Reporting Digital Health Implementations Based on the iCHECK-DH Guidelines and Checklist: Development of an Interactive Toolkit. J Med Internet Res 2025;27:e74235. [Crossref] [PubMed]
21. Subramaniam A, Hensley E, Stojancic R, et al. Careful considerations for mHealth app development: lessons learned from QuestExplore. Mhealth 2022;8:24. [Crossref] [PubMed]
22. Holtz BE, Mitchell K. Best Practices for Developing a Diabetes mHealth App. J Diabetes Sci Technol 2024;18:39-45. [Crossref] [PubMed]
23. Ellis CS, Bochner AP. Autoethnography, personal narrative, reflexivity: researcher as subject. In: Denzin NK, Lincoln YS, eds. Handbook of qualitative research. 2nd ed. Sage; 2000:733-68.
24. Adams TE, Jones SH, Ellis C, et al. Autoethnography (Understanding Qualitative Research). 1st ed. Oxford, New York: Oxford University Press; 2014.
25. Bochner A, Ellis C. Evocative Autoethnography: Writing Lives and Telling Stories. 1st ed. New York: Routledge; 2016.
26. d.School. An Introduction to Design Thinking PROCESS GUIDE [Internet]. Stanford University d.School; Available online: https://web.stanford.edu/~mshanks/MichaelShanks/files/509554.pdf
27. Martin J. Rapid Application Development. New York: Macmillan Publishing Company; 1991.
28. Liew H, Pienkowska A, Ang CS, et al. Empowering Foot Care Literacy Among People Living With Diabetes and Their Carers With an mHealth App: Protocol for a Feasibility Study. JMIR Res Protoc 2023;12:e52036. [Crossref] [PubMed]
29. Pienkowska A, Ang CS, Mammadova M, et al. A Diabetes Education App for People Living With Type 2 Diabetes: Co-Design Study. JMIR Form Res 2023;7:e45490. [Crossref] [PubMed]
30. Holzinger A, Waclik O, Kappe F. Rapid prototyping on the example of software development in automotive industry. In: Proceedings of the International Conference on e-Business [Internet]. Seville, Spain: SciTePress - Science and and Technology Publications; 2011:57–61. [cited 2025 Sep 3]. Available online: http://www.scitepress.org/DigitalLibrary/Link.aspx?doi=10.5220/0003524200570061
31. Thurston C, Johansson S, von Koch L, et al. Cross-sector collaboration to develop a mobile health solution for promotion of physical activity after stroke or transient ischaemic attack in Sweden. BMC Digit Health 2025;3:28.
32. Weber M, Mattli R, Raab AM, et al. What to Consider When Developing Multidomain Mobile Health Interventions for Lifestyle Management. JMIR Mhealth Uhealth 2025;13:e63573. [Crossref] [PubMed]
33. Roth WR, Vilardaga R, Wolfe N, et al. Practical considerations in the design and development of smartphone apps for behavior change. J Contextual Behav Sci 2014;3:269-72. [Crossref] [PubMed]
34. Mann-Jackson L, Alonzo J, Chaffin JW, et al. Lessons Learned From a Trial of a Bilingual Community-Based Peer Navigation And mHealth Intervention to Address HIV, STI, HCV, and Mpox Inequities Among GBQMSM and Transgender and Nonbinary Persons in Appalachia. AIDS Educ Prev 2025;37:273-87. [Crossref] [PubMed]
35. Siegler AJ, Knox J, Bauermeister JA, et al. Mobile app development in health research: pitfalls and solutions. Mhealth 2021;7:32. [Crossref] [PubMed]
36. Park JY, Lee G, Shin SY, et al. Lessons learned from the development of health applications in a tertiary hospital. Telemed J E Health 2014;20:215-22. [Crossref] [PubMed]
37. Bin Naeem S, Azam M, Kamel Boulos MN, et al. Leveraging the TOE Framework: Examining the Potential of Mobile Health (mHealth) to Mitigate Health Inequalities. Information 2024;15:176.
38. Kheirdoust A, Mazaheri Habibi MR, Emadzadeh A, et al. Investigating the approach of using behavior change techniques in the field of mobile applications: a systematic review. BMC Health Serv Res 2025;25:1347. [Crossref] [PubMed]
39. Pach D, Rogge AA, Wang J, et al. Five Lessons Learned From Randomized Controlled Trials on Mobile Health Interventions: Consensus Procedure on Practical Recommendations for Sustainable Research. JMIR Mhealth Uhealth 2021;9:e20630. [Crossref] [PubMed]