• Initial Concept Wireframes
  • Research Data (user interviews & domain research)
  • Usability Test Reports
  • Design Principles
  • Final Wireframes
  • Final Prototype

Quiddity is a healthcare startup aiming to “reduce the financial toxicity in the healthcare system”. Their platform is desktop, physician-facing, and breaks down different treatment options by cost and effectiveness, which the client hopes will give providers as well as patients greater understanding of the financials involved, empowering them to make the best decisions. To begin this three-week project, the client provided us with an initial prototype but encouraged us not to feel constrained by it, but rather to follow the results of our research. I worked alongside a team of two fellow UX designers in three distinct sprints.

The client’s initial wireframe was clean and clutter-free, but failed to include several key things (like the patient’s name, and basic info!) and featured a cumbersome architecture for comparing options.


  • Examine physician needs and constraints to determine the viability of the product
  • Make the platform engaging and efficient
  • Find a better way to present the information contained in the product


Our preliminary research involved exploring the domain and examining competitors. Gaining a reasonable understanding of the domain proved more time-consuming than expected, due to the esoteric, labyrinthine nature of the US healthcare system. Conducting a competitive analysis was particularly challenging in light of the fact that competitors’ platforms are closed systems. Rather than allow this to become an obstacle, we decided to focus on a first principles approach and began our user/SME interviews.

We conducted several interviews with six physicians across a variety of medical fields. The interviews ranged from 60 to 120 minutes and included a user test of the prototype. During the initial round of interviews, three key themes became clear.

  1. Doctors felt that they were spending too much time entering data into the universally-disliked Electronic Medical Record (EMR) rather than with the patient.
  2. The cost of the various treatment options isn’t released to either the physician or patient until after the treatment, which harms the doctor-patient relationship.
  3. Diagnosis and treatment selections are usually made mentally by the physician, who rarely consults outside data. 

Together with the data from the usability tests, it was time to move into synthesizing our findings.


Our research was synthesized by plenty of post-its and affinity mapping, as well as sitting down together and discussing things with each other. We posed one broad question to each other: what deeper insights did our research findings point to? I felt that our research allowed me to empathize deeply with physicians and understand that a lack of patient time was at the heart of most pain points, since they are too busy entering data into the EMR rather than attending to the patient. 

Through this conversation both with each other and with our data, we iterated upon the initial problem statement to reflect our insights:

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

At this point we also created our guiding design principles:

Efficiency - We will provide a simple platform with minimal data entry to help doctors make the most of the limited time they have with patients.

Credibility - We will help doctors build trust with their patients by providing reliable, contextualized information.

Transparency - We will facilitate an open and honest conversation between patients and doctors, taking into account the realities of the health insurance landscape.

Quality - We will set ourselves apart from other healthcare software by emphasizing quality and context of data over quantity.

Humanity - 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.


Our principles framed the problem for us, and together with the research synthesis data, and list of suggested features/improvements from the usability tests, we moved into the second design sprint, where each team member would create their own wireframed solution. To do this, I relied mostly on whiteboarding as well as the crazy eights tool of rapid ideation.

I opted to go in a minimalist direction, given that foremost among providers’ concerns was the excessive amount of screen time their job already entails. Managing to significantly cut down the number of screens produced a more manageable experience for users, several of whom mentioned they wanted as few screens as possible. 

Use arrows above to view screens. My initial wireframes eschewed images in order to present information to physicians in a way they are accustomed to, in order to allow them to grab the info they need at a glance. My biggest change was moving the entire comparison function to the main page, and simply using radio buttons and bold/grayed-out text to highlight options. Simple is best.

After conducting further testing on users and presenting to the client, who offered additional feedback, we were well-positioned to effectively evaluate our individual prototypes for the final design sprint, to create the final prototype.

The three different aproaches taken by me and my two teammates. On the left, Caity opted for an Amazon-style retail treatment with photos of the medical equipment in question. On the right, Joel went for a more graphical, node-based design.  


Combining the most successful features of each prototype, together with the insights gained from the previous round of testing and iteration enabled us to produce a final prototype that addressed common user demands:

  • A visual running tally of the total cost to the patient
  • Hover states to quickly access additional info
  • At-a-glance metrics showing patient’s out-of-range vitals, and diagnosis
  • A link to the relevant article for each effectiveness score
  • A faster method of comparing selected options

In further user tests, physicians preferred the more simple text-based approach, informing us that images, particularly photos of the equipment/pharmaceutical drugs, were of limited value.


In retrospect, this project was a huge learning experience compressed into a very limited timeframe. Overall, I’m proud of what me and my team accomplished. Familiarising ourselves with a complicated, convoluted domain in a couple of days was an achievement in itself, and I thrived in the fast pace we kept up to. The final user interviews all demonstrated that, unlike the initial prototype, the product is now viable and usable.

As UX designers, we are all aware of the importance of delightful user experiences. However, designing a platform that will be used by physicians during patient examinations in a high pressure environment showed that good UX can have serious ramifications on whether patients get the treatment they need. More than ever, it was made clear to me how crucial it was to create a product that simply got out of the way.

Looking forward, there are some key recommendations:

  • Further testing is necessary, and as much as possible it should be conducted on physicians in private practice, in their native workspaces.
  • Begin to build a database of diagnosis codes, treatments, and level of evidence. This mass of raw data would ideally be collected for one discipline initially.
  • Establish relationships with insurance companies and collect cost data.
  • Establish an add-on modular structure. Doctors already have limited time and patience for additional software, so it’s essential to seamlessly integrate into an existing EMR platform.