MONARCA is a persuasive mobile phone application designed to support the treatment and management of bipolar disorder. Behavioral data is monitored through both sensing and manual patient input, while timely feedback is provided based on clinical recommendations to help patients adjust their behavior and manage their illness. This paper presents the design process behind the MONARCA system and initial findings on the challenge of designing a persuasive system for the management of bipolar disorder. We discuss how difficult the design of such technology has turned out to be, for two primary reasons: (1) the inherent challenges of using persuasive metaphors with a complex mental illness, and (2) the tradeoffs encountered due to varying, and sometimes conflicting, stakeholder needs.
INTRODUCTION Persuasive personal monitoring systems seem promising for the management of mental illnesses such as bipolar disorder. Bipolar disorder is characterized by recurring episodes of both depression and mania, with treatment aiming to reduce symptoms and prevent recurrence throughout a patient’s lifetime. By applying pervasive healthcare technologies to the treatment of bipolar disorder, we can monitor patients’ behavioral and mood data, and provide timely feedback to them in order to help them adjust their behavior. This data supports the treatment and management of the illness in a multitude of ways. For example, patients and their clinicians can use the data to determine the effectiveness of medications, find illness patterns and identify warning signs, or test potentially beneficial behavior changes. Behavioral data collected could be used to predict and prevent the relapse of critical episodes.
Despite the plethora of research into personal monitoring
systems targeting behavior change [
METHOD Patients and clinicians of a bipolar disorder treatment program took part in an in-depth participatory design process. They were instrumental in decision-making about features through collaborative design workshops and iterative prototyping. Patients participated in semi-structured interviews about the treatment and management of their own illness to further inform the design process. Notes and artifacts from these design activities were analyzed for 1) an understanding of each stakeholder's motivations and needs, and 2) indicators of tradeoffs that arose in the design of the system.
Workshops were held every other week for six months. At every workshop, 1-3 individuals attended from each of the following three stakeholder groups: patients, clinicians, and designers. The designers led each three-hour workshop by facilitating discussion about particular design goals and issues; system features and functionality; and feedback on mockups and prototypes of the system. During initial workshops, overall goals of the system were introduced from both clinical and technical perspectives. Sharing these perspectives of the project involved drawing from their respective best practices: both medically and practically, clinicians know what works with patients; and designers are aware of related systems and technologies.
Design activities at workshops began in the early stages with hands-on brainstorming. We provided materials such as documents summarizing the goals of the system, images of existing tools and methods, large poster paper, writing materials, scissors, tape, etc. The sketches that came out of this initial brainstorming formed the basis for the first mockups. For the rest of the process, at each workshop we 1) discussed a few design goals and system features in depth, and 2) received feedback on the next iteration of the mockups. Mockups presented during workshops progressed from sketches to wireframes to interactive prototypes. SYSTEM DESIGN The design process resulted in 5 focus areas for a persuasive system for bipolar disorder: self-assessment, activity monitoring, historical data overview, coaching & selftreatment, and data sharing.
Self-assessment Subjective data is collected through a mobile phone using a simple one-page self-assessment form. Less than 10 items are entered by the patient on a daily basis, including mood, sleep, level of activity, and medication. Some items are customizable to accommodate patient differences, while others are consistent to provide aggregate data for statistical analysis. A simple alarm reminds the patient to fill out the form.
Activity monitoring Using sensors in the phone, objective data is collected to monitor level of engagement in daily activities (based on GPS and accelerometer), and amount of social activity (based on phone calls and text messages). This data is abstracted for analysis, to protect the patient’s privacy while still supporting self-assessment using objective data. Historical overview of data The patient and clinician will both have access to the data through a web interface. This will give them the means to explore the data in depth by going back and forth in time, and focusing on specific sets of variables at a time. Coaching & self-treatment Psychotherapy will be supported through everyday reinforcement in two ways. Customizable triggers can be set to have the system notify both patient and clinician when the data potentially indicates a warning sign or critical state. Second, after patients are advised by their clinicians about which actions to take in response to warning signs, they can keep track of and review them through the system. Data sharing In order to strengthen the psychotherapy relationship data and treatment decisions are shared between the patient and his/her clinician. Similarly, sharing data with family members or other caregivers empowers the patient to support the treatment process. Finally, sharing data among patients helps with personal coping and management efforts by reassuring patients that they are not alone, and helping them see how others manage their illness.
CHALLENGES WITH A PERSUASIVE METAPHOR One of the main original goals of the user-centered design process was to design a persuasive system for bipolar patients, which could help them constantly adjust their behavior to manage their own illness. In particular, the design process revealed the following three parameters were crucial to keeping a bipolar patient stable: 1. adherence to the prescribed medication – i.e., ensuring that the patient takes his or her medication on a daily basis 2. stable sleep patterns – e.g., sleeping 8 hours every night and going to bed at the same time 3. being physically and socially active – e.g., getting out of the home, meeting with people, going to work. Now – at first glance, this may seem simple, but numerous studies have shown that each of the above three things are very difficult to achieve for many patients, and achieving all three consistently is inherently challenging in combination with a mental illness. Hence, the core challenge is to create technology that would help – or “persuade” – the patient to do these three things every day.
Most persuasive health-related Ubicomp systems have adopted different metaphors with the goal of motivating the patient to perform healthy behavior. Examples of such metaphors include a garden that grows when the person is physically active; a fish that grows when the person walks more; and a dog that is happier when the person eats healthy meals. Common to these metaphors is a simple-tounderstand relationship between behavior (e.g. exercise) and visualizations in the metaphor (e.g. more flowers in the garden).
In the design of the MONARCA project, we tried to adopt the same strategy of creating a metaphor. In total of 5 different metaphors were tested and tried out in a series of design workshops. These metaphors included the use of an abstract color picture, a landscape with a river, a dartboard, a music equalizer, and a scale. The patients and clinicians rejected all of these metaphors – one after the other. Why did this happen? First we thought that maybe we were just bad at designing the metaphors, and we kept on trying with new ones. But since it turned out to be a persistent “problem”, we think that something more fundamental was at stake, which was expressed by one of the patients as: “I do not want my illness to be reduced to a game.” We think that this is an important insight into the design of persuasive technologies for healthcare and selfmanagement. Many of the technologies and metaphors reported so far deal with personal lifestyle related health management, which is fundamentally different from patients with a diagnosed mental illness. We think that the design of feedback to the patient needs to follow another pattern other than using a metaphor.
DESIGN TRADEOFFS During the user-centered design process, we discovered several tradeoffs in the design of the system due to conflicting stakeholder needs and motivations. These tradeoffs relate to the clinical efficacy of the system, the patient’s privacy, sustained use of the system, and other issues. In this section, we highlight two of the primary tradeoffs we dealt with during the design of MONARCA.
Clinically driven vs. patient driven strategies If a system has a strong clinical focus – meaning that it adopts only clinically proven treatment strategies – it could miss out on patient-driven approaches that may be helpful to some patients. In addition, the system may also ignore novel technological solutions that the clinical field has yet to evaluate. Since our system was designed for a clinical context, it was important that it adhere to clinical practices so that it could be evaluated as a valid intervention. In addition, considering clinical practices was crucial in designing a system to be viable for adoption and acceptance into a patient's treatment, which includes everyday use by the patient and occasional use by the clinician.
The clinicians that took part in our design activities shared with us scenarios, anecdotes, and commonalities about the treatment of their patients. We understood the context we were developing the system for by understanding the practices of clinicians with their patients. A recurring theme was clinicians' limited resources. This turned into a limitation for the functionality of the system, because if something took too much time or attention on the clinician's part, the clinicians would reject it. An example of one such feature was the system suggesting that the patient contact the clinic if data collected indicated possible warning signs – and making it easy for the patient to place this call. The motivation behind this feature was to encourage the patient to reach out for help when needed, but the clinicians ultimately rejected the idea because we could not find a reasonable protocol to make the benefits to the patient outweigh the burden on the clinic's resources. Features of the system also couldn't present a liability for clinicians, so they were more likely to reject ideas and limit the role of the system to be on the safe side. Any kind of text messages or notes written by the patient and made available to the clinic were kept out of our design, because we could not ensure that the clinicians would always read these messages, so we could not make them liable for their content.
We therefore realized that designing our system with primarily a clinical focus was limiting. The clinicians we worked with were clearly most comfortable with strategies that they were familiar with, they had evidence for based on their experiences with patients, and were backed by clinical trials. Deviating from these practices somewhat, and pushing our clinicians a little bit out of their comfort zone, enabled us to explore other potential strategies, from the perspectives of the patients and the designers.
An additional example of a debated feature is reported stress level. A stress level scale was strongly rejected by a clinician who argued that stress is not a clinically useful measure, nor is there any clinical definition of stress that would support accurate data collection. Interestingly, a second clinician was the one who suggested the stress level scale, and argued for it from a very patient-centered perspective based in psychotherapy. This clinician found that external stressors play a significant part in the mood of her patients, and it was useful for her to consider a patient's reported stress level when assessing how that patient was doing. She also believed that patients would find it useful to assess their own level of stress, regardless of the fact that they would be interpreting its meaning for themselves in the absence of a clinical definition. The patients tended to agree with her, so although this feature was under debate for several weeks, the designers opted to keep it in the design because enough participants believed there could be personal value in assessing one's stress.
The patients were creative in suggesting strategies based on their personal experiences. Knowing what behavioral changes have worked for them in the past, and imagining what new strategies might work for them, patients explored technological solutions unrestrained by considerations of clinical efficacy. This unrestrained creativity was productive during the design process for two reasons. First, it revealed what would motivate the patients to use the system, which is critical to adoption and acceptance. Second, it helped us realize which measures, though clinically significant, would ultimately fail because they were too intrusive for the patient to collect, or were not interesting enough to the patient to motivate collection.
Egocentric patient bias vs. clinician generalizations Although patients provide valuable insights into the experience of living with and managing bipolar disorder, their input tends to be egocentric, since their knowledge about the disorder mostly comes from their own personal experience with it. Discussions about the amount and type of data to collect were complex due to the different experiences and motivations of the stakeholders: clinicians were interested in data they knew to be relevant for assessment based on clinical studies or their own experiences treating patients; and patients were interested in data they thought would be useful to themselves personally for self-reflection. To balance these sometimes opposing interests, designers focused on what data would be easy and convenient to collect. Without nonintrusive data collection methods, the system will be overloaded with features and burden the patients, who are responsible for collecting the data every day. Here, the designers play an important role in keeping in perspective the implications of collecting different amounts and types of data. Patients and clinicians disagreed about how to include customizable personal warning signs, which patients would personalize and track on a daily basis. In addition to the universal warning signs that we selected with the help of clinicians to be applicable to most, if not all, patients, we discussed including personal warning signs that each patient could customize based on personal symptoms. Clinicians argued that there should be as few of these items as possible, even stating that one personal warning sign was difficult enough for patients to attempt to track in their daily life. On the other hand, patients argued that having more flexibility would allow them to explore multiple warning signs at once in order to determine which ones applied to them. One patient, who had difficulty understanding her illness and could not identify any of her personal warning signs, asked for a lot flexibility because she would have no idea what to track, so she would need to try many different items. The designers found a solution by suggesting that the feature be limited but flexible. The agreed upon solution would allow patients the option to include as few as one personal warning sign, but no more than three. Those patients who would only be able to handle one item at a time could customize the system to show only one at a time.
CONCLUSION In the design of a persuasive personal monitoring system for bipolar disorder, we ran into several challenges unique to using persuasive technology for the management of mental illness. Our findings demonstrate that the design of a system for bipolar disorder is quite different from that of systems that have been explored for other health purposes such as nutrition, physical activity, and chronic physical illnesses. In this paper we have highlighted some of the main issues that emerged during our design process, including using a persuasive metaphor, balancing clinical- and patient-centered strategies, and dealing with the biases of patient and clinician participants. Our work revealed major challenges due to the complexity of the illness, stigma surrounding the illness, and the often-conflicting needs of clinicians and patients.
ACKNOWLEDGMENTS This work has been partially funded by the EU Contract Number 248545 - MONARCA under the 7th Framework Programme. We would like to thank our participants for their contributions to this project and enthusiasm for the work.