Open access peer-reviewed chapter

Why Healthcare and Well-being Researchers should Become Developers: A Case Study Using Co-Creation Methodology

By Mart Wetzels, Joost Liebregts, Idowu Ayoola, Peter Peters and Loe Feijs

Submitted: September 5th 2017Published: October 18th 2017

DOI: 10.5772/intechopen.71113

Downloaded: 164

Abstract

Wearable technologies increase the ability to track different parameters related to health and well-being. As the variety and amount of data sources grow, a better understanding of health-related data can be obtained through research on data fusion. Outcomes can either be validated by end users when results are finalized or throughout the design and development process of mobile health applications. This chapter addresses the co-creation methodology applied for the creation of a mobile health application, called Vire, and the backend, called Synergy, to serve personal data to the mobile health application. Synergy provides an interface for the research team to interact with participants and visualizes parameters relevant to the study. Modern frameworks and platforms, such as React Native and Meteor, are used to facilitate the adaptiveness and functionality required for the co-creation of Vire. The chapter concludes by addressing the findings from the study with 26 participants.

Keywords

  • mobile health application
  • mobile application
  • research team
  • back office
  • react native
  • minimum viable product
  • experiential design landscape

1. Introduction

Wearable technologies increase the ability to track different parameters related to health and well-being. Mobile applications such as Gyroscope [1], Apple Health [2], and Google Fit [3] aggregate health data to provide a better personal insight or a collected overview of data. Individual vendors of wearable trackers, such as Fitbit and Beddit, provide mobile applications specific to their devices. These vendors often provide Application Programming Interfaces (APIs) to collect data for analysis or visualization. The objective of Vire and Synergy is to design a mobile health application that applies data fusion and data visualization techniques to create additional value for the users besides the vendor-specific applications. Existing research and design methodologies to evaluate the value of these visualizations for potential users are limited. Questionnaires can provide insights into specific topics such as the comfort of using trackers [4]. Text messaging can be used to test the efficacy of a system intended to improve blood pressure control and treatment adherence compared with usual care [5]. The co-creation method described combines these methods (questionnaires/text) and uses the infrastructure. The infrastructure developed (Vire and Synergy) enables to use these methods real-time for continuous observation and responsiveness to events within the scope of the research objectives.

2. Methodology

The methodology, being developed through this case study, is based on the Experiential Design Landscapes (EDL). EDL follow a research-through-design approach where the design process is positioned in the social context by creating infrastructures that enable designers and other stakeholders to develop Experiential Probes that evolve over time [6]. The EDL methodology solves the dilemma of ecological validity versus control, by enabling measurements to be taken in the actual context previously only possible in a controlled environment. Also, the EDL methodology solves the complication in generalizing the findings from a controlled environment to a real-life setting. The real-life setting, in case of an EDL, is an open environment accessible to the general public. Our methodology is applied to the individual participant’s context instead of the open environment, so it extends the probes to Personal Experiential Probes (PEPs). As visualized in Figure 1, each participant independently interacts with the mobile application and related devices. Feedbacks from participants are collected throughout the study, and changes to the mobile health application are pushed to the participants in an iterative fashion. The advantage of this approach is that suggestions for new features, or other changes, are evaluated independently by other participants. In comparison with the EDL methodology, our methodology is restricted to software possibly extended with connected devices.

Figure 1.

Visualization of methodology based on EDL.

2.1. Minimum viable product

Prior to the inclusion of participants, a period of 1–2 months is reserved for the definition and building of the minimum viable product (MVP). For this study, no prior cases provided experiences to substantiate features to be included in the MVP; thus, existing mobile health applications were investigated to define features. Features were categorized between essentials and optionals. Essentials are required to be ready before the launch of the mobile application whereas optionals can be built during the study. See Table 1 for examples of features defined for this case study.

EssentialsOptionals
MVPCommunication through a messenger service
Data integration mechanism with Meteor
Authentication with user accounts Profile page with settings
Push notifications for new messages
Bluetooth integration for other external devices
GPS tracking
Localization (multilanguage support)
Vire and SynergyList of DOs
Integration of Fitbit, Beddit, and Moves
Textual representation of data
Visual representation of data
Personalized representation based on correlations

