NEST Neonate Monitoring App

Helping doctors in receiving hospitals monitor infants in transit


NEST is a joint project between UW and Seattle Children's Hospital to reimagine how newborns can be transported between hospitals to create a more effective and efficient experience.

Role

Lead Designer (team of 4)

Duration

3 Months, ongoing

Skills

UX research, ideation, info architecture design, mobile UI design, prototyping, usability testing

Context

Not every hospital can help newborns with serious illnesses.

Small local hospitals often lack the equipment to deal with risky conditions and require newborns to be transported to larger hospitals for treatment.

Transport is risky and require a medical control physician to help the transport team.

The medical control physician is a doctor assigned to advise the transport team remotely in case of emergencies.

However, outdated technology used means communication is difficult and not guaranteed.

There isn’t a reliable way to communicate vitals data to the MCP and the time spent talking could cost the baby’s life.

Problem

The medical control physician needs better access to the baby's vitals during transport to assess the situation more efficiently.

Brief

Design a mobile app that helps today's MCPs imagine a future where they can access live and accurate data for the transported newborns in their care.

Response

NEST centralizes vitals, transport ETA, and patient history to help MCPs quickly assess the emergency to provide a diagnoses and treatment.

How it works

NEST makes it easier to assess a newborn's condition at a glance.

What doctors currently see

What our design will let doctors see

Highlighted states helps doctors identify issues with the newborn's vitals quickly.

Features

Centralized access to vitals readouts, equipment status, and patient history helps the MCP diagnose quickly

Live video feed gives the MCP critical visual information and helps instruct the transport team for treatment

Live location data helps the MCP assess the best treatment for the situation

Research

Literature Review

I began by reviewing previous interview transcripts with 2 MCPs and 2 transport nurses that described their transport experiences. This helped me build a foundational understanding of the transport process and the vitals data that are used.

SME Interview

I compiled a list of vital data and tools to set up my own SME interview with 2 doctors on our project team to rank what order they want to see the data in, as well as the importance of the data to the transport process.

Contextual Inquiry

I conducted a contextual inquiry with a transport team at Seattle Children's Hospital to understand how the transportation process works, what pieces of equipment are used, and what data they monitor.

Me, inquiring contextually

Findings

Transport Journey Map (click to enlarge)

Medical Control Physicians respond, not monitor

The MCP's role is to help the transport team when the team cannot handle issues on their own and are usually taking care of their own patients. They only care when there is a problem.

Medical professionals rely heavily on instinct to look for patterns, not outlier data points

Doctors and nurses are used to glancing at displays to check on vitals. They know what data to look for where and are likely to be confused by altered layouts. When looking at typical vitals monitors, doctors care more about the trend and less so about the individual data points. However, they still need to see the live data to make a correct assessment.

They also only have time for quick glances

This is especially true for Medical Control Physicians (MCPs) because they are in charge of both babies currently in their hospital and the baby who is being transported.

Doctors are resistant to change

Despite the frustrations of existing systems and technologies, doctors are very much of the "if it ain't broken, don't fix it" mindset. After all, the clunky system is predictable and reliable, which means they can anticipate fixes.

Ideation

Sketching and discussing

I first created a moodboard of the apps that doctors currently use to communicate, vitals monitor screens, and other data visualization applications to help inspire us.

Moodboard snippet + inspiration

We spent a week sketching out various UI layouts for displaying the data and used the sketches to kickstart discussions for what we feel is valuable to the MCPs.

I also invited 2 doctors who are stakeholders on this project to a design critique to get early alignment on our project and have their input early on.

Me and my teammate's sketches

We were able to validate several assumptions about matching the design to real workflows, such as keeping all the vitals data prominently visible. We also got a lot of new information, such as a preference for screens that looked like hospital monitors (design value: familiarity) and explicit labels instead of ambiguous icons.

Information Architecture

Design Values

Using our insights from our research and subsequent design critique with our stakeholders, we generated the following values to help inform our design.

Keep everything visible on a single page, if possible

Doctors and nurses are used to glancing at displays to check on vitals. They know what data to look for where and are likely to be confused by altered layouts.

Label everything

This is especially true for Medical Control Physicians (MCPs) because they are in charge of both babies currently in their hospital and the baby who is being transported.

Let the doctors decide how they want to use the features

When looking at typical vitals monitors, doctors care more about the trend and less so about the individual data points. However, they still need to see the live data to make a correct assessment.

Keep screens visually familiar to their physical counterparts

Doctors and nurses are used to glancing at displays to check on vitals. They know what data to look for where and are likely to be confused by altered layouts.

