Using Co-Design in mHealth Systems Development: A Qualitative Study with Experts in Co-design and mHealth System Development

Background: The proliferation of mobile devices has enabled new ways of delivering health services through mobile health systems. Researchers and practitioners have emphasized that the design of such systems is a complex endeavor with various pitfalls, including limited stakeholder involvement in design processes and integration into existing system landscapes. Co-design is an approach to address these pitfalls. Despite a rich body of literature on co-design methodologies, limited research exists to guide the co-design of mHealth systems. Objective: The objectives of our study was to (1) contextualize an existing co-design framework to mHealth applications and (2) derive guidelines to address common challenges of co-designing mHealth systems. Methods: We conducted an exploratory qualitative study consisting of 16 semi-structured interviews with co-design method experts (8) and mHealth system developers (8). Data were analyzed using thematic analysis. Results: The contextualized framework captures important considerations of the mHealth context, including dedicated prototyping and implementation phases. Additionally, seven guidelines were developed: (1) specificity of targeted mHealth context, (2) immersion in mHealth context, (3) health behavior change, (4) co-design facilitators, (5) post-design advocates, (6) health-specific evaluation criteria, and (7) usage data and contextual research to understand impact. Conclusions: System designers encounter unique challenges when engaging in mHealth development. We hope that the contextualized framework and guidelines will serve as a shared frame of reference to facilitate interdisciplinary collaboration at the nexus of information technology and health research.


Preprint Settings
1) Would you like to publish your submitted manuscript as preprint?Please make my preprint PDF available to anyone at any time (recommended).
Please make my preprint PDF available only to logged-in users; I understand that my title and abstract will remain visible to all users.Only make the preprint title and abstract visible.No, I do not wish to publish my submitted manuscript as a preprint.2) If accepted for publication in a JMIR journal, would you like the PDF to be visible to the public?
Yes, please make my accepted manuscript PDF available to anyone at any time (Recommended).
Yes, but please make my accepted manuscript PDF available only to logged-in users; I understand that the title and abstract will remain v Yes, but only make the title and abstract visible (see Important note, above).I understand that if I later pay to participate in <a href="http

Introduction
The proliferation of mobile devices (e.g.smartphones, tablets) has enabled new ways of delivering health services via mobile health (or 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], p.6).The ubiquity and increasing capabilities of these systems have created enormous potential to support individuals in self-managing existing health conditions (e.g., diabetes, stroke) as well as reducing their health risks by supporting healthier lifestyle habits (e.g., increasing vegetable intakes).
Adoption of mHealth systems is steadily growing.In 2018, nearly half of consumers in healthcare used mHealth systems compared to one sixth in 2014.Overall, the global mHealth market is expected to grow from US$28.320b in 2018 to US$102.35b 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], p.6). Research has referred to two main reasons for using co-design: (1) mHealth is a complex environment which requires involvement of diverse stakeholders (e.g., consumers/end-users, government, health practitioners, scientists, software developers) with codesign facilitating necessary collaborations (e.g., [1,9,10]); (2) using co-design ensures that mHealth systems are underpinned by expert insights and best practices (e.g., [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.Existing literature on co-design methodology provides important general guidance in the application of co-design frameworks and methods (e.g., [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 codesign 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.
In the current paper, we set out to 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 semi-structured interviews to synthesize the theoretical and practical expertise of eight co-design method experts (CMEs) as well as eight 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 the current study were (1) to contextualize an existing co-design framework to 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.Firstly, disease management empowers patients to manage their medical conditions more effectively and independently (e.g., control blood sugar levels; [18,19]).Secondly, health promotion facilitates better health choices, by providing support and encouragement for users to engage in behaviors to lower risk factors and improve health (e.g., better diet, 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 and colleagues discussed a user-centered design approach to mHealth systems development [20].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], p.3).However, it needs to be noted that user-centered design adopts an expert perspective where "trained researchers observe and/or interview largely passive users" ([8], p. 5).By 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], p. 12).Banos and colleagues developed an architecture that showed how specific functionalities and components of mHealth systems could be implemented [22].Building on usercentered design, Schnall and colleagues developed a three-cycle framework (relevance, design, and rigor) to better incorporate end-users' preferences [23].Eckman and colleagues developed a mHealth systems framework that considers design thinking principles, using "a hypothesis-driven method of generating and validating new concepts" ([1], p.424).Nahum-Shani and colleagues explored how one can design just-in-time adaptive interventions to support users' health behavior change [24].However, there has been limited focus on how to specifically apply a co-design approach that involves stakeholders within the mHealth context.

Co-design Frameworks
Researchers have proposed several frameworks to facilitate co-design (e.g., [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, 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], p.7).For instance, the framework by Visser and colleagues structured the co-design process into five phases of preparation, sensitization, sessions, analysis, and communication [14].Brandt and colleagues described an iterative cycle of making, telling, and enacting [25].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 four interconnected phases (see Figure 1).
1.The Pre-design 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 (e.g., journey maps, mock-ups, 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], p.10). 3. The Evaluative Phase allows users to assess 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], p.6). 4. The Post-design Phase captures the notion that once a system is part of users' lived experiences, it needs to evolve along with their needs, habits, and use patterns.Hence, "the tail end of the post-design phase [leads] to the front end of another design process" ( [13], p.10).

