Make it work designers, make it work
Project Runway’s dear Tim Gunn may have the best phrase for the HIT Squad at this moment. Jia Liu has covered the research philosophy of the team since our project begun. Yet, these ideas, conversations, and insights don’t come from thin air. They come about by establishing key design artifacts most appropriate for uncovering how EMR training could improve user satisfaction and mastery.
What’s in a name? Differentiating design artifacts from tools.
Before I breakdown what we used, let’s first understand the difference between a design tool and design artifact. A design research tool is the method employed to undercover insights and expand understanding of the industry and users you want to create a specific experience for. Meanwhile, a design artifact is the physical (or digital) manifestation of synthesized research. It pulls together the commonalities of your research and exposes any gaps so that your team can better determine your areas of exploration and in essence, design opportunities.
HIT Squad’s approach
What has made up our research mainly consists of user interviews — industry experts, EMR users, and AllScripts employees — as well as client collateral and product exploration for primary research. Secondary research largely came from content provided by the Centers for Medicare & Medicaid Services, white papers from EMR vendors, and commentary from HealthIT News.
To get to the insights, we knew we wanted to have key artifacts such as the stakeholder map, market opportunity analysis, personas, service blueprint, and an affinity diagram. These would not only help anchor our group’s mental model of healthcare and AllScripts’ services and methods, but also help drive our team toward specific goals.
Though most of the artifacts such as the stakeholder map, personas, and service blueprint are pretty much like other ones floating around the web or ones we’ve made for other projects, there is one artifact that deviates slightly from the rest. Our team took the traditional tool of affinity mapping and molded it to fit our needs. To clarify, it doesn’t mean we grouped notes to fit our predefined groupings. Rather, we didn’t think all of Karen Holtzbaltz’s (bless her sweet, intensely passionate user research heart) affinity mapping rules applied or needed to be adhered to.
Affinity mapping consisted of two phases, where Selin and I printed out individual notes from 20 interviews. Prior to starting the process, we developed a coding structure and template for easy identification of the interviewer and his/her role for each note. The first phase used hundreds of notes from 10 interviews; most of these interviews were with providers such as doctors and nurses, an EMR trainer, and healthcare executive.
Two hours brought us to a rough mapping of healthcare and attitudes toward EMRs at a high level. Two days later, the team took a look at the affinity together and decided to segment the groupings of notes into “Healthcare at present,” “EMR implementation,” “Provider Attitudes.”
Within each segment, we also decided to chronologically order these groupings (let’s call them headers) for additional structure. This dimension allowed us to view the affinity in a more focused manner since related problems were placed more closely to one another. Finally, not every header within a segment necessarily needed three notes as we had learned in class. Rather, if we felt that a note held much value, we still created a header for it and decided that these “loner” notes were areas where we needed more interviews.
The second round of affinity, a week later, was a little more complicated and I have to admit, our heads hurt a little. The interviews we printed this round had a handful of notes about provider attitudes toward EMRs, but a large portion were about EMR implementation. And within that, as we went through the notes, we realized that many notes needed to move to the service blueprint since they were too specific to AllScripts methodologies. We added a good chunk of headers within “EMR implementation” and realized the affinity diagram had reached saturation. Anything more, the map would lose its value. More notes wouldn’t give us new insights and instead, perhaps confound us even more. After going through the affinity a second time with the whole team, we decided the affinity map — for now — would take a break. Any new insights would populate another affinity diagram, maybe.
“Let’s just create.”
Our team as a whole has an attitude of “Let’s just create,” where we constantly are creating a bunch of first passes of design artifacts to establish a basic sketch rather than a perfectly polished piece. We hold each other to high standards — that you must know — and prioritize idea articulation as well as concept refinement more than the final product. All of these artifacts are a means to an end, acting as ways for us to boldly put forth assumptions and ideas, which ultimately give our client and each other something to react to.
I’m pretty proud of how far our team has come in our research regarding ambulatory healthcare and EMR implementation processes. I’m thankful for a team willing to make and create in a space so vast, wide, and honestly, confusing. I’m grateful for a client so ready to help and offer person after person as an information resource. I’m not shy to admit: healthcare UX is difficult and overwhelming. The team knew that going into this project, but we’re identifying first-hand the many constraints, stakeholders, and policies that may intimidate the most creative of ideas and push them into dark corners, afraid to ever emerge again. But as designers, we’ll make it work…oh yes, we’ll make it work.
To affinity and beyond,
Daphne
P.S. Wait, don’t leave yet! If you’re a Pittsburgh-er and in healthcare at some capacity, reach out to us. We’d love to involve you in a co-design session in April.
