User-Centered Design and Interactive Health Technologies for Patients

Abstract

Despite recommendations that patients be involved in the design and testing of health technologies, few reports describe how to involve patients in systematic and meaningful ways to ensure that applications are customized to meet their needs. User-centered design (UCD) is an approach that involves end-users throughout the development process so that technology support tasks, are easy to operate, and are of value to users. In this paper we provide an overview of UCD and use the development of Pocket Personal Assistant for Tracking Health (Pocket PATH), to illustrate how these principles and techniques were applied to involve patients in the development of this interactive health technology. Involving patient-users in the design and testing ensured functionality and usability, therefore increasing the likelihood of promoting the intended health outcomes.

Introduction

The development of interactive health technologies (IHTs) to promote health and manage illness has led to fundamental changes in health practices;¹ in fact these technologies have been credited with transforming health care. ^2,3 IHTs are defined as the interaction of an individual - consumer, patient, caregiver, or professional - with a computerized technology to access, monitor, share, or transmit health information, ⁴ and refer specifically to the communication and software programs for users, rather than the platforms (desk-top computers, internet, hand held computers or other devices) that run or deliver these applications. These applications support activities such as exchanging health information among patients and between patients and professionals, enabling health decision-making, and promoting positive health behaviors such as self-care.^4-6 IHTs have been successful in promoting better health outcomes for diverse patient populations. Examples include: Comprehensive Health Enhancement Support System (CHESS), a computer-based system of integrated services designed to help individuals cope with a health crisis or medical concern, ⁷ HeartCare: an internet-based information and support system for patients recovering after coronary artery bypass surgery,^,8, and Partners in School Asthma Management for inner-city elementary school children. ⁹

However, descriptions of IHTs intended for use by patients are typically limited to reporting their efficacy in promoting health behaviors and outcomes. It is rare to find reports describing how these IHTs were actually developed, particularly the methods that were used to involve patients in the early stages to design and test their usability. Yet for those who are considering developing IHTs, knowledge of these steps is crucial if the applications are to meet the patients’ needs, be easy to learn, and effectively support their tasks. Furthermore, despite recommendations that patients be involved in the design and testing of health technologies, ¹⁰ and that a full description of how IHTs were designed, tested and debugged be included in reports about such applications, ¹¹ few reports describe how to involve patients in systematic and meaningful ways throughout the development process. Therefore, the purposes of this report were to: 1) review the principles of user-centered design (UCD), 2) illustrate how to involve patients in UCD and prototype testing, and 3) conduct a descriptive, pilot study to determine whether Pocket PATH meets users’ needs and expectations.

User Centered Design

IHTs are designed to enhance health behavior changes and the management of illness, ¹² but their ultimate success depends on whether the intended users (e.g., patients) find the applications useful. Usability is defined as the measure of the ease with which a system can be learned and used, including its safety, effectiveness, and efficiency. ¹³ UCD is an approach for developing applications that incorporates user-centered activities throughout the entire development process. ¹⁴ This approach allows end-users to influence how a design takes shape in order to increase ultimate usability. ¹⁵ It involves a variety of methods, including assessing the intended users, observing and analyzing tasks and requirements, developing and testing prototypes, evaluating design alternatives, analyzing and resolving usability problems, and testing the features and interfaces with users in an iterative manner. Incorporating UCD principles in the overall development of IHTs keeps the focus on meeting users’ needs. Once considered dispensable, time consuming and costly, evidence of the benefits of the UCD approach is now unequivocal. ^16-20 Research suggests that involving users in the design and development of a new system will improve the system’s quality because of the more accurate assessment of user requirements and the higher level of user acceptance. ^18-20 Involving users has been found to substantially reduce development time because usability problems are identified and resolved before the systems were launched. ¹⁹ Applying UCD to the development of IHTs for patients improves functionality and usability, therefore increases the likelihood of promoting the intended health behaviors and health outcomes.

While UCD is highly acclaimed as a means of ensuring user acceptability, its application with patient users has not been widely disseminated to the health science disciplines despite calls for its application. ^10,11 This gap is problematic since nurses and other health scientists typically identify the health problems or behaviors of concern and propose possible interventions, many of which are IHTs intended for use by patients.

