Using Co-design in Mobile Health System Development: A Qualitative Study With Experts in Co-design and Mobile Health System Development

Background: The proliferation of mobile devices has enabled new ways of delivering health services through mobile health systems. Researchers and practitioners emphasize that the design of such systems is a complex endeavor with various pitfalls, including limited stakeholder involvement in design processes and the lack of integration into existing system landscapes. Co-design is an approach used to address these pitfalls. By recognizing users as experts of their own experience, co-design directly involves users in the design process and provides them an active role in knowledge development, idea generation, and concept development. Objective: Despite the existence of a rich body of literature on co-design methodologies, limited research exists to guide the co-design of mobile health (mHealth) systems. This study aims to contextualize an existing co-design framework for mHealth applications and construct guidelines to address common challenges of co-designing mHealth systems. Methods: Tapping into the knowledge and experience of experts in co-design and mHealth systems development, we conducted an exploratory qualitative study consisting of 16 semistructured interviews. Thereby, a constructivist ontological position was adopted while acknowledging the socially constructed nature of reality in mHealth system development. Purposive sampling across web-based platforms (eg, Google Scholar and ResearchGate) and publications by authors with co-design


Background
The proliferation of mobile devices (eg, smartphones and tablets) has enabled new ways of delivering health services via mobile health (mHealth) systems [1,2]. Broadly, mHealth can be defined as "medical and public health practice supported by mobile devices, such as mobile phones, patient monitoring devices, personal digital assistants (PDAs), and other wireless devices" [3]. The ubiquity and increasing capabilities of these systems have created enormous potential to support individuals in self-managing existing health conditions (eg, diabetes and stroke) and reducing their health risks by supporting healthier lifestyle habits (eg, increasing vegetable intake). The adoption of mHealth systems is steadily growing. In 2018, nearly half of the consumers in health care used mHealth systems compared with one-sixth in 2014. Overall, the global mHealth market is expected to grow from US $28.320 billion in 2018 to US $102.35 billion by 2023 [4].
Researchers have repeatedly emphasized that mHealth systems design and development is a complex endeavor with a range of pitfalls limiting adoption and/or effective usage in practice [5]. This is because the design process commonly entails limited stakeholder involvement [5,6], and solution artifacts lack integration with other health systems or their components [7]. To address these complexities, scholars have suggested co-design for mHealth systems development. Co-design refers to "the creativity of designers and people not trained in design, working together in the design development process" [8].
Research has referred to two main reasons for using co-design: (1) mHealth is a complex environment that requires the involvement of diverse stakeholders (eg, consumers/end users, government, health practitioners, scientists, and software developers) with co-design facilitating necessary collaborations [1,9,10]; (2) using co-design ensures that mHealth systems are underpinned by expert insights and best practices [5,11,12].
Despite repeated calls to use co-design for mHealth systems development [5,6], there is only limited guidance available on how to do so. The existing literature on co-design methodology provides important general guidance for the application of co-design frameworks and methods [8,13,14]. However, given the complexities surrounding a person's health and the multitude of stakeholders, there is a need for research that identifies the specific challenges system designers face when applying co-design in mHealth and to illustrate ways in which these challenges can be addressed. As such, there is a lack of guidance in the current literature in terms of how one can apply co-design in the mHealth systems context.

Objective
In this paper, we address this research gap by conducting a qualitative study that explores how co-design can be used in mHealth systems development. Specifically, we conducted 16 semistructured interviews to synthesize the theoretical and practical expertise of 8 co-design method experts (CMEs) and 8 mHealth system developers (MSDs) in a rapidly growing application area. Interviews were transcribed and analyzed using thematic analysis [15]. Thereby, the overarching research objectives of this study were (1) to contextualize an existing co-design framework for mHealth applications and (2) to construct guidelines to address common challenges of using co-design in mHealth development.

