Abstract
Participatory design, a method by which system users and stakeholders meaningfully contribute to the development of a new process or technology, has great potential to revolutionize healthcare technology, yet has seen limited adoption. We conducted a design session with eleven physicians working to create a novel clinical information tool utilizing participatory design methods. During the two-hour session, the physicians quickly engaged in the process and generated a large quantity of information, informing the design of a future tool. By utilizing facilitators experienced in design methodology, with detailed domain expertise, and well integrated into the healthcare organization, the participatory design session engaged a group of users who are often disenfranchised with existing processes as well as health information technology in general. We provide insight into why participatory design works with clinicians and provide guiding principles for how to implement these methods in healthcare organizations interested in advancing health information technology.
Introduction
Over the past 20 years, and accelerated by the introduction of the Health Information Technology for Economic and Clinical Health (HITECH) Act1 in 2009, healthcare organizations in the United States have been rapidly adopting health information technology to improve the delivery of health care and reduce medical spending. However, implementing and deploying successful informatics solutions in clinical settings has proved challenging.2 Managers and other C-suite hospital executives often have an incomplete knowledge of the detailed operational workflows the system must support. Thus the primary decision makers often make design choices that are inefficient for end users.
Researchers in the field of Human-Computer Interaction have long advocated participatory approaches to system design, in which end users play an active role in the design process, and user-centered design occurs from the beginning of the design cycle. Traditionally, user input or usability testing happens at the end of system development, or at least after major requirements and feature decisions have been set. Health information technology has tended to follow a similar process.3 But within the human-computer interaction community, methods that involve users at earlier stages of the design process are increasingly popular: the earlier users are involved, the more likely it is that the end product will meet their needs. In one such method, Participatory Design (PD), the eventual users of a system contribute to its design in even the most formative stages.4 PD was first developed in Scandinavia in the 1970s as a reaction to the disruptive introduction of computers into the workplace. Those people most affected by information technology—the workers whose jobs were being transformed or even eliminated—had little input into how their information systems were designed, and little power to enact change.5 Participatory design emerged from this context as a set of methods and practices that allow groups of non-designers to engage in discussions around information technology, to develop and refine prototypes, and to express their values with respect to the technology that affects their lives.
Can such approaches work within an existing clinical context? Further: can a hospital involve its own clinicians in designing health related technology? PD has been successfully employed in a wide variety of populations and topics, from marginalized teens6,7 to civic engagement8, even the delivery of healthcare it self9, and is a commonly used technique in Human-Computer Interaction research. PD has also shown promise in the design of healthcare technology, where it has been most frequently employed in the design of patient-facing technology.10 However, given PD’s origins in workplace systems, surprisingly few researchers have used PD to inform the design of clinician-focused systems. Gennari and Reddy introduced the technique to the American Medical Informatics Association community in 2000 in a paper describing the design of a clinical trial protocol management system; however, their paper focused more on interviews and contextual inquiry than on PD workshops as a technique.11 More recently, Kusunoki and Sarcevic, functioning in the role of outside consultants, used PD to inform the design of emergency room awareness systems, including the PICTIVE technique we discuss in this paper.12 Despite the success of these studies, PD work with clinicians has yet to take hold within the Medical Informatics community and little is known about how PD translates into measurable success for health information technology.
In this study, we asked physicians to participate in the design of a novel clinical prioritization tool utilizing PD methods. Our goal was to explore how physicians engage in the PD process and demonstrate their effectiveness in the design of clinical information tools. In previous work, we identified and modified an existing framework, knowledge crystallization,13 to frame and understand how physicians collect, process, and utilize data during the clinical prioritization process (i.e. identifying individual patients that need attention first).14 The framework demonstrated that clinicians collect data to categorize and prioritize patients according to an expected clinical course. However, when data does not support their expectations, or when categorization indicates potential for morbidity, physicians increase efforts to act or re-categorize patients. Unexpected clinical changes have a significant impact on the decision-making and prioritization by clinicians. With this foundation, we asked physicians to design a tool to help them with this specific task. In this paper, we identify the factors leading to a successful PD session with physician participants, describe challenges that we experienced, and ultimately provide a series of guiding principles for future physician-focused PD work.
Methods
We conducted an IRB-approved, two-hour participatory design workshop at Seattle Children’s Hospital, located in Seattle, Washington in early 2015. Participants worked individually and in groups to answer the motivating question “Which patient should I see next?”
Recruitment
To be included in this study, we required that physicians be credentialed at either the attending (supervising physician) or fellow (sub-specialty trainee) level, and that they provided acute clinical services to hospitalized patients. The primary author (AP) sent individual emails to 23 different providers at the study site, inviting their participation. We targeted a diverse audience with regards to gender, medical specialty, academic rank, and clinical experience. Given the professional relationships between AP and the medical staff, we identified individuals who we felt would make a positive and significant contribution to our PD session.
Our roles
Three researchers attended the workshop. The first author contacted participants, gave the opening presentation, guided the brainstorming session, and supervised the design activities, asking questions and offering guidance as needed. The other two researchers took notes and photos, documenting groups’ progress and social dynamics. The entire research team provided input on the format and organization of the session.
Session design
We utilized the PICTIVE participatory design technique to provide an environment that supports equal opportunities for a diverse set of participants to engage in the design process.15 First developed in 1991, the PICTIVE technique was intended to allow those with limited design experience and expertise to have “equal opportunity to contribute their ideas.” Sessions begin with brainstorming activities, designed to stimulate thought and create a dialog between participants, then followed by activities that allow the ideas to be physically expressed through the use of low-tech objects to support the creative process. This process ensures that all are able to contribute their ideas in a meaningful way. While PICTIVE explores the needs of users at a more detailed level, it doesn’t focus on workflow or other system level processes that may support the specific task at hand. Other PD methods, such as CARD, were developed to fill this gap, with the intent to help analyze and design workflows used in software systems.13 Given our previous work14 detailed the workflows of physicians for our specific task we asked physicians to focus on, PICTIVE was selected over other participatory design techniques such as CARD given the former’s emphasis on participant generated designs and less on collaborative analysis and workflow.
Materials
We provided a set of craft supplies to aid participants in creating their designs. Participants were able to make use of colored paper, stickers, pom-poms, pipe cleaners, glitter glue, scissors, glue guns, markers, and colored pencils in their designs. Each group was also provided with a foam core board on which they could mount their final design for presentation.
Design workshop overview
We conducted the session in the early evening to maximize participant availability, and provided a boxed dinner for each participant. Before the workshop, we divided participants into three groups: two groups of four, and one group of three. In selecting the groups, we looked for a diversity of experiences and seniority levels. For example, we tried to avoid creating groups where one person was in a group with his or her supervisor. We used participants’ boxed dinners as place cards; as participants arrived each one sat at their group’s table and socialized before we began the main design activity.
The workshop began with a PowerPoint presentation. The lead author introduced the study, gave an overview of our previous work, and presented participants with the motivating question: “What patient should I see next?” Participants then began the individual brainstorming portion. We asked participants to write down, on notecards, what information they would need, when they would want it, why they would want it, and where they would want it. Participants worked individually for approximately 10 minutes, and then participated in a group brainstorming discussion for the next 20 minutes. We recorded participants’ suggestions on a whiteboard so they could refer to their ideas during the hands on design portion of the workshop.
We then introduced the design challenge and constraints (Table 1). We encouraged participants to use the craft materials and allowed them to divide their time as they wished. Periodically during the design phase, the first author discussed groups’ thoughts and progress with them. In this design review, we sought not to shape participants’ designs but to elucidate their thought processes and stimulate intragroup discussion. In the last 20 minutes of the workshop, participating groups presented their designs to each other.
Table 1.
|
Data
We collected various types of data in this exercise. We audio-recorded the entire workshop, using smartphones running voice recorder apps at each group table. We also video-recorded the final presentations. One researcher took detailed ethnographic field notes of the entire session, while another researcher alternated between taking notes and taking photographs of groups’ progress. We collected and scanned individual brainstorm cards, and photographed the whiteboard with the brainstorm ideas on it. We collected the artifacts used in the presentations. Finally, the first author had a number of informal conversations with participants in the days following the workshop.
Analysis
Immediately following the workshop, the researchers held a debrief session amongst themselves. We discussed our perceptions of the workshop and proposed initial themes and observations to each other. We listened to the audio recordings and produced a more fine-grained analysis of each group’s work process. We looked particularly for power dynamics within the groups and key ideation points where groups made decisions or shifted phases. We also combined our field notes, notes from the audio-recordings, and photographs of the design sessions to generate a narrative about each group’s progress. Several days after the workshop, we met to share these analyses and refine themes. Finally, we explored each design through a standardized coding tool that had six prompts: (1) What does the design look like, (2) What info is included, prioritized, seen in other designs?, (3) What does the tool do?, (4) What information is missing?, (5) Any new ideas?, (6) How does the design tie back to the original framework?
Results
Participants
We recruited 11 physicians (five females) representing six different medical specialties (Table 2). Five of the subjects had participated in our previous study and therefore had some previous exposure to the topic. We divided the subjects into three groups, two groups of four and one group of three and they sat with their respective groups during all segments of the design session.
Table 2.
Group 1 | Group 2 | Group 3 | |
---|---|---|---|
Participants (Female) | 3 (1) | 4 (2) | 4 (2) |
Medical Specialties | Craniofacial | Clinical Informatics | General Medicine (2) |
General Pediatrics | General Medicine | Infectious Disease | |
Infectious Disease | Nephrology Rheumatology |
Nephrology | |
Academic Rank | Assistant Professor | Fellow | Assistant Professor (2) |
Associate Professor (2) | Clinical Instructor Assistant Professor Associate Professor |
Professor (2) |
Overall Session Output
During the individual brainstorming session (approximately 20 minutes), ten subjects (one subject arrived late and did not participate in this phase of the session) generated 47 ideas representing approximately 20 different topics or concepts. Individual subjects generated on average 4.7 ideas each (range 3 – 7). Some subjects needed additional clarification and an example to begin the exercise while others had no trouble with the original instructions. When asked to share their individual ideas the most senior physicians spoke up first with the younger physicians contributing later during the discussion, though eventually all subjects participated and spoke up during the group brainstorming session (approximately 20 minutes). This subsequent discussion covered 20 topics or concepts of which 10 were new and not documented during the individual process, suggesting that the group discussion supported the generation of new, more complex ideas (Figure 1).
The sketching and prototyping session lasted for approximately 50 minutes. During this time, groups one and two immediately began working collaboratively generating ideas, while group three started working individually and eventually worked as a group. Despite the productivity and diversity of ideas generated in the brainstorming segment, the prototyping and sketching segment generated far fewer concepts with groups one and two only coming up with one design concept and group three generating four different ideas which could be subdivided into two main concepts. The disparity between groups correlates with each group’s initial process of individual or group brainstorming with the former leading to more design concepts. However, overall each group generated a unique design concept, with each one differing from the others (Figure 2).
Prototyping Process
Two groups (Groups 1 & 2) began the prototyping session brainstorming together as a group and the third group began working independently and then eventually came together as a group to discuss their individual ideas. Interestingly each group had a slightly different process (Figure 3) that led to the generation of their final design concept. Despite this variation all three groups settled on their final design concept relatively early in the prototyping session and spent the rest of the time iterating and flushing out the design. All three groups had articulated their design concept prior to formally discussing the various requirements and data elements of the tool itself. Once the design had been articulated, the teams explored the data it could potentially present, how users could interact with it, and the goals it would accomplish. The teams spent much of their time discussing these various requirements in no specific order, cycling between the topics and requirements looping back to their design, and repeating for the duration of the prototyping session. With each iterative conversation clarifying their concept as well as the problem the design addressed, and ultimately moving the group closer towards their final design.
A significant portion of the group design time was spent discussing various visual encoding strategies and how best to represent different data elements. The most common strategies discussed were color, size, position, and iconography. Similar to the primary design concept, once an encoding strategy was presented there was limited debate within the group if other strategies had better visual potential. Most of the discussion instead surrounded what data could be presented by the specific encoding method chosen that supported the overall design concept and framework.
All three groups explored familiar technological tools and applications, including both medical and non-medical references, which led to a significant influence on their final design. The largest influence, modern multi-touch devices, provided some of the most fundamental functional requirements for each team. In fact, we observed on multiple occasions the participants attempting to interact with their design as if it were a functional multi-touch tablet device, touching or swiping with their fingers. In addition to the interaction, design inspiration came from various smart phone applications including those focused on weather, social media, and other productivity tools. Finally, groups also turned to more familiar medical application tools, such as the current electronic medical record used at the study site and even flow cytometry. Groups had no trouble finding inspiration to help guide their overall design process.
In the second half of the prototyping session, once each group had a strong idea of their final design concept, the primary author (AP) went to each group asking them to discuss their design. Through open-ended as well specific questions, this interaction often uncovered an incomplete design or even idea. For example, in response to the question: “How does the tool highlight this important piece of information?” it wasn’t uncommon to hear the response: “Oh, I hadn’t thought about that yet” or “That’s a great question, we still need to figure that out!”
In addition, AP discussed with each group the potential advantages and disadvantages of the different encoding strategies utilized in the various designs. Teams were asked if they had (1) recognized the advantages and disadvantages of different encoding strategies and once recognized (2) if they had any concerns with their choices. Despite the groups employing encoding strategies with less precision than other techniques (e.g. area vs. length), we uncovered the motivation behind the encoding, and more importantly why they needed the data or information for their specific task.
Individual Participation
All individuals participated in the design session, contributing in all phases of the study. However, the senior physicians dominated the discussions in two of three groups as well as the group interaction. This influence was apparent in both the overall discussion as well as the design decisions individual groups made during the process. At no time did any of the researchers overhear or observe any behavior or actions exhibited by any of the physicians that could have been interpreted as creating a power hierarchy within a group. However, Group 1, which had the least variability in terms of participant seniority, had the highest level of equality regarding the degree of individual participation. As the discussion behind the design concept came to a conclusion and the groups transitioned to actually producing their final design drawings, participation within all the groups became more equally distributed.
Finally, two of the physicians had clinical responsibilities during the design session, which led to repeated interruptions, at times leaving for more than 5 minutes at a time. After returning, these two participants had potentially missed critical discussions and decisions, and had to spend time getting themselves caught up with the rest of the group.
Discussion
The physician participants in our study not only identified valuable information to help design a future information tool used within the hospital setting, they also provided great insight into utilizing participatory design methods with a group of domain experts. Under the appropriate conditions, our physician designers demonstrated the effectiveness of PD as a design method, showing its potential to improve the technology utilized in healthcare organizations. In our discussion, we describe why PD works with physicians, some of the challenges we experienced and finally go on to identify a set of guiding principles for physician focused participatory design sessions.
Showing Knowledge-in-Action
Initially the brainstorming session might have been too vague for some participants, with a few needing additional instruction and direction. However, once started, the group maintained significant momentum carrying it forward allowing seamless transitions between activities. In addition, the warm up activity allowed the participants to become comfortable with each other as well as the design challenge itself. Given the number of unique and overlapping ideas as well as the speed at which they were generated, participants indirectly expressed their clear motivation to improve and advance the current state of health information technology.
During the brainstorming activity, participants generated many inter-related ideas quickly. Participants’ facility with the idea generation aspect of PD also demonstrates the high level of domain knowledge of our expert end users. The physician designers quickly and easily articulated their needs responding and building off each other’s ideas. Schon refers to this as “knowing-in-action,” which he defines as “the sorts of know-how we reveal in our intelligent action, publicly observable…like riding a bicycle and private operations like instant analysis of a balance sheet. In both cases, the knowing is in the action. We reveal it by our spontaneous, skillful execution of the performance, and we are characteristically unable to make it verbally explicit.”16 The physician designers’ ability to generate design concepts without first needing to develop functional requirements or explicitly stating a use case clearly supports the theory. Our designers used their implicit knowledge of their practice patterns and information needs to generate their initial design concepts. Through the PD process they had to explain and further expand on their original idea, unpacking their expertise and making it explicit. Not only did PD uncover and expose the underlying process of clinical prioritization, it also forced the participants to step back and reflect on their current practice ultimately defining their true needs. The activity required them to ask questions of their workflow and clinical processes that under regular circumstances do not require a significant amount of cognitive processing to execute as expert practitioners.
Throughout the session, participants engaged in progressive iteration, building off of their initial design concept as they worked. In some ways, participants’ approach resembles the practice of agile software development. Agile software development is a process “in which requirements and solutions evolve through collaboration…It promotes adaptive planning, evolutionary development, early delivery, continuous improvement, and encourages rapid and flexible response to change.”17 Each of our groups followed a similar process where they generated an idea, iterated and brainstormed on that idea, ultimately incorporating it into their design, and then repeating this process for the duration of the design period. It is interesting to note that no groups followed a more traditional waterfall approach where specific requirements are identified and settled upon before moving onto the next phase of the design process. It is unclear if this relates back to their expert status, the participatory design process, or just their excitement to create and engage in the process, but the results clearly suggest agile methods as a successful tool for generating ideas with this population of experts.
Becoming PD-atricians
The authors of this paper have collectively conducted and observed dozens of participatory design workshops over the years. One of us has considerable experience working with patients as designers, and another has conducted workshops with youth and teens. But the physicians in this study were a different breed. In some areas, they outperformed our expectations. For example, given relatively little guidance, participants in our study were able to generate sophisticated ideas during the individual brainstorming phase, and synthesize those into broad concepts during the whiteboard discussion. We were particularly struck by how little time and effort each group devoted to picking a design concept. In our experience with non-physician participants, participatory design groups will often spend significant time in this phase, trying out different design concepts and playing with the craft materials as a way to express competing ideas. With our physician designers, the opposite happened. Groups settled on an idea relatively quickly, and then used the materials as a way to realize their vision and express it for presentation. While selecting a single idea early certainly allowed participants to create more in-depth designs, we missed the opportunity to hear additional concepts and ideas from participants as most groups did not discuss and debate different design ideas.
In their professional lives, our participants are frequently called on to synthesize data and quickly reach intuitive conclusions. They are often asked to improvise a solution based on limited data, but rarely called upon to design something or engage in blue-sky thinking. They are practitioners, and are used to working on deadline. Indeed, some of the effects we described above may simply arise from participants’ awareness of the tight schedule of the design session, and their desire to ensure they had something to present. Finally, the physicians were articulate presenters and offered collegial and supportive critique.
Nevertheless, our study shows that participatory design with physicians can work well, provided the workshops themselves are designed with physicians in mind. Brainstorming and ideation can be accomplished successfully with relatively little guidance, provided the intended design is one that meets physicians’ current needs and experiences. Designs may not shift dramatically from early concepts, but a participatory design exercise can still capture value through surfacing physicians’ priorities. The participants were clearly engaged by the exercise and very motivated to solve real information challenges they experience while providing clinical care to their patients.
Recognizing Challenges and Constraints
Despite the overall success of the design session, we also experienced several challenges. We had no trouble finding interested participants; instead, we had difficulty finding a time to conduct our two-hour design session that fit into the busy schedule of our physician designers. Initial efforts to conduct a session during regular office hours failed to find a time that worked for multiple participants. Therefore, we elected to hold an evening dinner session, scheduled one month in advance, which made it much easier for our physician designers to participate. In addition, because we conducted the session after hours, participants seemed to have fewer distractions (checking their email) and less time constraints. In the end, the timing of our session allowed the participants to free themselves of their usual routines and fully immerse themselves in the design process.
Organizing the design sessions, within the two-hour time constraint, had its own challenges. We needed to ensure adequate time for brainstorming, designing, sharing, and ultimately feedback. Even though the design exercise took up over half of the entire session, having more time might have benefited both the physician designers as well as the research team. We asked that the physician designers produce one final design concept for each group, but did not put any methodological constraints on how to reach that final design. As we described, the teams settled on their design relatively early and refined the concept for the majority of the session. Rapid serial iteration has been shown to increase the diversity of design concepts leading to more successful products.18 In addition, producing multiple alternative ideas in parallel encourages designers to uncover previously unnoticed constraints and identify new opportunities.19,20 Unfortunately, given the time constraint of the session, we did not require or even encourage the physician designers to develop multiple ideas in parallel. Even Group Three, which spent time individually brainstorming ideas, only focused their efforts on a single design. In addition, people are more likely to provide more honest and critical feedback when they present and are presented with multiple designs versus single ideas.21 When our physician designers shared their final concepts, the other teams for the most part provided positive feedback with very little constructive criticism.
Along these lines, social dynamics also influenced individuals’ desire and comfort to provide constructive feedback. We clearly saw the influence of social dynamics and professional hierarchy play out during other parts of the session. Senior physicians typically spoke first, for longer periods of time, and often led the conversation in each of the groups. When assembling the groups, we attempted to minimize this phenomenon, though we had limited success. In addition, the groups that exhibited more obvious participation discrepancies tended to delegate the less cognitive tasks to the more junior physicians. With idea generation one of the primary goals of participatory design, it is important to understand and recognize the role social dynamics might play in influencing productivity within a group of physician designers.
The final issue we encountered concerned the actual designs themselves. Because the physician designers had no or limited design experience, some of their designs incorporated visual encoding strategies that went against well-defined best design practices. Designs attempting to communicate large volumes of numerical information should leverage the innate ability of our visual system to recognize certain information without any higher-level cognitive input.22,23 Pre-attentive processing allows for rapid interpretation of visual information with the proper framing and organization of the information. Size has the potential to communicate information rapidly, leveraging pre-attentive processing, though only when done correctly. For example, it is much easier to recognize size discrepancies along a single dimension, such as length versus a difference found in two or more dimensions, such as area (Figure 4). Some of the final designs produced during the prototyping session utilized differences in size along two dimensions (i.e. area) to communicate differences in scale. As designers we immediately recognized the potential limitation of this encoding strategy, though when pressed the physician designers seemed less concerned. However, while the physical designs created during the PD sessions have their place in the final design, more important are the ideas, values, and needs expressed by the non-expert designers. The output of participatory design is not a final design specification, but rather information for an expert designer to use when designing the final product, taking into consideration the physical design as well as the needs and requirements identified during the design session by the domain experts.
Engaging PD-atricians
When we step back and evaluate our own process, the PD session, as well as the actual content generated, we identified an underlying theme that led to the overall success of our work. Having a facilitator with a detailed understanding of the organization, domain expertise in the clinical context as well as human centered design methods allowed us to tailor and adapt the sessions to ensure they achieved the desired outcomes. With this knowledge, we identified a motivating challenge and recruited participants with the potential to make a meaningful contribution to the PD process. In addition, since the lead author was a peer of the session participants, it allowed them to trust this new, unfamiliar process and engage them in way that would not have been possible without the professional connection. Therefore, organizations investing in HIT and a desire to employ PD methods need to ensure they have informatics professionals with these diverse skill sets and established interpersonal relationships.
Guiding Principles for Future PD-atricians
Given the high costs associated with health information technology system failures, organizations need to take the time required to ensure the technology leads to the desired benefit and not introduce any harm.24,25 Although some researchers have described the economic benefits of iterative design26 and others have clearly demonstrated its rigor,27 many organizations simply undervalue its potential. For less than $500 (costs associated with this PD session), we now have a solid foundation to begin the design process. In addition, by engaging physicians in this process, not only do we gain their valuable insight, but also their interest in seeing the successful deployment of the tool as they are now partial owners of its ultimate success. In order to support others as they pursue participatory design methods to help advance health information technology, we offer a series of guiding principles developed from our presented experiences (Table 3).
Table 3.
|
In addition to the principles and ideas previously discussed, it is important to ensure that appropriate subjects are selected to participate in the PD session. Ideally, the organizers want to find those who are interested and acknowledge the existence of the challenge or problem. Participants need to have good communication skills, be open to feedback, and be willing to engage in the design process, as well as domain expertise. While it is important to have a diverse group of participants, session organizers need to consider the potential for these differences to negatively influence the group’s performance. Therefore, playing close attention to how the groups are structured should help to minimize any negative group dynamics.
Besides needing a diverse group of participants, it is just as important to have a diverse team facilitating the PD session. In the medical setting, the team needs to have knowledge and expertise not only in PD and design principles, but also the domain itself. Having these backgrounds allows the facilitators to ask directed and focused questions with the intent of pushing the participants to expand their thinking and ultimately their designs. The diversity of our backgrounds allowed us to form questions based on both the domain content as well as design aesthetics. Our team also had the benefit of our primary author being a physician and peer of the session participants, with a proven track record of improving the clinical information tools at the study location. The personal connection with each of the participants improved our recruiting capabilities as well as lead to increased engagement.
Limitations
Despite the diversity of medical providers within our sample, all of the participants were pediatricians at a single organization. In addition, Seattle Children’s Hospital supports the active engagement of its medical providers and encourages their participation in continuous process improvement activities. Therefore, they are very familiar with identifying system challenges and working collaboratively and iteratively towards consensus driven solutions. These factors might limit the generalizability of our study since physicians at other organizations may be less familiar with these organizational processes. However, given PD methods support non-experienced designers in the creation process, it should minimize these concerns.
In addition, we need to recognize the fact that only 11 individual physicians participated in a single PD session. While this also raises questions about generalizability, we feel our findings still provide insight into a process with genuine potential. Strauss and Corbin, describe the value of recognizing both the messages or theories derived from qualitative work, as well as the situation and conditions from which the theory was derived.28 Therefore, with the provided descriptions of our methods and institutional culture, others can use our work as a starting point and adapt it to fit their own organization.
Conclusion
Participatory design, a method well known to the Human-Computer Interaction community, has the potential to significantly enhance and improve the development of health information technology. Shifting design activities that involve end users to earlier in the development process should lead to applications that better meet the needs of stakeholders. Though it has seen limited adoption in the healthcare community, we have demonstrated its potential to make significant contributions. Utilizing well-described methods, we provide a series of guiding principles to engage physicians in designing new clinical information tools through participatory design. Organizations need to invest in human centered design methods such as PD by training their existing informatics professionals. Utilizing practicing clinicians with experience in Human-Computer Interaction, informatics, and deep domain expertise, project teams can build trust with typically skeptical end users leading to active participant engagement, translating into more successful projects.
References
- 1.HITECH Act Enforcement Interim Final Rule [Internet] hhs.gov. [cited 2016 Mar 9]. Available from: http://www.hhs.gov/hipaa/for-professionals/special-topics/HITECH-act-enforcement-interim-final-rule/index.html.
- 2.Bonnie Kaplan KDH-S. Health IT Success and Failure: Recommendations from Literature and an AMIA Workshop. J Am Med Inform Assoc. American Medical Informatics Association. 2009 May 1;16(3):291–9. doi: 10.1197/jamia.M2997. [DOI] [PMC free article] [PubMed] [Google Scholar]
- 3.Yen P-Y, Bakken S. Review of health information technology usability study methodologies. J Am Med Inform Assoc. 2012 May;19(3):413–22. doi: 10.1136/amiajnl-2010-000020. [DOI] [PMC free article] [PubMed] [Google Scholar]
- 4.Muller MJ, Kuhn S. Participatory design. Commun ACM. ACM Request Permissions. 1993 Jun;36(6):24–8. [Google Scholar]
- 5.Kensing F, Blomberg J. Participatory Design: Issues and Concerns. Computer Supported Cooperative Work. Kluwer Academic Publishers. 1998 Jan;7(3-4) [Google Scholar]
- 6.Fisher KE, Bishop AP, Magassa L, Fawcett P. Action!: codesigning interactive technology with immigrant teens. New York, New York, USA: ACM Request Permissions; 2014. pp. 345–8. [Google Scholar]
- 7.Nicholas M, Hagen P, Rahilly K, Swainston N. Using participatory design methods to engage the uninterested. ACM; 2012. [Google Scholar]
- 8.DiSalvo C, Nourbakhsh I, Holstius D, Akin A, Louw M. The Neighborhood Networks project: a case study of critical engagement and creative expression through participatory design. Indiana University; 2008. [Google Scholar]
- 9.Clemensen J, Larsen SB, Kyng M, Kirkevold M. Qual Health Res. 1. Vol. 17. SAGE Publications; 2007. Jan 1, Participatory Design in Health Sciences: Using Cooperative Experimental Methods in Developing Health Services and Computer Technology; pp. 122–30. [DOI] [PubMed] [Google Scholar]
- 10.Skeels MM, Unruh KT, Powell C, Pratt W. CHI Conf Proc. New York, New York, USA: ACM Press; 2010. Catalyzing Social Support for Breast Cancer Patients; pp. 173–82. [DOI] [PMC free article] [PubMed] [Google Scholar]
- 11.Gennari JH, Reddy M. Participatory design and an eligibility screening tool. Proc AMIA Symp; 2000; pp. 290–4. [PMC free article] [PubMed] [Google Scholar]
- 12.Kusunoki D, Sarcevic A, Zhang Z, Yala M. Comput Supported Coop Work. 1. Vol. 24. Springer Netherlands; 2014. Jul 22, Sketching Awareness: A Participatory Study to Elicit Designs for Supporting Ad Hoc Emergency Medical Teamwork; pp. 1–38. [DOI] [PMC free article] [PubMed] [Google Scholar]
- 13.Card SK, Mackinlay JD, Shneiderman B. Readings in Information Visualization: Using Vision to Think. Morgan Kaufman Publishers, Inc; 1999. [Google Scholar]
- 14.Pollack AH, Tweedy CG, Blondon K, Pratt W. AMIA Annu Symp Proc. Vol. 2014. New York, New York, USA: ACM Press; 2014. Knowledge crystallization and clinical priorities: evaluating how physicians collect and synthesize patient-related data; pp. 1874–83. [PMC free article] [PubMed] [Google Scholar]
- 15.PICTIVE—an exploration in participatory design [Internet] New York, New York, USA: ACM; 1991. p. 7. Available from: http://portal.acm.org/citation.cfm?doid=108844.108896. [Google Scholar]
- 16.Schon DA. Educating the reflective practitioner: toward a new design for teaching and learning in the professions. 1. San Francisco: Jossey-Bass; 1987. p. 1. [Google Scholar]
- 17.Larman C, Basili VR. Iterative and incremental developments. a brief history. Computer [Internet] 36(6):47–56. Available from: http://en.wikipedia.org/wiki/Agile_software_development. [Google Scholar]
- 18.Dow SP, Heddleston K, Klemmer SR. The efficacy of prototyping under time constraints. New York, New York, USA: ACM Request Permissions; 2009. p. 165. [Google Scholar]
- 19.Buxton B. Sketching user experiences: getting the design right and the right design (interactive technologies) Morgan Kaufman; 2007. [Google Scholar]
- 20.Dow SP, Glassco A, Kass J, Schwarz M, Schwartz DL, Klemmer SR. ACM Transactions on Computer-Human Interaction (TOCHI. 4. Vol. 17. ACM; 2010. Dec 1, Parallel prototyping leads to better design results, more divergence, and increased self-efficacy; pp. 18–24. [Google Scholar]
- 21.Tohidi M, Buxton W, Baecker R, Sellen A. the SIGCHI conference. New York New York, USA: ACM; 2006. Getting the right design and the design right; p. 10. [Google Scholar]
- 22.Treisman A. Preattentive processing in vision. Computer Vision, Graphics, and Image Processing. 1985 Aug;31(2):156–77. [Google Scholar]
- 23.Healey CG, Booth KS, Enns JT. Transactions on Computer-Human Interaction (TOCHI) 2. Vol. 3. ACM Request Permissions; 1996. Jun, High-speed visual estimation using preattentive processing; pp. 107–35. [Google Scholar]
- 24.Han YY, Carcillo JA, Venkataraman ST, Clark RSB, Watson RS, Nguyen TC, et al. Unexpected increased mortality after implementation of a commercially sold computerized physician order entry system. Pediatrics. 2005 Dec;116(6):1506–12. doi: 10.1542/peds.2005-1287. [DOI] [PubMed] [Google Scholar]
- 25.Del Beccaro MA, Jeffries HE, Eisenberg MA, Harry ED. Pediatrics. 1. Vol. 118. American Academy of Pediatrics; 2006. Jul, Computerized provider order entry implementation: no association with increased mortality rates in an intensive care unit; pp. 290–5. [DOI] [PubMed] [Google Scholar]
- 26.Erdogmus H. IEEE Software. 6. Vol. 22. IEEE Computer Society Press; 2005. Nov, The Economic Impact of Learning and Flexibility on Process Decisions; pp. 76–83. [Google Scholar]
- 27.Austin R, Devin L. Artful making: what managers need to know about how artists work. First. FT Press; 2003. Apr, Artful making: what managers need to know about how artists work, First edition. [Google Scholar]
- 28.Corbin JM, Strauss AL. In: Basics of qualitative research : techniques and procedures for developing grounded theory. Corbin JM, editor. Thousand Oaks: Thousand Oaks: Sage Publications; 1998. [Google Scholar]