Why do developers of IHTs designed for patients neglect to incorporate UCD in the development cycle, minimize the significance of evaluating usability with patient users, or fail to report how the principles of UCD were integrated into the development of their IHTs? Possible explanations include: a lack of appreciation for the importance of usability testing, a lack of time and resources to devote to upfront research and development, limited expertise in the principles and techniques of UCD, and perhaps most importantly, the tendency to develop IHTs based on developer-driven needs and priorities rather than those of the intended users. ¹⁹

Over twenty years ago, Gould & Lewis ²² introduced three guiding principles of UCD: 1) focus on users and tasks early and throughout the design process, 2) measure usability empirically, and 3) design and test usability iteratively. Since then, standards and techniques for applying these principles have emerged to meet the needs of specific projects. ¹⁷.¹⁹.²⁰

Applying UCD to the Development of Pocket PATH

Using the development of Pocket PATH as an exemplar, we will illustrate how the principles of UCD drove the design and testing of this patient-centered IHT. We developed this IHT to provide lung transplant patients a handheld PC with customized data recording, tracking, messaging and decision-support programs to promote self-care behaviors, including performing self-monitoring and identifying critical values that need to be to communicated to their transplant team in a timely manner. The complexity of the medical regimen to be followed by patients for the remainder of their lives after lung transplantation can be daunting. The regimen includes self-monitoring a variety of objective and subjective indicators (e.g., home-based spirometry, symptoms, blood pressure, and temperature) because no indicator alone has been shown to adequately detect complications such as acute organ rejection and infection. ^23,24 To this end, patients are expected to measure a variety of health indicators at home and notify the transplant team of any changes in their conditions.²⁵ However, many patients find it difficult to adhere to self-monitoring, identify worrisome trends, and decide what values should be reported to the transplant team. ²⁶ Below is an explanation of how each of the three principles of UCD was applied to the design and testing of Pocket PATH.

UCD Principle 1: Focus on Users and Tasks

Assembling the Development Team

An interdisciplinary team was assembled to ensure that the IHT addressed the latest clinical, behavioral and computer science advances and standards. It also ensured that multiple perspectives were considered when identifying and resolving issues that might arise during the development of the IHT. The team included: a nurse (principal investigator [PI]), computer scientists (human computer interaction specialist, programming engineer and user interface designer), behavioral scientists (experts in assessing and intervening on adherence-related behaviors in transplant and other chronic disease populations), a cardio-thoracic transplant physician, and a communication scientist who provided guidance as the project evolved based on his pioneering experience developing IHTs for persons with cancer. ⁶

Understanding the patient-users, their characteristics, and the health-related tasks to be performed were the IHT development team’s primary concerns. Assessing patients actually performing their work enabled us to understand the users’ goals, interests and learning styles that impact the use and effectiveness of an application. Without this knowledge, we could not be certain that the IHT was likely to modify or promote the intended health-related behaviors, nor be reasonably certain that the platform we selected and the user interface we designed would be appropriate for the intended patient-users.

Assessing Intended Users

We gathered information about background characteristics for the patients at our center that could affect their use of computer-based technologies from a variety of sources. Similar to the U.S. population of lung transplant patients, ²⁷ approximately 50% of our lung recipients are aged 50 or older, slightly more than half are female (53%), and 93% are Caucasian. Data were not available for computer experience in this cohort, but approximately 15% of patients used email to communicate with the transplant coordinator (R. Zomak RN, MS, Transplant Coordinator, personal communication, 4/15/05). In a recent survey of adult heart transplant patients at our center, ²⁸ 35% (29/82) indicated they had web access at home. The proportion of lung transplant patients with some computer skills was anticipated to be similar to heart patients; most were novice computer users. Prior research also showed that computer-based interventions were acceptable to chronically ill persons and their caregivers, despite lack of previous computer experience. ^7,29-31 Other studies reported a high degree of acceptance of handheld computers and phone-based transmission systems ^32,33 by persons with chronic illnesses and low levels of computer literacy, including lung transplant patients.³⁴ Although young people find computer technologies readily acceptable and commonplace, older adults have an interest in technology and can acquire new complex computer skills.³⁵