Related Work on mHealth Systems Design
mHealth systems have become a growing area for research and practice [16,17]. The two primary application domains that have emerged are (1) disease management and (2) health promotion. First, disease management empowers patients to manage their medical conditions more effectively and independently (eg, controlling blood sugar levels [18,19]). Second, health promotion facilitates better health choices by providing support and encouragement for users to engage in behaviors to lower risk factors and improve health (eg, better diet and smoking cessation). The design of mHealth systems is complex, with a range of pitfalls including limited stakeholder involvement [5], lack of integration with other health systems [7], and disregard of behavior change techniques [5].
Several studies have sought to improve mHealth systems design. McCurdie et al [20] discussed a user-centered design approach for mHealth systems development. The term user-centered design refers to "a design philosophy that places the needs, wants, and limitations of end users at the center of the design process" [21]. However, it should be noted that user-centered design adopts an expert perspective where "trained researchers observe and/or interview largely passive users" [8]. In contrast, in co-design, the user is in the position of being an expert of their own experience and actively plays a "large role in knowledge development, idea generation, and concept development" [8]. Banos et al [22] developed an architecture that showed how specific functionalities and components of mHealth systems could be implemented. Building on a user-centered design, Schnall et al [23] developed a 3-cycle framework (relevance, design, and rigor) to better incorporate end users' preferences. Eckman et al [1] developed an mHealth systems framework that considers design thinking principles, using "a hypothesis-driven method of generating and validating new concepts" [1]. Nahum-Shani et al [24] explored the design of just-in-time adaptive interventions to support users' health behavior change. However, there has been limited focus on how to apply a co-design approach that involves stakeholders within the mHealth context.

Co-design Frameworks
Researchers have proposed several frameworks to facilitate co-design [8,13,14]. By creating a conceptual structure of the process, these frameworks provide a shared frame of reference for researchers and practitioners engaging in system design. As noted by Sanders and Stappers [13], these frameworks can be understood as a response to the increased attention to methods: "So many methods, tools and techniques have been introduced that it has become useful to provide frameworks for organizing them" [13]. For instance, the framework by Visser et al [14] structured the co-design process into five phases: preparation, sensitization, sessions, analysis, and communication. Brandt et al [25] described an iterative cycle of making, telling, and enacting. Building on these earlier conceptualizations, the framework by Sanders and Stappers [13] has become one of the most widely recognized co-design resources (538 citations on Google Scholar, February 2021). The framework breaks down the timeline of the co-design process (shown in blue) into 4 interconnected phases (Figure 1, adapted from a study by Sanders and Stappers [13]).
1. The predesign phase is concerned with understanding the surrounding context and people's experiences, exploring knowledge in the user context, establishing goals for future experiences, and sensitizing participants to the problem space [8,13]. 2. The generative phase focuses on producing ideas, insights, and concepts that explore the design space, with users taking an active role in making through co-creation of conceptual artifacts (eg, journey maps, mock-ups, and storyboards). Although the vision is still fuzzy, these activities test, transform, and refine ideas, insights, and concepts that may then be designed and developed [13]. 3. The evaluative phase allows users to assess the effects and effectiveness of the devised concepts. The vision of the final artifact becomes more tangible through the evaluation prototypes that allow users to experience a situation that did not exist before [13]. 4. The postdesign phase captures the notion that once a system is part of a user's lived experiences, it needs to evolve along with their needs, habits, and use patterns. Hence, the tail end of the postdesign phase [leads] to the front end of another design process [13].

Overview
In this research, we adopted a constructivist ontological position and acknowledge the socially constructed nature of reality in mHealth systems development [51,52]. Recognizing that there is no single truth, constructivist approaches to research generate meaning through a collaborative dialog between researchers and the research participants [51].

Research Participants
We used a purposive sampling method to identify and recruit participants from 2 groups for interviews, namely, CMEs and MSDs. CMEs were recruited on the web using Google, Google Scholar, LinkedIn, Twitter, and ResearchGate to identify experts in co-design (eg, book authors, academics, and consultants). The MSD group was recruited by searching papers and reports by authors with co-design experience in mHealth. Interviewees had to be aged at least 18 years and fluent in English. Individuals were contacted by the first author via email with a study information statement before obtaining written informed

Data Collection
Data were collected between July 2019 and January 2020. Before the interview, the research participants received a two-page information statement via email about the research objectives, scheduled interview duration, and assurance of data anonymization. Individuals who provided written consent to participate were interviewed by the first author at a mutually convenient time using Zoom or Skype videoconferencing as per the interviewee's preference. The interviews were semistructured in nature, with the interviewer using a protocol composed of open-ended questions and probing for additional information when required. The interviews focused on two research objectives: (1) contextualizing an existing co-design framework to the mHealth space and (2) constructing guidelines to address common challenges in this context (see the interview guide in Multimedia Appendix 2). Open-ended questions provided the interviewees with opportunities to speak freely and to guide the discussion in the directions of interest.

