Below is an article originally written by Henry Bayuzick, a Product Designer at PowerToFly Partner Flatiron Health, and published on October 4, 2018. Go to Flatiron Health's page on PowerToFly to see their open positions and learn more.
For a good part of my life, I wanted to do something in healthcare. There was always something so powerful about the idea of becoming a doctor and helping patients heal. There was only one problem: I didn't do well in biology and I didn't think I was was capable of going through the rigors of medical school. So when it came time to choose my career, I went with what I was good at: design.
Five years into my career, the opportunity to be a designer at Flatiron Health presented itself. It seemed like the perfect gig, an intersection between my interest in healthcare and what I was good at. I was nervous that my struggles in biology would quickly resurface making it hard for me to succeed at a healthcare company, but, one year later, I'm confidently able to say that you don't have to be an expert in medicine (or good at biology) to be a good designer in healthcare. Here's why.
Co-designing with experts enables clinically-accurate solutions
At Flatiron, subject-matter experts are embedded in every product team and include doctors, pharmacists, physician assistants, and more. On each project, gaining context begins by sitting down with the subject-matter expert(s) and learning relevant information. This means asking questions like, "What's the difference between clinical staging and pathologic staging?" or "Who is the person entering this information?". Their expertise enables me to better understand the varying clinical content (in this case staging and prognostic factors) determining the information hierarchy, relationships, ideal states and challenging problems.
But our partnership doesn't end there; instead, throughout the project, we collaborate on design solutions to ensure our mental models continue to align and the end experience is clinically accurate. For example, when physicians stage cancer, they also track prognostic factors such as biomarkers that better explain the disease. The workflow that we were redesigning collected prognostic factors as a one-time value, which, for a medical novice like me, seemed logical. However, in reality, prognostic factors change over time and how they are tracked is significant when determining future treatment. Collaborating with subject-matter experts revealed this difference, its importance and ways to improve it.
How you learn is more important than what you know
Nobody knows everything. Okay, so that's obvious, but really, even the oncologists who have been practicing medicine for longer than I have been alive don't know how everything works. To be clear, they know a lot, and it's incredible how much providers can store and recall, but at the end of the day, every individual has their own area of expertise. What this means is that at the beginning of each project, it doesn't matter how much I know or how much I don't know, instead what matters is how willing and able I am to learn. A lot has been written about beginner's mindset, and with each project at Flatiron, there's really no other option for me than to have a beginner's mindset. Recently, my team and I redesigned the workflow that physicians use to select treatment (much more difficult than it sounds). There was no pretending, I didn't know anything about chemotherapy regimens, but I did know how to learn. I researched treatment guidelines, asked oncologists about how they choose treatment, walked through real patient scenarios, and sketched diagrams of my understanding.
User research will likely reveal what you missed
Flatiron's not-so-secret key to success has been to embed clinical experts into all projects. Although we have the privilege to work with clinical experts on an almost daily basis, user research is still essential. Subject-matter experts help us understand clinical content and how workflows should be performed, but thorough user research reveals how people are actually using our software, the nuances between providers and clinics, and the creative workarounds. There is also simply no replacement for putting a design solution in front of the person who will ultimately be using it every day. Before working in the healthcare, I cut corners with user research, often making assumptions based on what I would do and using poor proxies, but designing healthcare products has forced me to improve my research skills. Over the course of a year, I have shadowed physicians and front-office staff, and conducted numerous remote research sessions with clinical users, such as sessions with chemotherapy nurses to understand how they calculate drug doses and use design solutions aimed at improving the safety of their workflow.
A few months ago, I was shadowing a physician when I felt a brief desire to go back to school so I could practice medicine. When I mentioned this idea to the doctor, he said, "Adding another doctor doesn't solve these problems, but redesigning our approach does." It was in this moment I realized the unique skills I was bringing to the table as a designer. Digitizing electronic health records didn't magically make healthcare better, in most cases it did the opposite by contributing to physician burnout. All along my desire to be a doctor was rooted in helping people get better, and although I was not a good biology student, being willing to learn, to co-design with experts, and to invest in becoming a better researcher has enabled me to do just that.