To identify any physical impairments that might interfere with patients’ ability to use computerized devices, we reviewed the symptoms reported by a large cohort of lung transplant patients. ²³ The prevalence of tremors, blurred vision and short-term memory loss (primarily side-effects of the immunosuppression medications) highlighted the need to include users with these impairments in the design and testing of Pocket PATH.

Recruiting Representative Patients

After receiving IRB approval, we recruited a sample of 7 lung transplant recipient-volunteers from among patients returning to the pulmonary transplant center for routine follow-up. Our sample size was based on prior research suggesting that at least 5 users will expose the majority of usability problems.³⁶ Purposive sampling was used to recruit recipients of both genders and members of racial and ethnic minorities, as well as participants with blurred vision, tremors, short-term memory impairments and limited computer experience.

The following eligibility criteria were applied: 1) recipient of a lung transplant at least 12 months ago (in order to understand and evaluate self-monitoring tasks of patients with experience following the post-transplant regimen), 2) age ≥ 18 years (children under18 have different self-care patterns as a result of their developmental stage and dependence on adult guardians), 3) English speaking, 4) live within an hour drive of the study site (to reduce the time and effort for travel), and 5) willingness to permit a home assessment, attend at least three laboratory testing sessions, test the application in the field setting (his/her home) for a two week period, and participate in a final interview and evaluation at the completion of the study. All seven patients approached for participation agreed to enroll. Characteristics of the test users are presented in Table 1.

Table 1.

Characteristics of Patient-Users (n =7)

Gender	Female	4
	Male	3
Age years	51± 11 (21- 69)
Race	Caucasian	5
	African American	2
Education	High School	2
	Vocational	2
	College	3
Employment	Full-time	1
	Retired	1
	Disabled	5
Income	$ 5,000 - 19,999	4
	$ 20,000 - 49,999	2
	$ 50,000 or more	1
Impairments	Tremors	3
	Blurred Vision	2
	Memory Loss	2
Computer Use	None	3
	Desktop	4
	Desktop & handheld	2

Identifying the Intended Tasks

We reviewed the empirical literature regarding self-monitoring after lung transplantation to identify the intended tasks. Patients were routinely instructed to monitor clinically significant indicators of potential complications, including temperature, lung volumes and symptoms. Before discharge from the hospital after transplant, recipients are given a micro-spirometer, instructed to measure their lung volumes at least three times a week, record their values on a flow sheet, and contact their transplant coordinator if they notice a 10% reduction in forced expiratory volume in 1 second (FEV1). They are also instructed to report worsening shortness of breath, cough or fever.

Assessing How Patients Currently Performed Their Self- Monitoring Tasks

Contextual inquiry methods were used to learn how lung transplant patients were currently carrying out activities related to self-monitoring and to identify how an IHC might support these tasks. The premise for this field interview and observation method ³⁷ is simply to go where the users perform the tasks, observe, and talk with them as they perform the tasks. Some aspects of contextual inquiry are not foreign to clinicians, who are typically comfortable making home visits, and find these visits fruitful for gaining a better understanding of patients’ situations and an opportunity to reinforce health behaviors. However, contrary to the usual purpose of home visits during which the clinician is seen as the expert, for contextual inquiry, the purpose is to learn how the users perform the tasks. The stance of the developer is that of an ‘apprentice’ and the users are the ‘masters’ at performing their tasks.

At the start of the home visit with a lung recipient, he/she was told, “I’m here to learn how you gather and keep track of the information that you consider important for monitoring your health since your transplant.” A selected field note from one home visit is included (see inset) to illustrate what was gleaned about recipients’ self-monitoring and communication with the transplant clinician about health changes. Findings of this contextual inquiry conducted in the patient’s home, combined with contextual inquiries of other patients, pointed to the need for several customized features to promote self-monitoring. These included the ability to: simply and accurately record measures for a variety of objective and subjective indicators, display data in ways that made it easy for patients to recognize subtle changes and trends, provide warnings when critical thresholds were reached, provide feedback messages reminding patients of changes that coordinators expected to be notified about, organize contact information, and provide reminder systems. The need for these features would not have been apparent without having conducted these face-to-face inquiries with persons who were expected to perform the health care tasks in their typical surroundings.