Data Analysis
The first author coded the transcripts following the procedure of Braun and Clarke [15], which included (1) familiarization with the data, (2) coding, (3) searching for themes, (4) reviewing themes, (5) defining and naming themes, and (6) writing up. In step 1, this involved familiarization with the data by repeatedly reading and rereading the transcripts (ie, prolonged engagement). In step 2, the first author performed the initial coding in NVivo. The second author then checked these codes and validated them against the transcripts. Initially, we identified 154 codes from all interviews (eg, power distance and vulnerability). In step 3, the first and second authors clustered nodes into common themes based on coherent patterns. In several discussions between the authors, the identified themes became the foundation of the guidelines. In the results section, data extracts are quoted to support framework contextualization and guideline development.
In step 5, the authors further refined the guidelines by eliminating redundant themes and naming the guidelines. Figure 2 shows the contextualization of the Sanders and Stappers [13] co-design framework for the mHealth setting. It extends the 4 phases of the original framework by dedicated prototyping and implementation phases. A detailed overview of the example quotes for contextualization is provided in Multimedia Appendix 3. The first extension was the inclusion of a dedicated implementation phase. Interview participants noted that in the context of mHealth, there is a need to separate implementation from the evaluative phase. This is because the evaluative phase primarily focuses on testing the feasibility of the mHealth system rather than the wider rollout of the system into a complex mHealth ecosystem: In contrast, a dedicated implementation phase should focus on facilitating the integration of mHealth artifacts into complex systems and stakeholder environments. In other words, it is important to not only consider the design of the technical mHealth artifact, but everything else around it that is necessary for it to be successfully implemented. This includes important aspects such as documentation, training, and involving key stakeholders in the rollout (see postdesign advocates, guideline 5). The other important consideration discussed in the interviews was the importance of considering implementation right from the beginning of the co-design process:

Contextualization of Co-design Framework to mHealth Context
You would want implementation to be on the agenda right from the initial co-design process. You  The second extension pertains to a separate prototyping phase before the evaluative phase to acknowledge the complexity of mHealth artifacts and their evaluation requirements (eg, pilot-testing and randomized controlled trials). Including a separate prototyping phase assists in separating generative co-design methods in the generative phase (eg, paper prototyping), from instantiations in which the idea for the solution has become more mature and where (high fidelity) prototyping occurs (ie, hardware and software prototypes). Furthermore, it emphasizes the need for a fully functional prototype at the end of the prototyping phase, suitable for rigorous evaluation in the real-world context as part of the evaluative phase (eg, pilot-testing and randomized controlled trials). In addition, separating the prototyping and evaluative phases can clarify which stakeholders should be involved in which phase and in what capacity they should be involved (eg, app developers in the generative phase may simply observe or consult with the end users, whereas in the prototyping phase, they are developing a prototype): Finally, it is important to consider the context in which the co-design phases occur. The contextualized framework categorizes the generative and prototyping phases as phases in which generative engagement occurs. These phases involve gathering co-design participants from potentially diverse areas (eg, health practitioners and designers) in one place (eg, a co-design workshop in a studio or lab) to engage in generative co-design methods (eg, storyboarding and paper prototyping). However, it is important to note that, especially in the health context, it may not always be possible for end users to gather in the same physical space: Hence, for co-design to be accessible to end users, generative engagement does not necessarily need to occur in the presence of all stakeholders or in the same physical space. For example, Smeenk et al [54] described an empathic handover approach in which end users can participate in the early phases of co-design alongside a principal designer who later translates these contributions [54]. On the other hand, there are also co-design phases that require immersion in the real-world context in which the mHealth system will eventually be implemented (see also guideline 4). For example, in the predesign phase, interviews or observations may be carried out in a hospital to gain a better understanding of the problem and the stakeholders that need to be involved. Given the focus on the real-world context, this immersion is especially important for the predesign, evaluative, implementation, and postdesign phases:

Guidelines for Co-Designing in mHealth
On the basis of the thematic analysis of the interviews, we constructed seven guidelines (guidelines 1-7; Textbox 1) to address the challenges in co-designing mHealth systems. Multimedia Appendix 4 provides a detailed overview of example quotes. Textbox 1. Guidelines 1-7.

