
DASHBOARD
Timeline

A Privileged Problem to Solve
It’s hard to find someone in today’s world that has not been impacted by cancer. OncoLens, provides a platform to support the smartest minds in cancer care through virtual and in-person tumor boards. As the UX / UI Designer, I needed to create a dashboard that would be used during the tumor board meetings.
My objectives were to create an experience with the following:
-
lower cognitive load
-
ease coordination
-
access a single, comprehensive patient view
-
enable precision medicine
-
leverage clinical trial matching
-
ease outreach for second opinions and insights
​
Working with business stakeholders and the product manager, we decided our MVP would be the dashboard patient timeline.
Research & Discovery
I started off by sitting in on live tumor boards, understanding the flow of the meeting, how they broke out each patient, what pain points they currently had, what tasks were effortless, and the time spent on each patient.
​
I needed to understand the different user personas, who facilitated the meeting, how many were in the driver's seat and how tech savvy are they? Is there a level of customization that was needed for each facility that ran the tumor board?
​
Each patient has medical history, sadly, some very long. I needed a solution that displayed this information with ease and provided the entire timeline so nothing was missed. Different events or medications/treatments that could effect current recommendations needed to be highlighted for the safety of the patient. In some cases, 15 patients would need to be discussed in a 30 minute tumor board meeting - with a lot of detail the UI needed to be clean with very little clicks.
​
Live tumor boards provided the insight I needed, but I dug deeper to fully understand the user and the problem.
-
Competitive Analysis
-
Personas
-
Interviews (Radiologists, Oncologists, Pathologists)
-
Data Input, Output and Required Fields

Data Input, Output & Required Fields
I needed to match the needs of the user to what we could do for MVP. If users wanted to see a timeline, the information provided needed the logic for the backend development teams to pull the data. I needed to work through what would need to be required for the timeline to display successfully.
​
I broke out the the data into the different sections of the dashboard and highlighted which section data the patient timeline would need.
​
The doctors in the tumor boards were not who was entering the patient data, so I embarked on a new set of interviews with physician assistants and medical scribes. Every interview was different, but had a common theme of being busy and just trying to copy/paste doctor notes where they could to save time. Knowing that we would be out of scope, I took their feedback and worked with the product manager to add items to the backlog.
Ideation & Design
I pulled example patient history data to get an understanding of the copy and the different layers that would make up an individual patient's history. I researched different ways to display timelines and started sketching out ideas. Knowing that his will be on a busy dashboard, I had the challenge of keeping it clean with limited amount of clicks. Through the interviews, it was determined that the patient timeline would be one of the top 3 sections of the dashboard that would be highlighted/the main focus.
​
Through sketches and wireframes, I gathered my concepts and presented to my team for their feedback. After iterating and adding in actual copy to see the space that was provided, I narrowed down and created high fidelity screens. I presented prototypes to the internal stakeholders for approval to move forward. Once we decided on a concept, I kicked off usability tests to see if we were on the correct path.

Lessons Learned
Overall feedback from the usability tests were successful. The layout was well received and we introduced a modal to enlarge and focus in on the patient timeline.
We also learned that we had additional problems to solve. Users entering the information typically copy/pasted doctor's notes and had to think through required fields - most input was placed in open fields due to time efficiency constraints. If we were going to be able to display the information in a uniform layout, we needed to go back and brainstorm. Existing users decided to take this back to their team to discuss the importance of this data as well.
A possible solution was to provide a rich text editor and remove some required fields. Our next steps were to set up a recurring focus group and drill down on the time constraints of entering individual fields vs rich text editor capabilities and how that impacts reports from the data.