top of page

As the sole designer for CuraviGo, I was in charge of all facets of this project, including discovery research, project management, software and hardware design, gathering feedback and data, as well as iterative changes and updates.

A total of three versions went through four pilots at various facilities, each incorporating learnings from the previous iteration.

This project ran over the course of three years and is extremely rich.  Below is just a taste of my process through the product lifecycle.

Curavi Go

Create a portable version of the telemedicine offering, extending the reach of our virtual doctors, and expanding the company product offerings.

Project Goal

Discovery: 2 months

Define: 1 month

Design: 3 months

Iterate: 2 years

Overall: 2.5 years

TimeFrame

  • Competitor Research

  • Ethnographic Research

  • Customer Journey Mapping

  • Scholarly Journal Review

  • Bodystorming

  • Paper and foamcore prototyping

  • Moderated usability studies

Methodologies

The Goal

With the success of the CuraviCart, leadership decided it was time to make its telemedicine offering portable.  Designed to be taken into the home or on a multi-level campus, it would allow a nurse to enter the home and get provider-based care without having to move the patient from their current location or wait for an appointment.  Initially conceived to be a backpack, the product offering evolved based on customer research and feedback. 

 

To determine the needs of the project, I first met with the Chief Medical Officer of Curavi to determine why the company was interested in pursuing a portable version of our telemedicine and what value it would bring to our customers and users.

The first iteration

At the time that I joined Curavi, there were already some preconceived notions of what the product should be.  Given the success of the larger cart, it was assumed that the Curavi Go unit would be a scaled-down version with similar peripherals, but I decided to do some research to find out.

 

Stakeholder Discussions

After vetting a few partner facilities, one Continuing Care Retirement Community in particular showed interest in partnering with us to pilot the new unit.  Once the agreement was drafted, I met with several administrators to understand what their goals would be for the pilot. 

 

Based on those goals, I drafted metrics to capture and we reached a consensus on what numeric ranges would be poor, acceptable, and excellent.  These would be our guiding principles for the project.

 

User Research

After we knew what we were aiming for, I met with the expected end-users.  We started off with a series of phone calls where I talked with the users and got a feel for their workflow. Then, armed with a  moderator guide, the nurses talked me through their responsibilities and what a common occurrence would look like, and how they would expect telemedicine to assist them. 

 

Based on their existing process, we discussed how they saw us fitting into their workflow, I drew out a rough outline of the workflow, starting with the example below:

OTG Workflow.png

After having built a rapport with the nurses on the phone, I came on campus and we did some bodystorming exercises where they mimicked using the telemedicine case. 

 

After discovering their expectations and physical limitations, I shadowed them onsite for a day to see how they currently responded to incidents.  It soon became clear that when an incident occurred, it was often security that arrived “on-scene” first. 

 

A new idea emerged to allow security to start the connection instead of the nurses.  I spent the next day shadowing security instead and learning about how they responded to an incident and would regularly bring other medical equipment onsite for the nurses responding to calls.

The Finalized Workflow:

Curavi OTG Telephonic First Workflow.png

Design decisions And tradeoffs

Connectivity

Although the facility had wifi all throughout the campus, we agreed that since connectivity was essential for consults, I would build in redundancy by adding our own wifi generator.

Battery Life and Charging

Based on the fact that security had its own department transportation, I decided to make a unit that could be charged in the car, in addition to being able to plug it in at a resident’s home.

 

After looking at some existing data, I decided that if the average consult length was 30 minutes, and there was a possibility of two or three consults in a row, the minimum battery life for the unit had to be 3 hours.
 

Size and Weight

Since security both had a car and certain physical requirements, I had the option to make the unit larger and heavier than initially expected, although I didn't want to overload it.

 

After learning how much the nurses carted around campus, I also decided to consolidate some of the nurses’ equipment to both reduce the amount of stuff they have to carry, as well as incentivize use.  If the bandages and equipment they needed were already in the case, it would help drive utilization.

Peripherals

Scanner

Despite testing multiple portable scanners, I was not able to include one due to size restrictions.  However, my initial research showed that the providers needed certain documents like medication lists and advanced directives.  To satisfy this requirement, I developed a new flow for the “scannerless upload” where either security or nurses could take pictures of the resident’s documents to send to the provider

Vitals

To reduce the amount of equipment the nurses needed to carry, I decided to consolidate with what the nurses had on hand.  This would both simplify and incentivize the nurses to use the telemedicine case that security would deliver.

EKG

In this version, our regular 12-lead EKG would not work due to its size and complexity.  After I went to UPMC's Heart and Vascular Center to talk with some subject matter experts, I decided to include a 4-lead EKG with the option to use electrode pads or clamps with gel.​

Layout

Based on the bodystorming exercises and ethnographic studies performed earlier, it was clear that certain elements needed to be used much more frequently than others, and needed to be more accessible.  I decided to build a tiered compartment where cabling and the “guts” would be tucked away and harder to access or disrupt with common usage.  This also allowed me to pre-wire all the hardware and not force the users to mess with plugging and unplugging equipment.

 

I also decided to get custom foam cutouts for the top layer to make sure everything had its place and was intuitive to put back.  This had the added advantage of protecting the equipment.

Documents

To provide consent, I worked with administration to create the consent for treatment and provided the paperwork in the case.  The paperwork was designed in large print with high contrast so users would not need reading glasses at the time of the incident.
 

Software

Since our providers had to adapt to a new workflow, I needed to make some software changes for them as well.  

 

Firstly, I needed a way to indicate to them that this was not a “standard” telemedicine call, but a different consult type where they would not be able to access the patient’s records.  We decided to create a new consult type for them, as indicated across the top of the consult card.

 

Next, since they were not able to read the patient’s records, I needed a way for them to document as thoroughly as possible.  I added a dialog box that would allow them to document while still in video.  This would push to the patient records that would be faxed to the facility and reduce redundancy for providers.

First releasE