Guideline 1
• Carefully consider the unique circumstances of the targeted disease management or health promotion context with respect to its evaluation and integration requirements, stakeholder involvement, and end user vulnerabilities relating to highly personal aspects of a person's health.

Guideline 2
• As early as possible in the co-design process, consult the behavior change literature and/or involve experts in behavior change relevant to the problem context to effectively identify the targeted change in behavior and adequately plan the type and stakeholder involvement of co-design activities.

Guideline 3
• Select and engage co-design facilitators that have an authentic understanding of the intimate problem context (eg, first-hand experience, immersing in problem context, and literature consultation) and operate in an empathetic way to mitigate potential barriers associated with the power distance between mHealth stakeholders.

Guideline 4
• Immerse yourself in the underlying complex health context to identify and understand stakeholders early, include them in defining their involvement in the co-design process along existing health process requirements, recognize the diversity and inherent power distances among stakeholders, and prioritize the needs of the end user.

Guideline 5
• Throughout every phase of co-design, identify potential postdesign advocates from different stakeholder categories who can aid in implementing the mHealth system (eg, training staff in the use of the system) and champion its use in the postdesign phase (eg, providing feedback on system use in practice).

Guideline 6
• In the evaluative phase, ensure that the mHealth system goes through feasibility testing in the real world (pilot-testing and randomized controlled trials) to adequately address ethical considerations in the health context, determine potential risks to the end users caused by the artifact, and clarify whether it accomplishes its intended goals before implementation.

Guideline 7
• In the postdesign phase, collect usage data to observe the mHealth system's impact after it has been implemented and apply contextual co-design methods to understand this impact.

Guideline 1: Understanding Stakeholder Vulnerabilities and Diversity
The interviews emphasized important differences between health promotion and disease management, including (1) that mHealth users have unique vulnerabilities, (2) the diverse array of stakeholders involved, (3) the significance of evaluation, and (4) the actual implementation and translation. Owing to the focus on health outcomes, mHealth typically involves vulnerable user groups (users with health conditions that may create additional barriers to participation, eg, patients). Although this vulnerability may be present in some groups within health promotion (eg, smoking cessation and alcohol reduction), it appears to be most prevalent among the disease management cohort (eg, dementia and autism). This vulnerability creates challenges for (1) recruiting representatives from the target cohort and (2) being mindful of their health vulnerabilities: [CME2] With the specific focus of supporting positive health outcomes, the co-design process inherently touches on vulnerable, deeply personal aspects that, in turn, require high levels of trust in the research team and process. Hence, it is vital to select co-design tools and methods that are appropriate in this context and allow vulnerable end users to participate in the best of their capabilities: Each specific mHealth context also has its own diversity of stakeholders who need to be identified and involved in the co-design process. There may also be more than one category of end users, such as both the patient and the health practitioner, with differing requirements in terms of evaluation: The last element of this guideline is the integration of mHealth tools into a wider system landscape. One of the largest identified differences between co-design in mHealth and other contexts is that mHealth systems need to integrate into a highly complex health ecosystem involving an array of health processes, systems, and stakeholders: It is not just about the end product, it is about everything that goes with it that we need to test and work out too. So, the instructions that we give to people as to how to use it, how we advertise it, who we train in the facility in terms of helping patients to use it, how we promote it to staff so that they know it is available to their patients as well. [MSD1]