Table 1.

Essentials and optional features for MVP.

2.2. Participants

The size of the study population is limited from 20 to 30 participants between the ages of 18 and 75. The lower limit (20) prevents over-fitting and generalization of feedback on design decisions. The upper limit (30) is dependent on the number of available devices, but a larger sample would require additional members in the research team. Participants without an iOS- or Android-based mobile phone operation system are excluded due to the current limitation for Windows Mobile development in React Native. Each participant received a Fitbit Charge HR [7] and Beddit 2 [8] and was asked to install the corresponding mobile applications, Moves [9], Vire. Also, all research team members used the same devices.

2.3. Environment

Figure 2 depicts the ecosystem utilized in the study. Specific for the aggregation of Fitbit, Beddit, and Moves data, the services preceding Synergy are used to facilitate the availability of personal data in Vire. Figure 2 also shows two versions, alpha and beta, of Vire that are used to evaluate a new Vire version within the research team before deploying to the participants. The illustrations used in Figure 2 are the logos of the platform or framework used by the services.

Figure 2.

Visualization of ecosystem used in study.

Synergy is built using the Meteor (open-source) platform, developed by the Meteor Development Group (MDG). Synergy functions as the backend for Vire and serves the back office for the research team. Meteor was chosen for its use of the distributed data protocol (DDP)—a publication/subscription mechanism through websockets—that enables “real-time” applications. Vire is built using the React Native framework, developed by Facebook [10]. React Native enables the development of native, iOS and Android mobile applications using JavaScript and React. React Native was chosen for its crossplatform compatibility and performance in comparison with its alternatives. The uses of Meteor and React Native require researchers to only have experience in JavaScript for the development of the backend, back office, and mobile applications. The use of one programming language throughout enables a lower threshold for new researchers to become skilled in the tools used.

2.4. Interfaces

The interfaces presented in Figures 3 and 4 are specific to the implementation of Vire and Synergy but can be stripped to be reused for other researches. Throughout the design of these interfaces, the intent of creating a boilerplate for future research is kept in mind.

Figure 3.

Screenshot of back-office participant view.

Figure 3 shows the interface for the members of the research team. On the left pane is a list of all users with a notification label that shows a counter of unread messages sent by the participants. In the center pane, top left is the chat module to communicate with the participants. Participants do not know to which researchers they are talking to. On the top right, a list of current DOs for the participants and the completion state is listed. New DOs can be added there as well. On the bottom pane, there is room for notes from the researchers about the participants. Researchers share notes on the homepage and have a single page for notifications.

Figure 4 shows four screenshots of the MVP of Vire containing the homepage, where the visualization work will be done; the messenger, where participants can communicate with the research team; the list of DOs, where participants can see and mark their DOs complete; and the profile page where participants can link their devices and change language. The primary focus is on the development of the homepage.

Figure 4.

(a) Vire daily, (b) chat with researchers, (c) list of DOs, and (d) profile information and settings.

3. Results

After six months of running the study, the results on user requirements can be categorized as macro- and microfeatures concerning the MVP or for the implementation of Vire and Synergy.

Table 2 shows the division between MVP and Vire- and Synergy-specific requirements found during the study. For Vire and Synergy, the new MVP requirements are built in during the study. Future studies will include these before the involvement of participants. The requirements for Vire and Synergy are meant to be obtained while performing the research and are planned to be implemented and evaluated during the duration of the study. The outcome of this methodology is a back-office and crossplatform mobile application, ready for further research. The final results provide new requirements for the definition of the MVP. Future studies can reuse the boilerplate—template code for the MVP—with the improvements from previous experiences. Also, as stated in Table 2, the structure of the methodology can be redefined to clarify expectations from participants and increase efficiency in the iterative process.

MacroMicro
MVPCommunication of current activities to participants
Overview of activity/engagement of participants in back office
Integration of push notifications
Display connectivity status for internet and server connection
Vire and SynergyBack-office interface mimicking participant’s views
Defining value Vire over the existing mobile applications
Data availability when offline
Localization features and limited use of text
Descriptions of calculated values

