Lessons and Reflections From an Extended Co-design Process Developing an mHealth App With and for Older Adults: Multiphase, Mixed Methods Study
Why this work is in the frame
A frame that forgets how it found something cannot be audited. These are the routes that admitted this work.
Bibliographic record
Abstract
BACKGROUND: There are many mobile health (mHealth) apps for older adult patients, but research has found that broadly speaking, mHealth still fails to meet the specific needs of older adult users. Others have highlighted the need to embed users in the mHealth design process in a fulsome and meaningful way. Co-design has been widely used in the development of mHealth apps and involves stakeholders in each phase of the design and development process. The involvement of older adults in the co-design processes is variable. To date, co-design approaches have tended toward embedding the stakeholders in early phases (eg, predesign and generative) but not throughout. OBJECTIVE: The aim of this study was to reflect on the processes and lessons learned from engaging in an extended co-design process to develop an mHealth app for older adults, with older users contributing at each phase. This study aimed to design an mHealth tool to assist older adults in coordinating their care with health care professionals and caregivers. METHODS: Our work to conceptualize, develop, and test the mHealth app consisted of 4 phases: phase 1, consulting stakeholders; phase 2, app development and co-designing with older adults; phase 3, field-testing with a smaller sample of older adult volunteer testers; and phase 4, reflecting, internally, on lessons learned from this process. In each phase, we drew on qualitative methods, including in-depth interviews and focus groups, all of which were analyzed in NVivo 11, using team-based thematic analysis. RESULTS: In phase 1, we identified key features that older adults and primary care providers wanted in an app, and each user group identified different priority features (older adults principally sought support to use the mHealth app, whereas primary care providers prioritized recoding illnesses, immunizations, and appointments). Phases 2 and 3 revealed significant mismatches between what the older adult users wanted and what our developers were able and willing to deliver. We were unable to craft the app that our consultations recommended, which the older adult field testers asked for. In phase 4, we reflected on our abilities to embed the voices and perspectives of older adults throughout the project when working with a developer not familiar with or committed to the core principles of co-design. We draw on this challenging experience to highlight several recommendations for those embarking on a co-design process that includes developers and IT vendors, researchers, and older adult users. CONCLUSIONS: Although our final mHealth app did not reflect all the needs and wishes of our older adult testers, our consultation process identified key features and contextual information essential for those developing apps to support older adults in managing their health and health care.
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
Full frame distilled prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. Learned from the 10,348 direct Codex labels and 10,348 direct Gemma labels. Candidate is the union of thresholded teacher heads; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels or direct frontier model labels.
Codex and Gemma teacher scores by category
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.003 | 0.000 |
| Meta-epidemiology (narrow) | 0.000 | 0.000 |
| Meta-epidemiology (broad) | 0.000 | 0.000 |
| Bibliometrics | 0.000 | 0.001 |
| Science and technology studies | 0.006 | 0.000 |
| Scholarly communication | 0.000 | 0.000 |
| Open science | 0.000 | 0.000 |
| Research integrity | 0.000 | 0.001 |
| Insufficient payload (model declined to judge) | 0.000 | 0.000 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from it