Methods
In this research, we adopt 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 dialogue between researchers and the research participants ( [51], p.55).

Research Participants
We used a purposive sampling method to identify and recruit participants from two groups for interviews, namely Co-design Method Experts (CMEs) and mHealth System Developers (MSDs).CMEs were recruited online using Google, Google Scholar, LinkedIn, Twitter, and ResearchGate to identify experts in co-design (e.g., book authors, academics, consultants).The MSD group was recruited by searching papers and reports by authors with co-design experience in mHealth.Interviewees had to be at least 18 years old and fluent in English.Individuals were contacted by the first author via email with a study information statement before obtaining written informed consent to participate.Participation was entirely voluntary and did not involve any monetary reward or other compensation.
Ethics approval was granted by the ethics committee at the University of Newcastle, Australia (H-2019-0064).Data collection and analysis were carried out concurrently.The recruitment process continued until data sufficiency was reached (i.e., existing categories managed new data without further modifications [53]).The final dataset includes 16 interviews (8 CMEs, 8 MSDs).On average, CMEs had over 15 years of publication experience (min: 2 years, max: 25 years) in areas such as codesign/participatory design, co-creation, design thinking, generative design research, and design research methods.On the other hand, MSDs had over 8 years of publication experience on average (min: 4 years, max 28 years) in the mHealth literature spanning across multiple areas in disease management (cancer, heart failure) and health promotion (smoking cessation, nutrition).All interviews were audio-recorded (total duration: 14 hours, 15 minutes) and transcribed by the first author.Interview length was between 36 and 72 minutes.Appendix 2 provides details on research participants' backgrounds and experience.

Data Collection
Data was collected between July 2019 and January 2020.Before the interview, 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 video conferencing as per the interviewee's preference.The interviews were of a semistructured 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 interview guide in Appendix 1).Open-ended questions gave the interviewees opportunities to speak freely and to guide the discussion in directions of interest.

Data Analysis
The first author coded the transcripts following the procedure of Braun and Clarke [15], which includes 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 re-reading the transcripts (i.e., prolonged engagement).In Step 2, the first author performed initial coding in NVivo.The second author then checked these codes and validated them against the transcripts.Initially, we identified 154 codes from all the interviews (e.g., power distance, vulnerability).In Step 3, the first and second author clustered nodes to 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 the framework contextualization and guideline development.In Step 5, the authors further refined the guidelines by eliminating redundant themes and naming the guidelines.The first extension is the inclusion of a dedicated implementation phase.Interview participants noted that it 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 roll-out of the system into a complex mHealth ecosystem.

"You would not naturally do a clinical trial or a randomized control trial in your implementation phase because you first need to be able to test the feasibility." [MSD8]
"The implementation phase is after we have done the research and probably after we have analyzed the results and come to some kind of conclusions.So, there is a gap then between the generative phase and the implementation phase when we actually do our research.We are checking to make sure that we have got evidence now that would suggest that this is actually going to support people improve their health outcomes.That is your evaluative phase.Let's now go to the implementation phase where we actually deploy it.