Inset: Contextual Inquiry Field Note.

One recipient took me into her bedroom and pointed to a corner next to her bed with a table that was loaded with what she called, ‘her paraphernalia’ which included medication bottles, a spirometer, glucose meter, blood pressure cuff, thermometer, an alarm clock, an address book and a stenographer’s notebook. She said, “See that’s how I do it, every morning.” I asked her if she would show me what she does every morning while I observe, ask questions and take notes. She then sat on the side of the bed, took a deep breath and began what she called her ‘morning ritual’ commenting that, “I do all these things because I know it’s important to let [my coordinator] know when things aren’t right.” She picked up her spirometer first and said, ‘this is key… if my breathing isn’t good, the number will be lower, see (pointing to the digital screen on the microspirometer).” Then she demonstrated the expiratory maneuver, read the result and entered the number in her notebook, showing me the many pages of measurements she had entered previously. I asked her what she thought of today’s reading; she said it looked pretty good. I asked how she could tell, and she scanned the list of entries over the past several days and said, “by ‘eyeballing it’, they look pretty close.” I asked what spirometer reading would lead her to contact the coordinator and she said, ‘they say to call if the number drops by about 10%…but looking at the list, it’s hard to tell when it gets to that point, so I just look for drastic changes….then I guess I’d call…I’d call if it was too low and if I wasn’t feeling well. I don’t want to bother them otherwise, they’re busy enough.” I asked her how she judged how well she was feeling; she said, “I think about whether I’m more winded, or whether I can do what I normally do.” I asked if there were any other ways for her to tell. She said, “…or if I have a fever or a cough, things they say to call them about, but I have to feel pretty bad to call, otherwise I’ll wait and bring it up at my next appointment.” I asked what she used the alarm clock for, and she said, “…not too much… sometimes if I need to get up early for an appointment, or to remind me to take some pills, but most of the time I remember.” She showed me her address book with phone numbers for her transplant coordinator, her doctors, her pharmacy and contact information for friends and family.

Selecting the Appropriate Platform

Because patients perform self-monitoring in their homes, fully functional, palm-sized, stand-alone computer devices seemed the most logical choice for the IHT application. ^{1, 38} Hand held devices do not depend on Internet access or require any hardware in the home other than a phone line. Another consideration was the fact that many lung patients do not reside in close geographic proximity to the transplant center; follow-up visits often require long distance travel. Therefore, the development of a mobile IHT application was particularly appealing for this patient population. Its portability allowed the device to be taken to the transplant center where the patients’ health information could be shared with their clinicians during follow-up evaluations. We selected the Hewlett Packard iPAQ Pocket PC ® hx 2000 as our platform because it came equipped with several helpful features--calendars, contacts, notes, and alarms. These built-in features were attractive to the users and therefore encouraged use and integration of the device into their normal routines. ³⁹ The iPAQ used a version of the Microsoft Windows Operating System, and was easily programmable; program updates can be made centrally at the study site and sent via modem to devices remotely. All data entries were time-stamped, and data regarding patients’ condition and usage of the device were uploaded to the study site via a toll-free phone line (modem). Flash memory cards made it possible to re-install the custom programs and save archived data if the system failed or the battery lost power.

UCD Principle 2: Measure Usability Empirically

Selecting Usability Factors to Empirically Measure

Factors that contribute to overall usability and how each may be measured during usability testing sessions are listed in Table 2. ^20,40-42 The factors should be measured empirically and repeatedly throughout the developmental process. The methods that are employed for testing and the criterion values that are used to determine whether each of the factors in Table 2 is met must be established a priori and applied uniformly with all test-users. In addition, several reliable and valid self-report measures are available to assess users’ ratings regarding such factors as satisfaction, ease and efficiency over time as the design evolves. ⁴³

