Streaming

Patient Care teams using monitor/defibrillators can send near-real time patient data to remote providers in order to preview waveform morphology. 

ROLE

Solo designer, design sprint facilitator, define end to end UX between hardware and software platforms, drive brand continuity 

TEAM

Interaction design (me), marketing, project management. Hardware and software engineers (30+ project team)

DURATION

Device software: 8 months

Web software: 6 months

CUSTOMER PROBLEM

Medics and hospital care teams have no ability to send waveform data that they are interpreting while treating a patient in the field. They are always seeking ways to better communicate with the care teams that will be receiving emergent patients upon transport to the hospital.

Waveform morphology is complicated to describe visually over the phone. Today, emergency care providers are using static forms of transmissions (12-Leads) from monitors in order to communicate the patients current condition. 12-Leads only capture visual data containing a few seconds in time.

DESIGN GOALS

Solve for current generation device, but keep next generation device in mind for future growth, and shared UX flows for customers who might have a “mixed fleet” of devices.

Technical limitations of 15 year old embedded software. UI elements on screen limited by space and bandwidth considerations for how much data can be sent. 

Web experience must be unbranded. The web platform is agnostic of device type and competitor data can be used to stream within the application. For this reason, the UI should not look too similar to existing Stryker products. 

PERSONAS

We spoke with 16 participants from 4 countries to understand the target users of streaming data. 

ON-SITE OPERATOR

Uses the monitor/defibrillator system to provide medical care to the patient.

REMOTE OPERATOR

Uses their advanced training to make  assessments and evaluate next steps.

HOSPITAL ADMINISTRATOR

Receives all patient information from the remote operator. 

DEVICE DESIGN PROCESS

A traditional design sprint would not be feasible due to the amount of shared project resources in the Emergency Care business, so I proposed a flexible sprint schedule that spanned 8 half-days, and proposed my design plan to the team. They appreciated the time they were given to shared their days with other committments, and the clear detail of resources required each day. I sent out calendar invites for each internal stakeholder so they knew what to expect for level of involvement, and kicked off each sprint with the core teams partnership to baseline on Day 1. 

At the end of each sprint, I facilitated a team retrospective and sent an internal survey as a way to improve processes, communication, and time management on the next sprint. 

WEB DESIGN PROCESS

The team supporting the streaming web application was smaller and had the benefit of the context of the device discovery process, so we expedited our approach and went straight into concept iterations. Streaming needed to be incorporated into LIFENET Care, so the first step was find the logical placement for the feature to reside within the workflow of our hospital users. 

Our biggest unknowns before usability testing were 1. level of importance of the feature (and how its prominence would inform placement within the application), 2. what labels to use for the feature, and 3. what our users needed from the feature in order for them to find greater value in beginning to use it more (this concept was new to 100% of our US user group).

CUSTOMER DISCOVERY

In partnership with Marketing and Human Factors Engineers, we tested the end to end user experience. Both digital prototypes took a few days to build, and we increased fidelity as we learned more about our users expectations. 

CUSTOMER QUOTES

“I like that it’s pretty seamless. It’s the button we are used to pressing. Pretty intuitive, really good.”

“I think (operating the streaming feature) is about as easy as it gets.”

“The (streaming) user interface was very self-explanatory on the screen.”

“I think it’s very straightforward. It’s just another option within the device.”

“It’s pretty straightforward… select the site and turn it on and beware of the message whether it’s connected or trying to connect.”

OUTCOME

My work on streaming was the first medical device software I had the opportunity to design. It was incredible to be able to look at both the sending and receiving ux of a feature, and apply consistent elements through the design. 

Here are some of the area’s I expanded my experience in while designing this product:

  • UX Continuity. Not only would the design of this device interface effect our current products, the workflow would need to be cohesive with next generation monitor and defibrillators. We predict that many customers will have a “mixed fleet” of device types, and the mental models used to recall how to stream from multiple generations of devices needed to be as consistent as possible to reduce cognitive load of providers. 
  • Modifying Traditions. This was the first sprint that I had to modify the traditional 5-day design sprint into an extended 7-9 day effort made up of half-days. It was the only way the team could juggle all of their conflicting priorities. 
  • SW and HW crossover. I worked with over 30 stakeholders shared between embedded software system and application software to create the designs for both product ecosystems.