Design

Putting our values to work

We spent four weeks iterating on the design of the various data pages, focusing mainly on the vitals ("main") page. Our values and insights told us the main page will be the most important for diagnosing the patient, so it was important to get this part right.

Evolution of the home screen

Validation

Usability Testing with 3 doctors

Though this app was meant to be part of a design workshop, I did not want the MCPs to get distracted by inaccurate data or miss key features that we wanted to showcase. Therefore, I set up a usability test to help us validate the design decisions we made and to check the accuracy of our vitals.

Usability Test Doc

Test Details

Demographics
Participants: 3 senior doctors
Recruitment: Personal outreach

Tasks
Assess the accuracy of our representation of the vitals on a mobile screen
Figure out if our design is too complicated
Validate the value of a live video feed to identifying problems

Protocol
The usability test is conducted remotely over Zoom using our Figma prototype.

Findings and Improvements

Acknowledging that the three doctors we tested with were not pediatricians, we were able to gain valuable feedback about our prototype to help us make the best use of our limited time with the MCPs during the design sessions. Here is what we found:

Finding

Accurate and consistent placeholder data is critical to avoiding distractions

All of our participants expressed confusion with the placeholder waveforms we used to represent real data. Some were also confused by the inconsistent labelling (patient name vs. John Doe), which caused them to miss the video function.

Improvement

Create placeholder data based on real neonate vital ranges and real monitor waveforms.

Finding

Most hospitals use different equipment and using brand name/models is highly confusing

Internally, we refer to the equipment used during transport by the make and model (ex. Zoll monitor, Sentec), but equipment vary between hospitals. This would cause doctors from different hospitals to respond differently to our solution, despite working the same roles.

Improvement

Automatically change the make/model of the machine when detected and include a label to indicate the machine type.

This will be a far future feature as the current design is specifically for Seattle Children's.

Finding

Doctors are pretty inquisitive and forgiving, as long as the value of learning outweighs the cost

Our app is jam packed with data, some of which we placed based on intuition and assumptions. Our non-standard functions like the note-taking function did cause the participants to make several errors during the tests, but all were very excited about the features during the debrief. They all said that they were fine clicking around to learn the app, as long as it didn't take too long at first and helped them accomplish their jobs faster in the long run. So in short, no it's not too complicated.

Improvement

Value traditional layouts/workflow a little more than "optimization" in future iterations. This can help doctors transition and maintain their workflow.

Finding

Live video feed is hard to find and not critical to problem solving

Because we wanted to understand how doctors might use this app to problem solve on their own, we did not give explicit instructions to our participants to use the live feed to problem solve. As a result they all failed to find the live feed, but were all able to identify the problem because of their familiarity with the data. According to one participant:

"When I see that one lead is flat and the others are working, I know that the lead has fallen off."

After we told them about the feature, they said that they were confused by the use of "placeholder name" instead of "John Doe", as we had been calling the patient. This made them believe that the button lead them back to the main page to check on their other patients.

Improvement

Change the live feed icon to a video icon for additional clarity and remove placeholder text such as "patient name".

Post-Usability test changes

Visual polish

Conclusion

Next Steps

Dictation to fill forms
A lot of the communication that happens between the MCP and transport team are formulaic and procedural. There is opportunity to streamline parts of the conversation by creating a form that fills out via audio and combines it with the live output data.

More informative notifications
As diagnosis is the main task the MCP would want to use this app for, we want to make it even easier to start diagnosing from the get go. We believe that by being able to better get the doctor's attention and priming them to look out for certain vitals, we may be able to improve their ability to diagnose neonate issues during transport.

Addition of transport selection function
Our MCPs would like more functionality to this app and the next feature to be designed is the selection portion of the transport process.

Reflection

From this experience, I learned about the value designers provide as intermediaries and sense makers. I didn't invent anything new during this project, but focused on gathering pieces of information scattered around the team and stitching them together into a product that addressed the stakeholder needs. Making sense out of chaos, especially when the experts are too busy saving lives, is a pretty cool thing to do.

I also learned the importance of getting primary data and actually being immersed in the space that you're trying to design for. I struggled for a long time in the beginning trying to make sense of all the vitals, metrics, and roles, and it wasn't until I was able to sit down with the transport team and ask questions ask they demonstrated the devices that I finally had a clear picture of the system in my head.

And finally, but not least-ly, get stakeholder alignment early. That will help reduce ambiguities and allow you to deliver effectively, not anxiously (thanks Heather ❤️).