Table 2.

Usability Factors and Empirical Measurements ²⁰, ⁴⁰-⁴²

Factors	Objective Measures	Subjective Measures
Learnability: ease with which use of device is learned so users can rapidly accomplish intended tasks	Clock time for new users to learn to accomplish the intended tasks	Users’ ratings of the ease and time to learn the system
Effectiveness: usefulness for supporting intended tasks	Successful performance of the intended tasks; measures of productivity	Users’ ratings of the system’s ability to promote their performance and productivity
Efficiency: productivity once users have learned the system	Clock time to accomplish the tasks once users have learned the system	Users’ ratings of the system’s ability to improve the speed at which they perform
Errors: low frequency, severity of errors and easy recovery	Error rates trying to use system; Severity of errors; Recovery time for errors	Users’ ratings of the impact of errors on using system and their ability to recover from errors
Flexibility: variety of ways to achieve intended tasks	Number of different commands or routes to achieve the same goal	Users’ ratings of system’s ability to provide different commands or routes to achieve the same goal
Memorability: ease with which casual users can return to the system without having to relearn	Memory failure rate on how to use system the next time; time to re-learn the system after periods of non-use	Users’ ratings of the ability to remember how to use the system the next time and their ability to re-learn the system after periods of non-use
User Satisfaction: pleasant for users	Frequency for utilization of the system and its features	Users’ ratings of their fondness, perceptions and opinions of the system and its features

Usability assessment reports, using a pre-determined format, were generated for all testing sessions and reviewed by the team. These reports allowed for direct comparisons between users to determine the nature, severity and frequency of any problems. Quantifying problems in these terms promoted better decisions about which usability problems would be given priority based on available time and resources. Typically, if 50% or more of participants had difficulty completing a task, then this feature was considered problematic and required attention. ⁴⁴ The threshold for modification was lower for some issues, for instance, usability problems that frustrated users or lead them to give up trying to perform a task.

Laboratory Evaluation

Three UCD sessions were conducted in a controlled, laboratory setting to obtain feedback from users on the acceptability and functionality of Pocket PATH. Design iterations were evaluated from the patient-users’ perspectives early and repeatedly. For the first usability testing sessions, low fidelity prototypes, sketches of interface elements on paper or printed screen shots of what the users would see and use, were used to get feedback regarding such features as the appearance of interfaces, syntax of commands, and the performance of simple tasks. Although these initial prototypes did not have all the functionality of the final product, some part(s) of the design were ready to be tested and could be developed and modified more quickly and inexpensively than the final version. In the process, we obtained feedback from users before we proceeded to the more expensive back-end programming activities. ⁴⁵

The human computer specialist students conducted the usability testing, but the PI, primary programmer and user interface designer observed all testing sessions. This collaboration was useful because we found the inclusion of experts led to multiple perspectives about recommendations and solutions. The personal contact with the users helped the team stay committed to developing a useful and functional product.

We experimented with videotaping the testing sessions, but abandoned this approach for several reasons. For example, users naturally tilted and repositioned the hand held device and stylus during use, but movement made it difficult to focus the camera on the screen. Additionally, it was not possible to aim the video recorder toward the screen and the user simultaneously. As an alternative to conventional videotaping, we relied on our observations, and screen-capturing techniques using Camtasia ® v 2.1 (TechSmith, Okemos, MI) with video and audio capabilities loaded on a lap top and synchronized to wirelessly record how the users made selections and navigated the system’s features on the handheld. This approach allowed the tester(s) to follow the users’ paths by viewing the handheld screen images on the laptop. The users were less conscious of being recorded, and both video and audio data were archived for further review and analysis of usability problems. The recordings were automatically time-stamped to facilitate tagging issues of concern. The issues and reactions of users could be easily compared, and selected screen images were ‘cut’ using SnagIt ® v 7.2 (TechSmith, Okemos, MI) software as examples for future inclusion in the user-training manual.

