Lessons and Reflections From an Extended Co-design Process Developing an mHealth App With and for Older Adults: Multiphase, Mixed Methods Study
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.
How this classification was reachedexpand
Full frame machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.139 | 0.159 |
| Meta-epidemiology (narrow) | 0.002 | 0.002 |
| Meta-epidemiology (broad) | 0.002 | 0.002 |
| Bibliometrics | 0.003 | 0.002 |
| Science and technology studies | 0.015 | 0.014 |
| Scholarly communication | 0.011 | 0.010 |
| Open science | 0.006 | 0.014 |
| Research integrity | 0.006 | 0.009 |
| Insufficient payload (model declined to judge) | 0.002 | 0.001 |
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 itClassification
machine, unvalidatedMachine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".