Overview
This study involved designing a tablet dashboard for Ugandan healthcare providers to monitor NICU vitals. Working on this tablet was a constant balancing act of using the best design practices to create an intuitive product while having limited access to the end users in Uganda for interviews and testing. This product was a great opportunity to reconcile the product's environment with the product to deliver a product that was usable and better user experience.
Keep reading for more in-depth dive into the case study, or skip ahead to the prototype.
Roles
Tools
Accomplishments
This is the wearable a neonate would wear on their head. It monitors four major vitals: heart rate, oxygen saturation, temperature, and respiratory rate.
Photo courtesy of Neopenda
Coming into this project, I knew very little about neonatal care. However, given my educational background and job in healthcare, I was familiar with a lot of the medical terminology and picked up acronyms fairly quickly. I also had background knowledge about general processes surrounding patient care and paperwork procedures. As a daughter of a nurse, I understand what nurses experience in terms of how closely the interact with patients and the emotional investment that goes into care.
Neopenda involved a team of two: Sona, the CEO and co-founder; and Tess, the CTO and co-founder. They have done their fair share of field research in Ugandan hospitals and visited over 100 neonatal units to scope out the environment and determine the needs of those units. Upon meeting our clients, I observed that Tess and Sona are well-organized and have a firm grasp on what areas lacked research and testing. A big concern for them was how we were going to design in an environment that’s removed from the end users in Uganda. Therefore, one of our final deliverables was a testing plan to carry on the work that we put into designing the interface. Not only did we need to explain what needs to be tested, but also how it should be tested. Our biggest goal was to validate enough of our assumptions to help Sona and Tess get to the next testing phase.
We had a few assumptions we wanted to test throughout the course of the project:
We decided to set up a second meeting with Sona and Tess to tap into their experience with Ugandan hospitals. We learned that doctors are forced to try certain procedures due to the lack of monitoring equipment, while nurses are pressured to make up data on the papers because they often don’t have spare time to take vitals, let alone write them down. Therefore, the system would need a way to build accountability for the nurses to respond appropriately to alarms without blaming them.
Twins and triplets are a common phenomena in Uganda, leading to a more urgent need for labeling babies correctly. We also learned that there are medical standards and regulatory constraints around the LED lights on the wearables and alarms that we would have to keep in mind while designing the interface. We would also have to keep in mind the product’s longevity because when things break in Uganda, they don’t get fixed due to lack of money and IT support. It also helped clarify some constraints about the technology of the tablet. We originally thought we had to organize 100 sets of vitals on a single interface, but Tess told us that a tablet could only hold up to 20 sets at a time, which was much more manageable to work with.
We collaborated on the initial problem statement with the clients and produced the following:
We created the initial problem statement with the clients so our team could gain alignment with them and have a problem to work from as we delved into research.
Our next step was to do some research to get acquainted with the field, fast. Due to the three-week constraint of the project, we had to rely heavily on broad domain research. We covered three main areas in our research:
1. Understanding the environment
2. Unpacking the device
3. Broader knowledge on neonatal care
To help us understand what’s already in the market, we analyzed other wearable vital signs monitoring technology for newborns. Since our client had already completed their own analysis, I honed in on them from a design perspective to see how they visually display data and alert caregivers.
From analyzing these competitors, I found that the temperature alarm would only sound when the baby was too cold, and that alarms could be silenced safely for up to 120 seconds. In addition, some monitors would show trends for vitals.
For indirect competitors, we looked at out-of-category areas dealing with monitoring vitals and data displays. We found two devices that informed our design and usability:
From these two platforms, we learned how a busy dashboard could be streamlined to help with scannability. This helped us as we turned to address the initial prototype’s usability.
Prior to working with our team, Sona and Tess had already designed and simulated an interface on a laptop. The images below represent the four main screens that stem from the top navigation (Dashboard, Patients, and Devices).
To help us in our initial research-gathering, we conducted a heuristic evaluation of the existing interface. This created a baseline for testing Neopenda’s interface, which helped guide us in developing an improved solution by rectifying the violations. We focused on areas of most concern, shown in red and orange.
We then turned to speaking with SMEs and potential users from Uganda to get a better understanding of neonatal care in Uganda. We categorized our interviewees by: 1) familiarity with Neopenda dashboard interface, 2) exposure to and understanding of Ugandan culture (specifically regarding low-resource neonatal care), 3) amount of time spent with neonates (nurse or doctor).
Most of our interviews with Ugandans were conducted over WhatsApp. My teammate and I were fortunate enough to get a tour of the ward with one of our Ugandan interviewees over a video call. Because we were able to video chat, it turned out to be an extremely helpful session and gave us a doctor’s point of view on the interface’s practicality for doctors.
During our interviews, we also asked for user feedback on the initial interface. We came across some common pain points that surfaced. Most of the nurses end up doing a lot of doctor’s work of diagnosing because there’s a scarcity of doctors. We found that theft is a common concern in hospitals; even items such as flashlights are stolen, so bringing a tablet into the hospital raises concerns. Most importantly, we learned that babies are constantly moved around the ward, and more often than not, there are multiple babies per bed. This raised the question about how we could make the interface give some sense of direction to where the patient of interest is located in the ward.
From there, we created an affinity diagram to help us make sense of the different data points:
We ended up uncovering four main trends:
1. Visual cues are preferred over auditory alarms, but the current interface is difficult to scan
2. There are concerns about changing alarm parameters accidentally
3. Babies can be found in groups of up to 6 per bed, and they are often grouped by their condition
4. Nurses are trusted with the ability to change alarm parameters, sometimes more so than doctors
These trends were called out because 1) they contain information that would help us to develop concepts to solve for the problem moving forward, and 2) they pose as the biggest challenges to the usefulness of the interface.
Gathering these insights helped us get more in-depth with our problem statement to make it more context specific:
There is currently a lack of medical equipment, space, and staff in low-resource environments. Neonatal nurses in low-resource environments need a way to efficiently scan vital monitoring information and find neonates in critical condition so they can channel their energy to the child with the most need.
We wanted to focus the problem specifically around what the interface could solve, namely for the interface to be easily scannable and call attention to the neonate in the most need. We learned that nurses are stretched thin when they have to manually check vitals for 8–50 babies. and the sickest ones often fall under the radar. Therefore, we wanted to create an interface that would do the regulating for the nurses, which would cut their workload so they could focus on the neonate that needs immediate attention.
Our affinity diagram also helped us create design principles:
We came up with these specific design principles to keep our team on track as we created possible solutions. Sound the Alarm helped us think about how the alarms could be more helpful instead of an annoyance, which was commonly what we heard from our interviews. For Condensed Spaces, we wanted our design to assist an environment that is more chaotic and lacks structure and space. We wanted to keep Neopenda in mind with Ikea Manual, knowing that part of their business plan is to scale to other low-resource environments. With Clear Direction, we wanted to avoid any potential confusion with labeling because user mental models may differ from location to location.
We moved next to concepts by starting with a brainstorm session. After numerous rounds of quick sketches, our team drilled down to four concepts to test:
01 MOVING MAP
DESCRIPTIONA display that lays out exactly where the baby is by using a spatial map that corresponds to the physical space of the ward.
RESULTSWe ended up taking out the concept Moving Map after it tested poorly with two users. We learned that nurses won’t have time to keep track of their patients’ locations, and that it would be complicated to implement in differently shaped wards. One of our users suggested a new concept idea that I turned into...
DESCRIPTIONA display that provides instant knowledge about what’s going on with the use of quick alerts. I drew inspiration from existing baby monitors and how their alerts looked.
RESULTSUsers reported that the screen looked too cluttered. They also wanted a way for the alarm to call up which vital was causing it.
DESCRIPTIONA display that shows all the patients on a single screen by showing vitals horizontally. I created this with inspiration from airline information screens as well as sparklines. We tested out a dropdown that tells the user what type of bed the patient is on.
RESULTSUsers were split. Some said it was hard to scan for the right information because everything is jammed together. They also said that the sparklines are difficult to interpret without context of an x- and y-axis. Since nurses told us that they don’t look at trends often, we decided to take out sparklines. Others said the layout was familiar from US hospitals, and the dropdown might cause more confusion than help, so we removed it.
With concept testing, we learned more about the nuances of taking neonates’ vitals and what’s most important to check in any given scenario. We also learned the differences in what information doctors prefer to check versus what nurses prefer to see. For example, we found that doctors tend to check trends so they can study patterns while nurses are too busy rushing around dealing with emergencies to check them. One of our users brought up the fact that temperature needs a more lenient alarm because it takes a long time to bring a neonate’s temperature up, so that alarm going off the whole time won't be helpful. The user also had the idea of having different headband sizes/colors depending on the neonate’s gestational age (premature or full term) to help distinguish one child from another.
We hit a rough patch in the road when we found out that our user in Uganda didn’t have access to wifi. We ended up paying for long-distance calling to get some interview time with her and learned valuable information. I asked her about about the patient intake process and learned about including the APGAR score and a section to indicate whether the neonate is “twin 1” or “twin 2”.
Because we had such a wide variety of viewpoints from our concept testers (one Ugandan doctor, two U.S. nurses, and three US doctors), my team and I had to compromise all the different viewpoints. After speaking to Tess about our conundrum, she advised us to make our best inferences moving forward and to focus on solving the issues from a nurse’s standpoint primarily.
We decided to move forward with sidebar alarms (to use real estate wisely), auto scroll, tooltip options (to help with real estate), a trends modal (to preserve context), “Locate” functionality, and the scenario of using different band colors once we got the OK from Tess.
Since we were far removed from the actual environment, we felt like the use cases were still ambiguous and wanted to understand how the environment affects nurses’ interactions with the device. This helped us figure out what happens when the wearable needs to get taken off to get charged, when a patient no longer needs monitoring, and how a nurse enters a new patient’s information.
Once we had a better grasp on the workflows, we got to building out the prototype in Axure. We created a dashboard with the following changes:
I created the “Patients” page and “Devices” page. The “Patients” page gives the user the ability to add or remove a patient and identify what band the patient is using. The “Devices” page allows the user to manage the wearables by its MAC address. Even though it was not in our scope, we decided to add the “Locate Baby” functionality to the “Patients” and “Devices” pages so nurses can locate the wearable in their chaotic environment. I also created the site map.
Even though it's a fairly simple prototype, it was still helpful to map out the interface and highlight the information architecture. This allowed us and the clients to see from a high level what information belongs on each page and how it differs from the original prototype.
Once we prototyped the solution, we put it in front of our pseudo-users to get feedback. We wanted to understand if it would help solve the problem we had identified and test the usability.
We tested with one doctor and three nurses, all U.S. healthcare providers. The majority of the tests were conducted remotely through screen share.
Our testing involved the following four tasks:
Overall, 4/4 users explicitly said that the prototype’s interface is user-friendly and easy to navigate. As a result of usability testing, we made some changes to the last iteration before handoff.
During the usability test with the doctor, I had an opportunity to visit a NICU in Chicago. I got a peek of the monitors as well as the doctor’s dashboard. I could hear the alarms in real time, which was much less obtrusive than I expected. I also saw the way that the babies were named as well as the trends operating in live time, which contributed to our future recommendations.
There were some challenges during user testing. We had a promising usability test at 7 am with a Ugandan nurse that never happened due to multiple dropped calls and unreliable wifi on her end. Unfortunately, we were not able to get end user input, but we were able to create a more comprehensive testing plan with the users we were able to test with.
With the test plan, we had to be thoughtful about how to relay a research plan for people who’d never done a usability test before. We went as specific as laying out roles of moderator and note taking. The more thorough the test plan, the better it would be to ensure that the work gets carried on and the interface gets properly tested—things like language, intuitiveness of use, usefulness of the tablet in the chaotic environment of Ugandan hospitals, and if it will be helpful in worst-case scenarios where there are 100+ newborns in a ward.
This product demo shows the intuitive interface, strategically placed alarms, auto-scrolling in conjunction with alarms, and preserving user in the proper context, and error prevention.
Moving forward, there are many areas left untested that need to be explored. To ensure Neopenda’s product success, we recommended that they make changes to the prototype in two phases:
By implementing these changes, we believe that this will propel Neopenda over their competitors by bringing a system that has the ability to detect all important vitals while minimizing needlessly annoying alarms. In addition, the changes will offload the current nurses manual work of checking each neonate’s vitals, which could cause them to overlook a neonate in need of immediate attention. This would prevent many preventable deaths. For Neopenda’s team, it’s a breakthrough because there are currently no systems out there that factor into account the chaotic environment of low-resource hospitals.
Our clients informed us that their next steps are to launch a pilot test in U.S. hospitals this fall and take our prototype to test in Uganda this fall as well. Once they have gathered data on what needs to be updated, they will build it out and go into production in fall of 2019.
Neopenda was an exciting and eye-opening project. Hearing of equipment and staff inadequacies that lead to infant mortality was oftentimes saddening. It was frustrating for various team members, but ultimately helped us to empathize with the Ugandan nurses. I reminded my team at multiple times to focus on our scope as UX designers: the tablet that will help the nurses save lives. I came into this project with a set of assumptions about Ugandan culture and didn’t know what to expect. What I learned was that the people are polite, gentle, and reluctant to criticize in our conversations. I learned to be careful about not talking over them like Americans tend to do. There were other considerations, such as being sensitive about what band colors would be acceptable to put on babies in Uganda.
I learned how to work with existing medical and device regulations in place. While brainstorming ideas, my team and I had to run the ideas past Sona and Tess to ensure we weren’t breaking any code. We tried to get creative with different alarm colors, band colors, and LED colors, but discovered that in the end, doctors and nurses prefer to see something standard.
Another huge lesson was understanding how to strategize with our clients and keep them in the loop about inconclusive data. It was good to bring Sona and Tess into the conversation about our difficulties and gain empathy and buy-in from them. Because they have experienced a lot of the frustrations we faced, it made it feel like we were all in this journey together.
Reflecting on our end prototype, we came up with a good solution for putting 20 babies’ information on a screen in spite of tremendous challenges, such as an unorganized environment and lack of staffing. Some features I ended up designing for the interface didn’t solve for the problem statement directly, but were useful and helped us understand business and technological constraints. If I could do it over again, I would advocate diverging more in our concepts stage rather than settling too early on certain concepts.
As a UX designer, I want to be able to impact someone’s life with my design work. With this project, I can literally impact people by saving lives. It’s a privilege to be trusted by Sona and Tess with this work. It’s a gratifying feeling to be hand-delivered a thank-you card after our work was completed.
We were even featured in their monthly newsletter!