MyStrengths, a Strengths-Focused Mobile Health Tool: Participatory Design and Development
Bibliographic record
Abstract
BACKGROUND: People living with chronic illnesses are an increasingly large group. Research indicates that care and self-management should not only focus on the illness and problem-oriented aspects of these individuals' lives but also support them in recognizing and leveraging their personal strengths in daily life. OBJECTIVE: This paper presents the design and developmental process of MyStrengths, a mobile health (mHealth) app designed to help its users (people with chronic conditions) both find and make use of their personal strengths in their daily lives. Through 4 consecutive phases, this paper presents participant- and researcher-driven activities, discussions regarding design, and development of both the MyStrengths app and its content. METHODS: During the 4 phases, we used a range of methods and activities, including (1) an idea-generating workshop aimed at creating ideas for strengths-supporting features with different stakeholders, including patients, caregivers, relatives, and designers (N=35); (2) research seminars with an international group of experts (N=6), in which the concept, theoretical background, and design ideas for the app were discussed; (3) a series of co-design workshops with people in the user group (N=22) aiming to create ideas for how to, in an engaging manner, design the app; and (4) in 4 developmental iterations, the app was evaluated by people in the user group (N=13). Content and strengths exercises were worked on and honed by the research team, the expert groups, and our internal editorial team during the entire developmental process. RESULTS: The first phase found a wide range of stakeholder requirements to, and ideas for, strengths-focused mHealth apps. From reviewing literature during the second phase, we found a dearth of research on personal strengths with respect to people living with chronic illnesses. Activities during the third phase creatively provided numerous ideas and suggestions for engaging and gameful ways to develop and design the MyStrengths app. The final phase saw the output from all the earlier phases come together. Through multiple increasingly complete iterations of user evaluations testing and developing, the final prototype of the MyStrengths app was created. CONCLUSIONS: Although research supports the use of strengths-focused mHealth tools to support people living with chronic illnesses, there is little guidance as to how these tools and their content should be designed. Through all activities, we found great support among participating users for strengths-focused apps, and we can consider such apps to be both appropriate and valuable. This paper illustrates how combining a range of user-, researcher-, literature-, and designer-based methods can contribute to creating mHealth tools to support people with chronic illnesses to find and use more of their own personal strengths.
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 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.005 | 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.003 | 0.000 |
| Scholarly communication | 0.000 | 0.000 |
| Open science | 0.000 | 0.000 |
| Research integrity | 0.000 | 0.002 |
| Insufficient payload (model declined to judge) | 0.001 | 0.002 |
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 teacher head, 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".