Users were given scenarios to simulate tasks they would perform at home with the device. They were encouraged to use think-aloud techniques and provide a running commentary of their thoughts while performing the intended tasks. Testing accomplished during session 1 included general device and self-monitoring features using primarily paper or prototype forms; session 2 included adherence and communication functions and any new modifications using the actual programs on iPAQ; and session 3 tested all features and functions. At the completion of each laboratory testing session, we administered a reliable and valid measure of user satisfaction, the After-Scenario Questionnaire (ASQ), ⁴⁶ a three-item survey for users to rate their satisfaction with ease, amount of time, and support information on a seven-point scale (lower scores ~ more satisfied). An overall ASQ score was obtained by averaging the scores of the three items. Mean ASQ scores (presented in Table 3) declined between session 1 (1.76 ± 0.85) and 3 (1.0 ± 0), demonstrating increasing user satisfaction with Pocket PATH over time.

Table 3.

Mean ASQ Scores After Each Laboratory Testing Sessions (N=7)

Items	Session 1	Session 2	Session 3
Ease of completing tasks in scenario	1.57 ± .78	1.25± .5	1± 0
Time to complete tasks	1.43 ± .78	1± 0	1± 0
Support when completing tasks	2.29 ± 1.3	1± 0	1± 0
ASQ Overall	1.76 ± .85	1.08 ± .16	1± 0

ASQ, After Scenario Questionnaire; ASQ scores range from 1-7 (lower scores = higher satisfaction).

The tapes were reviewed in combination with testers’ notes to reveal the potential source of errors and problems in order to inform future modifications. We rated the significance and priority of each problem and summarized the results using the usability assessment reports. The team discussed all reports and by consensus made decisions about future modifications. Using this process iteratively, design features were improved until requirements were met.

UCD Principle 3: Design and Test Usability Iteratively

Every stage of UCD includes testing and analysis, and these activities require looping back to earlier stages so that development occurs in iterative cycles of assessing-designing-testing-analyzing-refining-testing-analyzing-refining. ²⁰ UCD is a way to identify the real needs, reactions and behaviors of users as they interact with the system over the course of its design iterations until users deem it usable and functional. ²²

Field Study

After the laboratory evaluation, Pocket PATH was tested in the field to determine whether patients found it feasible to use independently in their homes and to assess the functionality of all of its features, including data recording, data display, and transmitting data to the study site. Only six of the patients tested Pocket PATH in their homes (the youngest original recipient volunteer expired before the field study). In addition to reviewing training on the use of the device, each patient was given an illustrated user manual describing all the features and a toll-free phone number to call for technical help. Each user was provided the device, charger and a CompactFlash modem v.90 (Hawking Technology, Irvine, CA) to transmit data to the study site remotely over the phone line. They were asked to record their measurements—daily spirometry values, blood pressure, pulse, symptom ratings, etc. The results were displayed on the iPAQ screen in both log and graphical display formats. Normal thresholds were set for each clinical parameter; feedback messages were generated when values outside the acceptable range were entered. Patients were also requested to make any suggestions for improving the user’s manual.

The data transmitted to the study site were reviewed to assess utilization of the features defined by the following indices: the percentage of features that users accessed, the number of ‘hits’ per feature, the percentage of daily measurements recorded and transmitted, and times users appropriately contacted their transplant clinicians when prompted to do so by automatic feedback messages. On average, Pocket PATH was used daily by the 6 participants over the 2 week study period. Each participant used the daily checklist, logs and graph features regularly. Normal thresholds were set for each clinical parameter; and feedback messages were generated when values fell outside the acceptable range. All of the field test users accessed the message history and notes feature at least once. They also responded to prompts to notify the transplant clinician for signs of potential problems. When the users uploaded data to the study site via the modem, all the data that patients entered into their devices, as well as any feedback messages they received, were flagged upon receipt at the study site. For example, one recipient was entering increasingly higher heart rates from her baseline pulse of 85 per minute to 100 beats per minute over a period of a week. Because the device was programmed to detect increasing trends within the short period of time, the device appropriately displayed a warning message indicating that she should report her rapid pulse to her transplant clinician. Based on this feedback, she contacted her transplant clinician to discuss proper treatment rather than waiting until her next appointment to report it. In total, the group entered approximately 1400 data values and sent data to the study site at least three times per week. Only one participant used the tech-help service; she phoned to make sure that she was uploading her data successfully. One investigator-initiated call was made to another participant when no data were uploaded for the first 3 days. After reviewing the procedure with her, we discovered that she had been omitting a step in the active synchronization procedure; her data uploads were successful from then on.

