UX RESEARCH / DESIGN
Quiddity Solutions is a startup platform concerned with reducing the financial toxicity that is prevalent in the healthcare industry. It seeks to address the problem that patients and physicians are concerned with the costs of care, but doctors do not have access to accurate cost data when they’re interacting face-to-face with their patients. The platform seeks to give doctors a way to compare treatment options across several criteria, such as effectiveness and cost, while also involving the patient more with the decision-making process. This will in turn increase patient satisfaction with the treatment. As part of a three week design sprint, our team was tasked with:
1. Examining physician needs and constraints to determine the viability of the product
2. Making the platform engaging and efficient
3. Finding a better way to present the information contained in the product
Our initial research methodology was concerned with first analyzing the domain, which proved to be quite tricky due to the byzantine complexity of the American healthcare system, and the clandestine nature of other healthcare startups concerned with cost reduction. From there, we pivoted to a second method of research, interviewing doctors themselves on their day-to-day routines, as well as having them perform initial usability testing with the initial prototype we were given from the client.
Our initial evaluation of the MVP told us this was a bare-bones product structured to mimic a retail platform. The user would input a patient’s insurance info and diagnosis code, and then be able to build and compare courses of treatment containing options pertaining to the specific diagnosis. Our initial assumptions in evaluating the prototype led us to a number of research questions we were interested in that we would use to focus our efforts and research:
• What systems/tools do physicians currently interact with during a patient visit?
• How do physicians determine and decide between potential procedures or courses of treatment?
• How do physicians respond to cost inquiries from patients?
• What cost information, if any, do physicians have (or want) access to?
• What frustrations do physicians encounter during a patient visit?
• What information/features do doctors need to improve their workflow?
• How useful does the general concept of the platform sound?
We then conducted 60-120 minute interviews with six doctors across a variety of disciplines, first learning about how they interact with patients on a daily basis, then having them evaluate the initial prototype.
What we discovered in our research is that doctors currently experience several pain points in the exam process that we had not anticipated. Most large medical facilities as well as small private practices have moved from traditional paper notation to Electronic Health Records (EHR) and Electronic Medical Records (EMR) which can be cumbersome and difficult to use, due to their interfaces being more akin to accounting software than exam software. Having to use these platforms takes valuable time away from patient interactions, which are already too brief by their standards. Further, the doctors noted that they have reservations that when cost is concerned in treatment, as they want patients to view them as allies, rather than “businessmen trying to make a buck.”
These interviews provided the team with valuable insight into the treatment doctors routinely provide, and gave us several key takeaways to consider in our next steps:
• Excessive screen time is a huge constraint and source of frustration for both physicians and patients.
• Costs of procedures and medications are very important to patients; doctors don’t usually have access to this information, but they want it to have better informed discussions with their patients.
• Diagnosis and treatment selection processes are largely done mentally in the context of the specific patient in question; it is rare to consult additional studies to formulate a course of treatment.
After synthesizing our research, we formulated a problem statement for our iteration moving forward:
Time-strapped physicians need access to accurate procedure and drug costs to better navigate an increasingly cost-conscious healthcare landscape in a way that:
• Forefronts improved patient care
• Fits efficiently into the physician workflow
• Enhances, as opposed to erodes, trust and transparency with the patient
We also developed our guiding design principles:
We will help doctors build trust with their patients by providing reliable, contextualized information
We will facilitate an open and honest conversation between patients and doctors, taking into account the realities of the health insurance landscape
We will provide a simple platform with minimal data entry to help doctors make the most of the limited time they have with patients
We will set ourselves apart from other healthcare software by emphasizing quality and context of data over quantity
Physicians resent the idea that patients and medicine can be reduced to an algorithm; we will help doctors keep patient care at the center of their work
Formulating the statement and establishing our design principles helped us move forward into the iteration process by giving us a clear goal of what we were trying to solve, as well as giving us a framework for what we absolutely needed to consider in achieving that goal.
Each member of the team then took our respective quick ideas, and translated them into a series of wireframes as possible solutions. We experimented with several different approaches: a node based layout, a layout including all of the information into accordions for quick access and glanceability, and using a single page with hover states and more organized statistics. Due to the time limitations of the design sprint, and the very limited scheduling availability in which to test these designs with the doctors, we were constrained to only being able to utilize wall voting and client feedback to determine what features we would bring forward into our final prototype for further user testing.
For our final prototype, we merged the most functional ideas from our initial ideations into one, to address features doctors wanted:
• A visual running tally of the total cost to the patient
• Hover states to quickly access additional helpful information
• Quickly accessible information regarding patient out-of-range vitals, and diagnosis
• More in-depth explanations as to what “effectiveness” measured
• Faster method of comparing selected options
• A “shopping” model of displaying information, in order to maximize screen real estate, as well as provide a system doctors would be familiar with
The clickable prototype can be found here.
After analyzing this feedback, we made certain updates to the wireframes such as removing the email feature, and annotated them for our final client deliverable.
After testing, we conceptualized a number of suggestions for next steps in the process:
• Further testing
– Further iteration and usability testing needs to be performed, and it is key that it is performed in its domain as part of a contextual inquiry. The platform should also be tested further with doctors working as private practitioners, rather than part of a complex medical system.
• Build a database of diagnosis codes, treatments, level of evidence
• Establish a relationship with insurance companies and collect cost data
• Establish an add-on module structure
– For the platform to truly succeed, it needs to integrate fully into already existing EMR and EHR platforms, so doctors do not have to have even more windows and platforms to deal with during their limited time.
One of the major things I learned from this project was that many key assumptions that we made as a team starting the project were quickly found to be incorrect, demonstrating the absolute importance of using design thinking as a methodology. What we initially thought was a platform that could be used to reduce costs had unintended consequences of both secondary user perception, as well as integrating into it’s primary user’s workflow. Though the platform itself has verifiable merit and could be a useful tool to both doctors and patients; in such a complicated and esoteric domain, being able to test, iterate, and pivot is crucial to the development of a successful product.