Mobile & Tablet app (iOS)
Oct 2017 - Jan 2018
User Experience, UI Design
Fresenius is a premier healthcare company focused on delivering the highest quality of care to people with renal conditions. They have 2400+ dialysis clinics in the US with over 190000 patients. The current system they use requires their physicians to navigate in and out of numerous softwares just to get through the day. This cross-platform inefficiency slows down their workflow causing them to waste valuable time.
Compass is an app that streamlines the daily workflow of nephrologists, while allowing them to spend time on what matters the most: providing quality patient care. With Compass, physicians can see the list of scheduled patients for the shift/day, detailed patient charts and lab reports, take quick notes during each check-up and manage prescriptions.
Before we started thinking of solutions, there was one big problem to begin with - we were going to design for a field that was completely alien to us. How did we tackle it? We collaborated with the stakeholders to get a first-hand, extensive understanding of their needs followed by a comprehensive 3-day design sprint to explore potential innovative solutions.
Day 1: The first day was spent listening, consuming and asking LOTS of questions about the day-to-day life of the physicians. Throughout the day, each of us was noting down "How might we..." questions. By framing a problem as a question, we train our brain to look for meaningful and relevant solutions rather than focus on the problem. For example, one problem statement we came across was "The note-taking process is cumbersome". This was framed as "How might we make the note-taking process easy and efficient?" See how the question already makes us look for solutions? By the end of our 8-hour workshop with the client, we cumulatively had about a 100 how-might-we questions. A few examples:
Day 2: The second day was spent analyzing and synthesizing all the questions we came up with. We used affinity mapping to club the questions that were trying to solve the same problem. This helped us gather different perceptions and solutions for each problem. After the categorization, we asked the clients to mark the questions/categories that they felt were most important for us to focus on. We encouraged them to add their own how-might-we questions to the board. By the end of the exercise, we had the 4 categories they wanted us to primarily focus on - Patient list, patient info, notes, and orders.
Day 3: The third day was used to ideate and brainstorm solutions. We picked one category (Example: patient list) and set a timer for 10 min. We jotted down as many ideas as we could. The clients were encouraged to do this exercise with us. At the end of 10 min, we all presented our ideas to the team. We repeated this method for all the categories we finalized on day 2. In the end, we all put up our sketches/notes on the wall and proceeded to mark the ones in which we saw potential. This helped us discard ideas that were unfeasible or seemingly "cool" but not useful to the client. We also had to consistently keep in mind the timeline to define the scope of the project.
The primary goal of the research was to understand the day-to-day tasks of the physicians and identify the pain-points in their journey. The two methods we used were:
Fly on the wall
We conducted fly-on-the-wall observational research where the team spent an entire day on-site with physicians to gather information without directly engaging with them. This method limits any potential bias or behavioral influence.
We interviewed 5 nephrologists to better understand the problem space, user needs, and behavior. The interviews were repeatedly conducted at different stages of the design process to collect feedback on our iterations.
After gathering all our insights from the kickoff sprint and the research, we set out to first and foremost, identify what problems we will be solving.
Systems are not integrated: Multiple systems need to be accessed during office visits and dialysis clinic rounds to find labs, data on a patient, medication lists, etc. The systems not being integrated can cause duplicate work for the physicians.
Missing important information: Crucial information like care alerts, prescriptions, and transplant status are hard to find. It is critical for the physician to not overlook this so they can follow through on updates and avoid miscommunication. The consequences of oversight can be lethal.
Time-consuming data entry: The process of completing notes after patient visits is cumbersome and inefficient.
No real-time information: Once the patient begins the dialysis treatment, there is no information in the system. This can cause the physician to accidentally skip a patient and lose out on billing and the ability to provide good patient care.
We used sketching and whiteboarding to explore a wide range of ideas. It was a great way to get feedback early-on and collaborate with others to finalize potential solutions. This helped us decide which ideas to discard and which to explore further.
Considering how complex the project was, it was paramount that we engage with the physicians early in our process to gain a clear understanding of their clinical workflow. By weekly reviews with the stakeholders and simple task-based tests with physicians, we were able gather valuable insights on their priorities. Using Lookback and Invision, we set up our user test and gathered their feedback.
Here's an example question we asked:
"What patient info is used to decide who to visit next when rounding?"
We got to know that just the patient name and demographics do not suffice. Nor does the order of their scheduled appointments. The physicians prioritize by the patient's treatment attendance and time remaining in the treatment session.
An efficient way to sort and filter through patients based on real-time updates. Quickly view important information about the patient like treatment time or notes submitted to prioritize who to visit.
An intuitive way to categorize and consume the patient details. View a quick summary with the latest updates along with detailed lab reports, medications, allergies, treatments, hosptializations or past notes.
Landscape compatibility for screens with data tables to make consumption easy.
Creating a note made faster by the option of importing data from past notes. Transfering information between doctors on different shifts made easy by letting them resume a note right where it was left off.
One place to review all the orders and sign it with a swipe. In addition, there is an ability to select all orders to sign them in bulk.
Once we nailed the features and flow for mobile, I took upon the task to create the tablet version of the app. A cross-platform, integrated solution was paramount for a seamless and successful physician experience across all touch points.
"Found this to be a great timesaver."
- Dr. Adam Protain, Adventist Health, Portland
"We've gone as far as we can with traditional research. Now we have technology in our pockets that lets us go even further."
- Dr. Helen Link Egger, Duke University Medical Center
- Dr.Peter Manring, Bronson Healthcare
The product is released in its MVP edition and early results are looking promising. Following its conclusion, the product will move to beta for internal testing before its launch. It is planned to be used across 2400+ dialysis clinics with over 190000 patients.
The user research helped us uncover significant pain points that the physicians face with their daily tasks. Here are a few that we came across from our interviews:
Explore the mobile prototype
We had a few more ideas that were successfully discussed, validated and tested but could not be added to MVP due to time and scope restrictions. Few of those being adding a new patient, billing, secure messaging between doctors and e-prescribing.
Feedback delays due to busy schedules of the physicians: Our timelines were tight and getting regular check-ins with nephrologists wasn't easy. There were quite a few times when the feedback was delivered later than the expected date which meant that we couldn't incorporate that in time. Since we were working on multiple platforms, we needed the designs to be locked down for iPhone before starting the tablet design. Unfortunately, there was a lot of back and forth which led us to a state where we were tackling too many problems.
Remote testing: The physicians we were designing for were located all over the US. It was difficult to arrange for real-time testing sessions. We used lookback to video record the tests but most physicians forgot to speak-out their thoughts. We lost the opportunity to ask them contextual questions based on the test.
Rules and regulations: There are quite a few rules and regulations associated with the process of a patient visit. It was challenging to design something innovative while fulfilling those requirements.