Final Evaluation Session

Following the field study, the six test users returned to the study center to test the final version of Pocket PATH and provide feedback as they evaluated its features (see Figure 1 for one screen shot from the daily checklist feature). At the end of this session, we also administered another reliable and valid measure, the Post-Study System Usability Questionnaire (PSSUQ). ⁴⁷ It was specifically designed for use at the completion of usability studies. The PSSUQ assessed overall user satisfaction with 17 aspects of the system and interface, using the same seven-point scale as the ASQ (lower scores = higher satisfaction; possible range = 1-7). The final PSSUQ scores (presented in Table 4) revealed that the test users were highly satisfied with Pocket PATH (mean scores 1.05 +.10). They also expressed appreciation for the opportunity to be involved in the development process.

Figure 1.

The Daily Checklist feature of Pocket PATH is comprised of screens for patients to enter personal health data (e.g., vital signs, symptoms and lab results) with links to graphical display screens.

Table 4.

Mean PSSUQ Scores After the Field Study (N=6)

Items	M± SD
1.Easy to use system	1± 0
2. Simple to use system	1± 0
3. Effectively complete tasks &scenarios	1± 0
4. Quickly complete tasks & scenarios	1± 0
5. Efficiently complete tasks & scenarios	1± 0
6. Comfort using system	1± 0
7. Easy to learn to use system	1± 0
8. Believe could become productive using system	1± 0
9. Error messages were clear	2.0 + 1.7
10. Easily recover from mistakes	1± 0
11. Information about system was clear	1± 0
12. Easy to find needed information	1± 0
13. Easy to understand information	1± 0
14. Information helped complete the task	1± 0
15. Information was clearly organized	1± 0
16. Interface was pleasant	1± 0
17. Enjoyed using interface	1± 0
PSSUQ Overall	1.05 +.10

PSSUQ, Post-Study System Usability Questionnaire, PSSUQ scores range from 1-7 (lower scores = higher satisfaction).

Summary

Pocket PATH is comprised of custom features that supplement the standard personal organizer features of the iPAQ, including data entry, graphical displays, reminders and feedback messages about information considered central for self-monitoring after lung transplant. These behaviors are crucial in order for lung transplant patients to be actively involved in the interpretation and decision-making processes of tracking their health related data and communicating changes to clinicians appropriately and promptly.

Keeping our focus on the tasks and users throughout the development process helped reduce the risk of designing an IHT application that was based entirely on what we considered important and useful rather than what the patient-users thought would assist with self-monitoring activities. We applied the principles of UCD, and employed a variety of usability-testing techniques to evaluate the effectiveness of screen designs, functions, navigation paths, labels, and other elements of the interface with representative users. Data from iterative testing informed modification and refinement of the application. When the prototype was deemed useful and functional in the laboratory setting, it was further tested in the field. As other studies have shown, involving users throughout the entire development process ensures that the final IHT is functional and acceptable as soon as it is ready to be deployed. We applied the principles of UCD to involve patient-users in the development of Pocket PATH, therefore increasing the likelihood of enhancing its success in promoting self-monitoring activities after lung transplant. Based on our results, applying UCD to the development of IHTs intended for use by other patient populations will assure that users’ needs and expectations are met.

We subsequently conducted a randomized-controlled pilot trial and determined that newly transplanted patients found Pocket PATH superior to conventional methods for self-monitoring after transplantation. ⁴⁸ A full-scale randomized controlled trial is now warranted to rigorously test the efficacy of Pocket PATH in promoting self-monitoring and to determine the impact of Pocket PATH use on long-term transplant-related health. Furthermore, patients need to be involved in the ongoing evaluation of Pocket PATH to obtain user feedback regarding the utility and functionality of Pocket PATH overtime.