Table 2.

Overview on user requirements.

Figure 5 depicts the final version of Vire. In relation to Figure 4, a two-weekly overview and food record is added to provide better information to the users. Other notable differences include the refinement of general styling and markup. Throughout the study, the focus lies on the definition and development of core functionalities of the app and test that the app works both on low- and high-end mobile phones. To the end of the study, the requirements become saturated and more concrete; this enables to focus on improving the visual experiences.

Figure 5.

(a) Daily overview, (b) two-weekly overview, (c) dietary pictures, (d) list of DOs, and (e) profile and settings.

Vire, for Android and iOS, will be used for a clinical trial of 150 cardiac rehabilitation patients in the Netherlands, Spain, and Taiwan. The methodology and study itself have contributed to the clinical trial by evaluating the functionality and usability of Vire outside the scope of the trial within an open environment. Without this process, issues or additional requirements not considered on forehand could affect the experience of the clinical trial.

4. Discussion

The methodology described in this chapter provides a rich feedback mechanism for the design and development of a research-based mobile application and accompanying back office. The reasons why well-being researchers should become developers are evident. The ability to define the MVP and the flexibility to implement features based on user feedback on the spot are the two main reasons we have found. By being involved in the development of a mobile health application as a researcher, the quality of the research increases. The effectivity of an intended interaction can be compromised by an esthetic mistake or incompatibility on certain devices. Using our methodology, the design and development artifacts that influence the user experience are already tackled. The experience, or the ability to gain experience, in defining prerequisites for the development of a mobile health application is gained through the hands-on approach. Within this process, the researchers are confronted with real-life development issues that give insight into the feasibility of a proposed or requested feature from participants or from within the research team itself. These learnings will provide the experience to prevent working on over-ambitious features and trigger creativity by discovering the limitations of used software and hardware. The use of JavaScript-based frameworks (React-Native) or platforms (Meteor) eases the learning curve for researchers, without in-depth programming experience, to tackle issues and develop iteratively by responding to feedback from participants. This approach enforces careful consideration of design and development decisions to (re)define the chosen direction of the study and offers a method to strengthen the qualities of the mobile health application and thereby the research itself.

Acknowledgments

This work is supported by the European Commission Horizon2020 which funded Do Cardiac Health: Advanced New Generation Ecosystem (Do CHANGE) project.

How to cite and reference

Link to this chapter Copy to clipboard

Cite this chapter Copy to clipboard

Mart Wetzels, Joost Liebregts, Idowu Ayoola, Peter Peters and Loe Feijs (October 18th 2017). Why Healthcare and Well-being Researchers should Become Developers: A Case Study Using Co-Creation Methodology, Proceedings of the Conference on Design and Semantics of Form and Movement, Miguel Bruns Alonso and Elif Ozcan, IntechOpen, DOI: 10.5772/intechopen.71113. Available from:

Embed this chapter on your site Copy to clipboard

<iframe src="http://www.intechopen.com/embed/proceedings-of-the-conference-on-design-and-semantics-of-form-and-movement-sense-and-sensitivity-desform-2017/why-healthcare-and-well-being-researchers-should-become-developers-a-case-study-using-co-creation-me" />

Embed this code snippet in the HTML of your website to show this chapter

chapter statistics

164total chapter downloads

More statistics for editors and authors

Login to your personal dashboard for more detailed statistics on your publications.

Access personal reporting

Related Content

This Book

Next chapter

Designing Biologically Inspired Movements into the Esthetics of Interactive Artifacts

By Neda Fayazi and Lois Frankel

Related Book

First chapter

Nonparametric Modeling and Model-Based Control of the Insulin-Glucose System

By Mihalis G. Markakis, Georgios D. Mitsis, George P. Papavassilopoulos and Vasilis Z. Marmarelis

We are IntechOpen, the world's leading publisher of Open Access books. Built by scientists, for scientists. Our readership spans scientists, professors, researchers, librarians, and students, as well as business professionals. We share our knowledge and peer-reveiwed research papers with libraries, scientific and engineering societies, and also work with corporate R&D departments and government entities.

More about us