" [MSD5]
By contrast, a dedicated implementation phase should focus on facilitating the integration of mHealth artifacts into the complex system and stakeholder environment.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 getting key stakeholders involved in the rollout (see post-design 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.

"You would want implementation to be on the agenda right from the initial co-design process. You need to have a plan. If you are going to co-design something, you need to have a plan that if it is effective, how could it be brought about, and those discussions or those people involved in that process. […] Having those people involved from the start is fundamental to the success of implementation, and having plans around that." [MSD7] "You really need to work with the [health system] and that is where that whole implementation phase becomes crucial because even if your thing is beautiful, if it does not have the support to make it work, it will fall down." [MSD3]
The second extension pertains to a separate prototyping phase before the evaluative phase to acknowledge the complexity of mHealth artifacts and their evaluation requirements (e.g., pilot testing, randomized control trials).Including a separate prototyping phase assists in separating generative co-design methods in the generative phase (e.g., paper prototyping), from instantiations in which the idea for the solution has become more mature and where (high fidelity) prototyping occurs (i.e., hardware and software prototypes).Further, 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 (e.g., pilot testing and randomized control trials).Additionally, separating the prototyping and evaluative phases can make it clearer which stakeholders should be involved in which phase and in what capacity they should be involved (e.g., 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.)Lastly, 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 (e.g., health practitioners, designers, etc.) in one place (e.g., a co-design workshop in a studio or lab) to engage in generative co-design methods (e.g., storyboarding, 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: "Maybe they cannot get there.Maybe socially it is a challenge for them.Maybe you do engage with those people one-on-one, and then bring things together later.So, an interview, or user testing, or even a digital engagement where you are putting something online and getting some feedback.

" [CME6]
Hence, for co-design to be accessible to end users, generative engagement does not necessarily need to occur in the presence of all the stakeholders or in the same physical space.For example, Smeenk et al describe an empathic handover approach where 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 requires 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, one may carry out interviews or observations in a hospital to get 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 post-design phases.

"I think a really important part of that was the fact that we were working on-site" [MSD1]
"We position ourselves in the context by submerging ourselves in all the relevant stakeholders" [MSD8]

Guidelines for Co-Designing in mHealth
Based on the thematic analysis of the interviews, we constructed seven guidelines (G1-7) to address challenges in co-designing mHealth systems.Appendix 4 provides a detailed overview of example quotes.

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 (to be) involved stakeholders, 3) the significance of evaluation, and 4) the actual implementation and translation.Due to the focus on health outcomes, mHealth typically involves vulnerable user groups (users with health conditions which may create additional barriers to participation, e.g., patients).
While this vulnerability may be present in some groups within health promotion (e.g., smoking cessation, alcohol reduction), it appears to be most prevalent among the disease management cohort (e.g., dementia, autism, etc.)This vulnerability creates challenges for (1) recruiting representatives from the target cohort and (2) being mindful of their health vulnerabilities.

"The first thing that comes to mind [challenge] is getting access to participants. It is really impossible in healthcare. […] It might be really hard to get people to open up and be honest about their experiences of having a stoma bag […]. It is just not a subject that ever gets discussed with family members around. [You] can talk to patients one-on-one maybe, but [not] with all their family around them." [CME2]
With the specific focus of supporting positive health outcomes, the co-design process inherently touches on vulnerable, deeply personal aspects which, in turn requires high levels of trust in the research team and process.It is hence vital to select co-design tools and methods that are appropriate in this context and allow vulnerable end-users to participate to the best of their capabilities.
"I knew from experience what it was like to be with someone who has this disease, and that made it easier because I already knew the context, because then you know how to behave.I think for people who are not familiar with that, they must be acquainted with that first."

[CME3]
"One [challenge] is a lack of trust.
[…] It happens with government led and funded projects where people who may have had a lifetime of being let down by organizations and institutions and they may find it difficult to trust that their voice will really be heard and that things will really change because of their participation.

" [CME6]
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 be also more than one category of end-users such as both the patient and the health practitioner, with differing requirements in terms of evaluation.