Guideline 2: Planning for and Assessing Health Behavior Change
The second theme refers to the importance of consulting the behavior change literature and considers directly involving behavior change experts in the co-design process. Overall, the importance of consulting the behavior change literature was mentioned in 9 of the interviews (4 CMEs and 5 MSDs). The importance of behavior change for mHealth systems design relates back to the very nature of the underlying health promotion and disease management contexts, in that the purpose of these systems involves some change in user behavior to address a health goal [55]. For health promotion, this commonly refers to a change in lifestyle behaviors, such as reducing alcohol consumption and quitting smoking [49,56] or improving eating habits [47]. For disease management, examples include regularly performing rehabilitation exercises [41], following a specific medication regime [57], or recording specific aspects of daily activities [39,41]. Interviewees emphasized that because behavior change is not a by-product but is integrally linked to the purpose of the mHealth system, it is vital to explore in the early stages of the co-design process which behaviors are addressed and in what way: MSD6 elaborated that a key distinguishing factor between mHealth and other contexts is that co-designing mHealth systems is linked to changes in behavior that are often deeply personal to the end users, which are linked to deeply embedded long-term habits (eg, eating, physical activity, and sleep patterns): Finally, given the focus on mHealth systems to achieve positive health outcomes, it is vital to carefully tailor the co-design activities to the individual circumstances and capabilities of the stakeholders, particularly the end user: Co-design frameworks [

Guideline 3: Identifying and Involving Co-design Facilitators
Interviewees emphasized the critical role of facilitators. In mHealth, co-designing involves high stakeholder diversity (eg, app developers, health practitioners, and health insurance providers) while simultaneously addressing highly intimate issues and concerns regarding a person's health (eg, quitting smoking and diabetes self-management). Against this backdrop, the facilitator plays a critical role in involving stakeholders in a trusted, meaningful, and effective way.
Neglecting the role of the facilitator yields a range of risks, including a lack of true involvement (eg, because of power distance between end users and health professionals) and a lack of understanding about end users' lived experiences and perspectives:

We were a little bit disconnected from knowing what it truly means to struggle with [an] addiction that you want to give up and you know is bad for you [...]. All these issues are quite emotional and unless you understand how it really feels I think it is important for whoever is running the workshop [to] have a feel for the topic, a knowledge of what it means. [MSD6]
To address potential challenges (eg, power distance and lack of empathy), interviewees emphasized that co-design facilitators need an authentic understanding of end users' real-world experiences (eg, through first-hand experience, immersing in problem context, and consulting relevant literature). Facilitators are then able to operate in a more empathetic way, which can help participants feel more comfortable sharing personal experiences regarding their own health. For example, MSD6 stated that facilitators in their smoking cessation project had personal experience with the context. On the basis of ice-breaking exercises, the authentic experiences of the facilitators enabled them to support stakeholders in becoming more comfortable to actively engage with co-design activities. As a result, the facilitators were perceived as more like co-design participants than authority figures. Empathy, or a "soft human touch" (CME4), is a critical skill for a facilitator running co-design workshops to overcome the inherent power distance issue in the mHealth space:

Guideline 4: Immersion Into the mHealth Ecosystem
Co-design involves the effective collaboration of system designers with users and other stakeholders. Frequently raised elements include (1) the importance of being immersed in the context where stakeholders are, for optimal problem identification; (2) identification of relevant stakeholders as early as possible to drive their own involvement and contribute to the study design, including ethics approval; and (3) the need for an ongoing relationship with stakeholders in mHealth that recognizes the power distance between stakeholders and prioritizes the needs of end users.
The multiplicity of factors affecting and supporting a person's health renders the environment of mHealth system design inherently complex. Interviewees repeatedly stressed the need for system designers to immerse themselves deeply to effectively identify stakeholders, understand pain points and relationships with one another, and correctly determine the problems they can and cannot address: Another important aspect relates to involving stakeholders as early as possible because failing to do so is particularly critical, and possibly fatal, in the realm of mHealth. First, because of the array of factors around a person's health, the number of potential stakeholders is high, which requires buffer times for planning, organizing, communicating, and scheduling. Second, the health sector naturally encompasses complex policies and procedures to adhere to privacy regulations and protect and support vulnerable populations. It is therefore vital for stakeholders to become involved sufficiently early to be able to point out procedural constraints in their domains (eg, requirements and time frames for ethics approvals): Support for positive health outcomes is an ongoing process. It follows that the relationship with stakeholders of mHealth systems design needs to be managed and supported in an ongoing way. Although this holds true for both health promotion and disease management, it is particularly critical in the disease management space. It is also critical to balance the number of participants involved in co-design activities and avoid a potential power imbalance geared toward senior medical practitioners. The resulting power distances between the stakeholders must be carefully considered. After all, the person most affected by the system will be the end users and, hence, it is vital to adequately capture and address their needs: The problem should really be generated in part by the people who are affected when it has something to do with health management. [

Guideline 5: Identifying and Involving Postdesign Advocates
Interviewees repeatedly stressed the challenge of implementing and rolling out mHealth systems. This is linked to the complexity and risk of processes in the health sector and the multitude of stakeholders who need to work together effectively. Against this backdrop, we identified the importance of postdesign advocates as an important theme. CME1 described postdesign advocates as "end-users who are really interested in what you are doing, how you are doing it, and what it could mean for them." MSD7 elaborates that postdesign advocates are the "people behind it that are going to drive, push, and refer patients or their communities to [the mHealth system]." Identifying postdesign advocates is critical for system designers to support the implementation and postdesign of the mHealth system.
Postdesign advocates need to be stakeholders who are well-connected and respected in the application context. By actively involving them early in the co-design process, their contributions can already be considered in the predesign and generative phases. This establishes a "buy-in" of stakeholders that can later assist in championing the system in the implementation and postdesign phases with the people and communities who are going to use the system. In this way, identifying postdesign advocates can mitigate many challenges in mHealth, including integration into clinical practice and collecting data in the postdesign phase: Beyond the technical aspects of the designed system, interviewees argued that the integration into the complex processes and the various stakeholders in the health space renders the implementation and rollout of the system exceptionally challenging. Postdesign advocates can be critical to informing and supporting the implementation of the mHealth system in the real world. If health practitioners do not believe that the system will be useful, they will not promote it to their patients and may actively dissuade use: If they were not taught how to use [the app] properly, if they were not given the right support materials, or if it did not get to the right people because the people who did the roll out of it were not briefed well enough around the sorts of people we want it to go to, even if it was really beautifully designed, then it would have failed. So, I am talking about the wraparound services of the thing.
We talk about champions, you have got to have people behind it that are going to drive it and push it. They are going to refer patients or their communities to it, or they are going to support services to use these tools Finally, another reason for involving postdesign advocates is that stakeholders in practice are essential to measuring the impact of the mHealth system once it has been implemented in the real world (eg, based on usage data) and being available for follow-up co-design activities in the postimplementation phase (eg, postdesign interviews) to make sense of the usage data:

Guideline 6: Applying Health-Specific Evaluation Criteria
The evaluation of mHealth systems requires additional considerations compared with other contexts because of the intended and possibly unintended effects of the artifact on people's health. The main elements uncovered from the interviews were as follows: (1) the risks and ethical issues associated with developing solutions in a health care context and (2) the need for feasibility testing in the real world (eg, clinical trials and pilot-testing), before implementation, to ensure that the mHealth system accomplishes what it set out to do and does not pose a risk to the end users.
Interview participants emphasized that because of the focus on people's health, there are additional risks and ethical considerations when co-design mHealth systems for a health care context. For example, MSD1 elaborated:

Even though your interruption through technology might end up with things being better, you still have to be very conscious of the fact that there is more at stake if anything goes wrong because I would not want to be involved in a technology that made things more complicated for people who are already in a complicated and stressful situation. [MSD1]
To navigate these risks, it is important to ensure that an mHealth system goes through feasibility testing such as pilot-testing and randomized controlled trials in the real world so that it can be established that the mHealth system accomplishes its goals and does not pose a risk to the end users: You need a randomized controlled trial of the app first, so that is in the evaluation phase, not the implementation phase, to then prove that it increases patient outcomes and then they might adopt it. [MSD2] MSD8 further explained that it is important to understand that there are different levels of feasibility testing that pertain to the quality of the test and the cost to run the test. For example, MSD8 recommended performing pilot-testing before conducting randomized controlled trials for these reasons: We would never as a health researcher or a health clinician move straight into a randomized controlled trial without pilot data first [...]. In terms of costings, randomized control trials are much more expensive to run and they are the gold star or grade one evidence [MSD8] MSD1 adds that feasibility testing is not only important for ensuring that the mHealth system works and poses no risk to end users. Owing to the extensive costs of upkeep after implementation, finding problems during feasibility testing is beneficial because they can be fixed by re-entering the earlier co-design phases. Thereby, some problems are more likely to be found because testing is performed in a real-world setting:

Guideline 7: Collecting and Analyzing Usage Data to Understand Impact
The final theme focuses on the importance of postdesign. CMEs noted that even though postdesign is important to assess the impact of artifacts in the real world [13], this step is frequently not carried out because of time and cost constraints. However, the postdesign phase is especially important in the mHealth context because impact is driven by changes in health behavior [10], and mHealth systems are intended to be used over extended time spans (eg, diabetes self-management). Hence, mHealth systems must be updated to meet changing user needs: I think post-implementation and the collection of evidence of the impact of that change is absolutely essential because you are talking about people changing their behavior for better health outcomes" All apps need to be updated, and one of the biggest issues with health apps is they are not. [MSD7] In addition, interviewees explained that mHealth is in a unique position to measure this impact because of having access to participant usage data from the mHealth system because of their ability to collect usage data. Thereby, it is important that qualitative co-design methods (eg, postdesign interviews) are used to make sense of this participant usage data:

General Discussion
Although extensive research exists on co-design methodology and its general application, limited research has examined the complexities that arise in co-designing mHealth systems. This study aimed to (1) contextualize an existing co-design framework for mHealth and (2) develop guidelines for addressing common challenges. From the 16 interviews conducted with CMEs and MSDs and thematic analysis, we contextualized the co-design framework by Sanders and Stappers [13] to the mHealth context and constructed a set of 7 guidelines.
We identified several important aspects from contextualizing the Sanders and Stappers [13] co-design framework. First, it became apparent that some of the co-design phases should be split up. Although the original framework has an overall generative phase, a separate prototyping phase was suggested for mHealth to distinguish between the generation of early concepts (eg, low-fidelity prototyping) in the generative phase compared with the testing of more mature concepts where maturity is higher (eg, high-fidelity prototyping). Furthermore, a dedicated implementation phase distinguishes activities performed during evaluation (eg, pilot-testing and randomized controlled trials) versus implementation (eg, creating documentation, training, and user acceptance). Second, mHealth has its idiosyncrasies regarding the front-end of co-design, including the importance of researchers immersing themselves in the complex problem context and diverse stakeholder landscape surrounding a person's health. Furthermore, this diversity of stakeholders can lead to a power distance issue in the generative phase. Therefore, it is important to recognize the vulnerability of mHealth end users and their relationships with other stakeholders that could impede participation. The evaluative phase is also affected, as mHealth problems are typically riskier compared with other contexts. Thus, pilot-testing and randomized controlled trials were mentioned by interviewees as suitable evaluation methods for mHealth. Finally, the postdesign phase plays a specific role in mHealth because of its intended effects on health behavior. However, this cannot be assessed until the system is deployed. Hence, the postdesign phase is necessary to understand this impact on user behavior and to allow for continued monitoring and maintenance.
Addressing the second research objective, seven guidelines were synthesized for applying co-design to mHealth (labeled guideline 1 to guideline 7). As shown in Figure 3, the guidelines pertain to the specific phases of the co-design process. Emphasizing the importance of the front end of co-design, guideline 1 to guideline 4 focus on ensuring that researchers and practitioners establish an intimate understanding of the problem context as early as possible. Interviewees noted that, by following these steps, common challenges such as stakeholder identification, power distance, and lack of trust can be addressed effectively. For instance, by immersing oneself in the mHealth problem context (guideline 4), researchers and practitioners can better understand how end users interface with stakeholders in their health ecosystem, aiding in stakeholder identification. Guideline 5 maps to all phases in the framework as (postdesign) advocates (ie, users championing the system) can be identified in any phase. Interviewees noted that these advocates can help mitigate many issues that can potentially surface in the implementation phase, for instance, by championing the system themselves and by training others. Next, guideline 6 maps to the evaluative phase and emphasizes the importance of health-specific evaluation (eg, pilot-testing and randomized controlled trials) given the high-risk nature of mHealth challenges. Finally, guideline 7 maps to the postdesign phase to ensure that the impact is measured post implementation along with contextual research that informs further system refinements. Beyond phase-specific relevance, there is also an important interplay between the guidelines. First, guidelines 1, 2, and 4 are linked to 3 because a deep understanding of the problem context is needed to effectively apply guideline 3 (highlighting the importance of the front-end of co-design in mHealth). Without this, many of the challenges identified by the interviewees (eg, power distance, lack of trust, and accessibility of tools and methods) would compromise later co-design phases. Second, there is a link between guideline 1/guideline 2 and guideline 6/guideline 7. Guideline 1 and 2 primarily focus on understanding the problem context and establishing the desired goals of the mHealth system, while guidelines 6 and 7 refer to the evaluation of how well the mHealth system addresses these goals, both pre-and postimplementation. Finally, there is a link between guidelines 5 and 7 since the identified advocates will invariably be needed to understand the impact of the mHealth system in the real world.
There were key differences and similarities between the responses of CMEs and MSDs, with implications for the results presented in this paper. First, the interview guide acknowledged the differing nature of expertise between the CME and MSD groups to elucidate the experts' specific domain knowledge (Multimedia Appendix 2). For instance, questions for CMEs primarily referred to co-design in a general sense, which tapped into their expertise in co-design applications, processes, phases, methods, and tools. Conversely, questions for MSDs focused on how co-design manifested in their own projects, which led to more specific responses about the contextualization of co-design to mHealth (challenges they had faced, how they involved mHealth stakeholders, benefit of co-design to their project, etc). The groups expressed similar considerations around the challenges and benefit of co-design, since cost and time constraints are typically common factors in co-design processes, regardless of the context. There was general between-group consensus regarding the aspects that would inform the derivation of guidelines and the contextualization of the framework. Overall, the responses from CMEs tended to refer to general considerations around applying co-design to a complex area, whereas the responses from MSDs were more specific to challenges and best practices based on experience from actual mHealth projects.

Implications
This work has several important implications for researchers and practitioners. First, building on the extensive expertise of CMEs and MSDs who participated in this research, the contextualized framework may provide a shared frame of reference to guide mHealth systems development projects, which are interdisciplinary in nature [5,6]. Rooted in the widely used co-design framework by Sanders and Stappers [13], the contextualized framework brings to light a range of critical considerations that arise in the health context. As a shared frame of reference, the contextualized framework may aid mHealth researchers and practitioners in planning co-design activities and involving stakeholders in all stages of design [1,6]: Complementary to the framework, the guidelines point to pitfalls in mHealth systems development along with specific suggestions on how these challenges can be navigated. Multimedia Appendix 5 provides a checklist for co-designing mHealth systems projects according to the 7 guidelines. By facilitating stakeholder engagement and involvement in co-design activities, these guidelines may help researchers and practitioners to ensure that mHealth systems are underpinned by expert insight, reflect the lived experiences of end users, and integrate into the existing system and process landscape [5,11]. In so doing, co-designed mHealth artifacts may enable end users and health professionals to develop a stronger sense of ownership and agency over the outcome. Researchers and practitioners can actively engage postdesign advocates to assist in increasing buy-in from stakeholders, overcoming barriers, and championing the system's implementation and use.

Limitations and Opportunities for Future Research
This study had some limitations. First, it should be noted that most of the interviewees resided in the Oceania region and/or were working within the academic sector. Future research may bring to light potential differences in co-design between industry and academia as well as geographical differences related to cultural factors (eg, uncertainty avoidance and power distance [58]). Second, while our research builds on the expertise of the interviewed experts beyond the scope of an individual mHealth system, future research is warranted on the usefulness of the contextualized framework and guidelines for the development of actual mHealth systems. Importantly, this evaluation and refinement should also include the perspectives and lived experiences of individuals involved as co-designers in the context of a specific mHealth system. This was beyond the scope of this study, as we considered mHealth system design beyond the scope of a specific mHealth systems development project. Third, because the current focus is on the co-design process as a whole, it was beyond the scope of this study to assess the applicability of specific co-design methods for mHealth (eg, cultural probes and journey maps). Future research needs to investigate the usefulness and boundary conditions of individual co-design methods in mHealth. This would have the potential to illuminate specific activities that can assist in stakeholder engagement and impact determination in the long run.

Conclusions
With the focus of supporting positive health outcomes, researchers and practitioners encounter unique challenges in mHealth systems development. Following a constructivist approach, we interviewed 16 experts in co-design methods and mHealth systems development to contextualize an established co-design framework for the mHealth setting and to construct a set of tangible guidelines to address common challenges in this space. While contextualization emphasizes the need to include dedicated prototyping and implementation phases, the guidelines provide practical insights on how to engage in this process by (1) understanding stakeholder vulnerabilities and diversity, (2) planning for and assessing health behavior change, (3) identifying co-design facilitators, (4) immersing in the mHealth ecosystem, (5) identifying postdesign advocates, (6) applying health-specific evaluation criteria, and (7) analyzing usage data and contextual research to understand impact. We hope that the contextualized framework and guidelines presented in this work will serve as a shared frame of reference to facilitate interdisciplinary collaboration at the nexus of information technology and health research.