healthcare
dashboard
desktop
b2b
EyePACS Dashboard
Consolidating all of the necessary steps to complete a retinal screening into an all-in-one dashboard for rapid, yet efficient, retinal screens.
The solution
Let's start from the beginning - what is EyePACS?
Diabetic retinopathy is the leading cause of blindness in working-age adults
There are often no visual symptoms in its early stages, so patients are usually unaware that they have the condition. But when symptoms do arise, it may be too late for treatment. Up to 95% of diabetes-related blindness is preventable with timely detection.
EyePACS is a service that provide local clinics with the resources to timely detect diabetic retinopathy
It's a clinically validated, web-based system that uses store-and-forward technology to facilitate the diabetic retinopathy screening process. EyePACS helps local clinics provide preventative care to help patients get the timely detection and treatment that they need to prevent blindness. Check out their website here.
EyePACS received concerns about complicated user workflows
The EyePACS system requires a lot of steps to complete a diabetic retinopathy screening. Pictured below is the steps that a retinal photographer must take in order to fully complete one patient screening.
So, EyePACS developed the "AutoUploader" to address concerns
The "AutoUploader" was to simplify the steps highlighted in orange in the user workflow above. Ideally, this program would allow retinal photographers to seamlessly upload and manage patient cases without having to switch between multiple windows.
…but users didn't like this new product, and my job was to investigate why and design a better solution.
I utilized several research methods to uncover pain points
Semi-structured interviews
to gather user perspectives, experiences, and expectations to identify potential areas of growth
Contextural inquiry
to gain insight on real-world usage and observe users in their natural environments
Heuristic evaluation
to assess the existing solution against recognized usability principles to gain an objective, structured perspective
Moderated usability testing
to gather user feedback and assess their ability to perform intended tasks with the product
Before formally starting the research process, I identified my key users
First, I conducted semi-structured interviews with these key users
Using Google Meet as our medium, I met with several users from each key user group shown above (n=11). Here's what the interviews revealed about these users:
Retinal photographers struggle to remember how to use the product after being trained
Photographers, the main users of this program, have trouble remembering the workflows that they were trained on and feel that they need to constantly reach out to EyePACS for help.
Training staff are overwhelmed with training and support asks
Staff report that the program is difficult to use and troubleshoot, resulting in a lot of their workload being centered on troubleshooting.
Contextual inquiry helped me understand how the product was being used
What users say =/= what users do, so I considered contextual inquiry to be an important step for this project's research process. My goal was to understand how my key users were interacting with the AutoUploader in its real context and in what ways it was not meeting expectations. My two key user groups of focus for this were EyePACS training staff and retinal photographers at partnered clinics (n=6). The contextual inquiry revealed:
Lots of lagging between steps
There were no clear call-to-actions (CTAs) with each step in the AutoUploader, causing users to be confused about what they were supposed to do next
No support available
When they were stuck on a step, there was no easy way to troubleshoot or reach out to support to get help. Their only option was to email EyePACS support and wait for a response.
Not enough feedback
Often asking, "Did it work?" after completing certain steps - there wasn't enough feedback for users to know whether they are progressing correctly.
A heuristic evaluation helped identify objective weaknesses
After gaining insights from the interviews and contextual inquiries, I conducted a heuristic evaluation to assess the existing platform against standard usability principles to get an understanding of the product outside of the user. This helped to further inform my design requirements and constraints.
Turning research insights into design opportunities and requirements
At this point, I had gathered insights on the problem through three different ways: (1) semi-structured interviews, (2) contextual inquiry, and (3) a heuristic evaluation. Below are my takeaways for actionable ways I can act on my findings:
Identifying new user flows as part of the product revamp
After discussing with EyePACS management and stakeholders, we agreed that it was best to completely re-design the product instead of simply fixing the existing solution. This meant that I would need to outline new user flows. Given the user flows, the management team wanted it to be designed as a dashboard.
Onto low-fidelity prototyping with new user flows in mind
I was asked by management to completely re-design the product instead of simply fixing the existing solution. This meant that I would need to outline new user flows. Given the user flows, the management team wanted it to be designed as a dashboard.
Gathering user feedback for the low-fidelity prototype
I asked for user feedback from 7 users, with a focus on asking for what they liked, disliked, and what they wanted to see. Most of the feedback was towards the homepage, patient list page, and overall workflow.
Onto the mid-fidelity prototype with user feedback in mind
Conducting usability testing at the mid-fidelity stage
As part of the usability testing, I asked my users (n=5, consisting of EyePACS training staff and retinal photographers) to complete the following tasks while speaking their thought process out loud. The following are the tasks and their success rates:
Upload a patient case
3 out of 5 users were able to complete this task (60% success rate)
View the patient list and edit a patient's information
5 out of 5 users were able to complete this task (100% success rate)
Task #1 had a 60% success rate and I found the following user pain point:
While task #2 had a 100% success rate, users left additional feedback for the final iteration:
Balancing stakeholder wants versus heuristics
When presenting to a higher-up stakeholder for feedback on the mid-fidelity, we ran into a disagreement on one part of the design where I had to defend my design decision. The problem was whether the landing page for the dashboard should be the “Dashboard” (Home) tab or the “Upload” tab. I had intentionally designed it so that “Dashboard” would appear upon launch.
After further discussion, the solution agreed upon was minimizing clicks for the user and setting “Upload” as the landing page to prioritize less clicks for the photographer.
I applied all of my findings to the high-fidelity prototype
Impact of the new design
We arrived at these impact metrics after doing real testing with the AutoUploader, keeping in mind both the image upload times and the time that it takes to type in patient information. We arrived at an approximate 5 minute run through with the Figma prototype that I shared with the team, keeping in mind those extraneous times.
This was an incredibly valuable learning experience with lots of takeaways
Defending your design decisions
When discussing designs with stakeholders, disagreements are bound to happen. In those cases, I strongly believe in at least explaining my stance first, even if it doesn’t end the way I had originally planned. Voicing my thought process, hearing feedback, and learning from it is important for my growth as a designer.
Involving developers early-on
One of my biggest regrets for this project was not involving the developer early-on to discuss feature feasibility. It solidified the idea that design is certainly not possible solely through the hands of the designer, and it’s imperative that we work cross-functionally to ensure all moving parts are accounted for.
Designer responsibility
I discovered many user pain points were linked to the product's functionality, which is under the responsibility of the developer. Although I can't directly influence this aspect, as a designer, I can collaborate with the developer to incorporate all necessary workflows into the design, aiming to prevent as many issues as possible from arising on my end.
Be ready for change
This project started with no other goal than to improve it. Since the team was new to UX, once they had seen the low-fi and mid-fi prototypes, they had a lot of suggestions. It was important that I was open to those suggestions and kept an open-mind to making necessary changes to the original user flows to ensure that the product met business goals.