"You have got app designers, [marketing people, health professionals], and you have got the end-users who are trying to grapple with their medical challenges that they have. […] That would be one of the biggest challenges, getting those people together." [MSD5]
The last element of this guideline is the integration of mHealth tools into the 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 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: Planning for and assessing health behavior change
The second theme refers to the importance of consulting the behavior change literature and, consider directly involving behavior change experts in the co-design process.Overall, the importance of consulting the behavior change literature was mentioned in nine of the interviews (4 CMEs, 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 (see [55] for a review).
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 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.
"You have to engage in the behavior change literature […].A health practitioner probably knows that there is behavior change literature to go to, but someone outside that health domain may not know to go to that literature.

" [MSD8]
MSD6 elaborated that a key distinguishing factor between mHealth and other contexts is that codesigning mHealth systems is linked to changes in behavior that are often deeply personal to the endusers, that are linked to deeply-embedded long term habits (e.g.eating, physical activity, sleep patterns): "You are talking about changing behaviors that are there for a reason.

They are not just trivial behaviors, they are deeply embedded and they have really unusual reasonings that […] surprise you. Whereas if you are just designing a booking system or whatever, it is not that emotive." [MSD6]
Finally, given the focus on mHealth systems on achieving positive health outcomes, it is vital to carefully tailor the co-design activities to the individual circumstances and capabilities of the stakeholders, and in particular the end-user.

"Co-design frameworks [are] very focused on picking a series of methods for a workshop, and then saying, 'okay participants, I all want you to do this method using these kinds of materials.' [This] is just completely unfeasible when you have people with only one hand […]. Co-design […] for healthcare […] does have to be approached differently." [CME2] 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: Identifying and involving co-design facilitators
Interviewees emphasized the critical role of facilitators.In mHealth, co-designing involves high stakeholder diversity (e.g., app developers, health practitioners, health insurance providers) while at the same time addressing highly intimate issues and concerns regarding a person's health (e.g., quitting smoking, diabetes self-management).Against this backdrop, the facilitator takes 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 (e.g.due to power distance between end-users and health professionals) and a lack of understanding about end-users lived experiences and perspectives.

"I think that power balance is particularly interesting in healthcare because it is really hard to say that you do not agree [with] a doctor. […] They are held up in such high esteem as being experts of the subject matter […]. So, to then put-up patients in a room [saying] 'codesign with your doctors', it could be really confronting to [say] 'oh I have a different opinion to you and I do not usually get to express it in my experiences with you, but now can I?'" [CME2] "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 (e.g., power distance, lack of empathy), interviewees emphasized that co-design facilitators need an authentic understanding of end-users' real-world experiences (e.g. through first-hand experience, immersing in problem context, consulting relevant literature).
Facilitators are then able to operate in a more empathetic way which can help participants feel more comfortable about sharing deeply personal experiences regarding their own health.For example, MSD6 stated that the facilitators in their smoking cessation project had personal experience with the context.Based on ice-breaking exercises, the authentic experiences of the facilitators enabled them to support stakeholders in becoming more comfortable to actively engage with the co-design activities.As a result, the facilitators were perceived more like co-design participants than authority figures.Empathy, or a "soft human touch" (CME4), is a critical skill for a facilitator running codesign workshops to overcome the inherent power distance issue in the mHealth space.

"I think the more practical power distance issues in sessions can be easily navigated if you just have a bit of a soft human touch to ensure that people do not feel like you are the cocky arrogant researcher, expert, designer, or however you are positioning yourself." [CME4]
"There is comfort that comes from people who are like you.

[This] is why I saw the two [facilitators] being so successful with the low self-esteem kids because they themselves started the session talking about their problems. The designers running the session were able to talk about their experiences and how they dealt with it and so then they immediately became not the person leading the co-design activity, but a true co-designer." [MSD6]
Guideline 3 Select and engage co-design facilitators that have an authentic understanding of the intimate problem context (e.g., first-hand experience, immersing in problem context, literature consultation), and operate in an empathetic way to mitigate potential barriers associated with the power distance between mHealth stakeholders.

Guideline 4: Immersion into the mHealth ecosystem
Co-design involves an effective collaboration of system designers with users and other stakeholders.
Frequently raised elements included 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.
"You do have to be embedded in the space in order to identify it, or you have to be listening to people who are embedded in the space in order to identify it.

was around interviewing all different types of stakeholders individually to try and understand what their experiences are, what their frustrations are, what their behaviors and pain points are, what they really struggle with." [MSD2]
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, due to 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 hence vital for stakeholders to be become involved sufficiently early to be able to point out procedural constraints in their domains (e.g., requirements and time frames for ethics approvals).

"I would say involve them right from the start. […] Ascertain to what extent they are going to be able to contribute any of their time […] and ask them what stage they think they want to be involved […] and let them drive that process." [MSD5] "The best way to manage the different stakeholders and the management is at different stages [to] highlight the appropriate stakeholders that are necessary and let them know what their voice is and what their purpose is. Basically, letting stakeholders know when their input is important and needed and what the reason for their input is." [CME8]
Supporting positive health outcomes is an ongoing process.It follows that also the relationship with stakeholders of mHealth systems design needs to be managed and supported in an ongoing way.While 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 codesign activities and avoid a potential power-imbalance that is geared towards senior medical practitioners.The resulting power distances between stakeholders must be considered carefully.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. […] There must be more of an ongoing relationship [with end-users] even if there is not a particular problem yet." [MSD1]
"I get really concerned when I see just one or two people with lived experience brought on as kind of the token users to a predominantly professional group and you just think how can those people feel confident and comfortable in that setting, especially in a health context where they are used to being told by the professionals.

" [CME6]
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: Identifying and Involving post-design advocates
Interviewees repeatedly stressed the challenge of implementing and rolling out mHealth systems.This is linked to the complexity and risk of processes in health sectors, and the multitude of stakeholders who need to effectively work together.Against this backdrop, we identified the importance of post-design advocates as an important theme.CME1 described post-design 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 post-design advocates are the "people behind it that are going to drive, push, and refer patients or their communities to [the mHealth system]".Identifying post-design advocates is critical for system designers to support the implementation and post-design of the mHealth system.
Post-design 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 pre-design and generative phases.This establishes a "buy-in" of stakeholders that can later assist in championing the system in the implementation and post-design phases with the people and communities who are going to use the system.In this way, identifying post-design advocates can mitigate many challenges in mHealth, including integration into clinical practice and collecting data in the post-design phase.

"Implementation of mHealth tools is extraordinarily challenging […]. There are a lot of barriers of getting things into practice and getting that buy-in from communities […] can actually aid your implementation because they have already bought in. Because they are invested in it, they are more likely to try and help make it happen." [MSD7]
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.Post-design advocates can be critical to informing and supporting the implementation the mHealth system in the real world.If health practitioners do not believe that the system is going to 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.

" [MSD3]
"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" [MSD7] Lastly, another reason for involving post-design advocates is that stakeholders in practice are essential to measuring the impact of the mHealth system once it has been implemented into the real world (e.g., based on usage data) and being available for follow up co-design activities in the postimplementation phase (e.g., post-design interviews) to make sense of the usage data.

"You will find some end-users in this process who are really interested in what you are doing and how you are doing it and what it could mean for them. Those are the kind of people who might become your post-design advocates who would collect this data for you and at a reasonable price because they have a vested interest in seeing how it worked and helping other people manage their lives for example. So, you could build it into the whole process." [CME1]
Guideline 5 Throughout every phase of co-design, identify potential post-design advocates from different stakeholder categories who can aid in implementing the mHealth system (e.g., training staff in the use of the system) and championing its usage in the post-design phase (e.g., providing feedback on system usage in practice).

Guideline 6: Applying health-specific evaluation criteria
The evaluation of mHealth systems requires additional considerations compared to other contexts due to both intended and possibly unintended effects of the artifact on people's health.The main elements uncovered from the interviews were: 1) the risks and ethical issues associated with developing solutions in a healthcare context, and 2) the need for feasibility testing in the real world (e.g., clinical trials, pilot testing), before implementation, to ensure the mHealth system accomplishes what it set out to do and does not pose a risk to the end-users.
Interview participants emphasized that due the focus on people's health, there are additional risks and ethical considerations when co-design mHealth systems for a healthcare context.For example, MSD1 elaborates: "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 control 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 doing randomized control 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 making sure that the mHealth system works and poses no risk to end-users.Due 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 due to testing being done in a real-world setting: "You need to do it in stages, especially because there is such a massive cost involved in terms of the upkeep of apps […].If you can have a prototype, it is not just about testing the prototype, it is also about testing how the prototype works in the real world before you turn it into the end product" [MSD1] Guideline 6 In the evaluative phase, ensure that the mHealth system goes through feasibility testing in the real world (pilot testing and randomized control 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: Collecting and analysing usage data to understand impact
The final theme focusses on the importance of post-design.CMEs noted that even though postdesign is important to assess the artifact's impact in the real world [13], this step is frequently not carried out due to time and cost constraints.However, the post-design 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 (e.g., 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." [CME7]
"All apps need to be updated, and one of the biggest issues with health apps is they are not."

[MSD7]
Additionally, interviewees explained that mHealth is in a unique position to measure this impact due to having access to participant usage data from the mHealth system due to their ability to collect usage data.Thereby, it is important that qualitative co-design methods (e.g., post-design interviews) are used to make sense of this participant usage data.Guideline 7 In the post-design phase, collect usage data to observe the mHealth system's impact after it has been implemented and apply contextual codesign methods to understand this impact.

General Discussion
While extensive research exists on co-design methodology and its general application, limited research has examined the complexities that arise in co-designing mHealth systems.The current study aimed to (1) contextualize an existing co-design framework to 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 seven guidelines.
We identified several important aspects from contextualizing Sanders and Stappers's [13] co-design framework.First, it became apparent that some of the co-design phases should be split up.While the original framework has an overall generative only phase, a separate prototyping phase was suggested for mHealth to distinguish between the generation of early concepts (e.g., low-fidelity prototyping) in the generative phase compared to the testing of more mature concepts where maturity is higher (e.g., high-fidelity prototyping).Further, a dedicated implementation phase distinguishes activities performed during evaluation (e.g., pilot testing, randomized control trials) versus implementation (e.g., creating documentation, training, 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.Further, 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 to other contexts.Thus, pilot testing and randomized control trials were mentioned by interviewees as suitable evaluation methods in mHealth.Lastly, the post-design phase plays a specific role in mHealth due to its intended effects on health behavior.However, this cannot be assessed until the system has been deployed.The postdesign phase is hence 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 (labelled G1 to G7).As shown in Figure 3, the guidelines pertain to specific phases of the co-design process.Emphasizing the importance of the front-end of co-design, G1 to G4 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 (G4), researchers and practitioners can better understand how the end-users interface with stakeholders in their health ecosystem, aiding in stakeholder identification.G5 maps to all phases in the framework as (post-design) advocates (i.e., 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, G6 maps to the evaluative phase and emphasizes the importance of health-specific evaluation (e.g., pilot testing, randomized control trials) given the high-risk nature of mHealth challenges.Lastly, G7 maps to the post-design phase to ensure that the impact is measured post-implementation along with contextual research that informs further system refinements.Beyond the phase-specific relevance, there is also an important interplay between the guidelines.First, G1, G2, and G4 are linked to G3 because a deep understanding of the problem context is needed to effectively apply G3 (highlighting the importance of the front-end of co-design in mHealth).Without this, many of the challenges identified by the interviewees (e.g., power distance, lack of trust, accessibility of tools and methods) would compromise later co-design phases.Second, there is a link between G1/G2 to G6/G7.G1 and G2 primarily focus on understanding the problem context and establishing desired goals of the mHealth system while G6 and G7 refer to the evaluation of how well the mHealth system addresses these goals, both pre-and post-implementation.Lastly, there is a link between G5 and G7 since the identified advocates will invariably be needed for understanding 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 these experts' specific domain knowledge (see Appendix 1).For instance, questions for CMEs primarily referred to codesign in a general sense, which tapped into their expertise on 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 (e.g., challenges they had faced, how they involved mHealth stakeholders, added value of co-design to their project, etc.).The groups expressed similar considerations around the challenges and added value of co-design since cost and time constraints are typically common factors in codesign processes, regardless of the context.There was general between-group consensus with regard to the aspects that would then inform the derivation of guidelines and the contextualization of the framework.Taken as a whole, the responses from CMEs tended to refer to general considerations around applying co-design to a complex area, while the responses from MSDs were more specific to challenges and best practices based on experience from actual mHealth projects.

Implications
There are several important implications for researchers and practitioners from this work.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 codesign 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.Appendix 5 provides a checklist for co-designing mHealth systems projects along the seven 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 (e.g., [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 post-design 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
The current study is not without limitations.First, it needs to be noted that the majority of interviewees resided in the Oceania region and/or are 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 (e.g.uncertainty avoidance, 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 then 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 the current 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 (e.g., cultural probes, 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 to the mHealth setting and to construct set of tangible guidelines to address common challenges in this space.While the 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 into the mHealth ecosystem, (5) identifying post-design advocates, (6) applying healthspecific 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.

Figure 1 .
Figure 1.Co-design Framework by Sanders and Stappers a

Figure 2
Figure2shows the contextualization of the Sanders and Stappers[13] co-design framework to the mHealth setting.It extends the four phases in the original framework by dedicated prototyping and implementation phases.A detailed overview of example quotes for the contextualization is provided in Appendix 3.

Figure 2 .
Figure 2. Contextualized co-design framework for mHealth a

Figure 3 .
Figure 3. Interplay of guidelines and mapping to the co-design phases

Figures
Figures "You have got all these functionality and metrics that you can get from mHealth that you cannot get anywhere else [such as] Google metrics, Google Analytics, and usage statistics[…].That is a whole avenue of data that you do not have when you do not have mHealth." This is great work.There is definitely work in what you are doing.[...] Any type of framework that helps us to do this on the ground more effectively and in [the mHealth] context, that is the kind of work that we need."[CME4]