Philips

eCareCoordinator
UX Design, Visual Design, Front-end

Overview

Philips eCareCoordinator drives proactive health management to monitor chronically ill patients with Philips Hospital to Home telehealth programs.

Scope & Cadence

Despite the hefty scope and aggressive timeline, the team was able to go from knowing nothing, to knowing many happy users of the newly created eCareCoordinator In just a few months utilizing LEAN methodologies.

We conducted weekly sprints in which we worked closely with the Philips team to define the work that each team member would be tackling in that time frame.

A routine check-in with actual clinicians who would be using the new system was also established to validate or invalidate that we were headed in the right direction through usability testing of the clickable prototypes and user interviews.

ECARECOORDINATOR IN ITS NATURAL ENVIRONMENT

Goals

We were tasked with providing clinicians with a daily review of each of their patients, allowing them to prioritize patients and adjust care plans or intervene as needed. Also, our solution needed to give clinicians real-time access to both objective health data as well as subjective responses collected via health questionnaires and other communication with the care team about the patient’s status.

Team

I worked on this project during my time at Appiphony. The team consisted of the Chief of UX, a product designer (me), about 5 engineers, an engagement manager, a PM, and the Philips eCareCoordinator product team. I spent the majority of my time synthesizing research, generating UI sketches, high fidelity mockups, and creating clickable HTML prototypes as well as writing all the SASS for production.

Research

To develop an understanding of the application’s core users and the problem we would be solving over the next months, the team conducted ethnographic research, user interviews, and usability testing of current systems.

In the current system, patients were extremely greatful for the fact that they could get care from the comfort of their own home. The in-home telehealth equipment helped patients who would normally have up to three hospitalizations a year, have only one or even zero. This is because the system uses preventative measures and patient learning to avoid unnecessary hospitalizations.

“This is the best thing that’s ever happened to us, and I really mean this from my heart…I wouldn’t be where I’m at today without this right here helping us.”

By talking with patients and clinicians we were able to ensure that we weren’t tearing down what was working, but building upon it and making it more usable.

SCREENSHOT OF IN-HOME EQUIPMENT

SCREENSHOT OF OLD SYSTEM

The problem wasn’t that the system was bad. The problem was that the system was not as efficient as it could be and onboarding clinicians was pretty time intensive. We were able to determine the main points of frustration on the clinician side were patient protocol creation, patient survey creation, and the inability to see at a glance how patients were doing.

Approach

Inventory & Ideation

With the problem defined, we did a product tear-down to catalog things we noticed during the research phase that were/weren't currently working. For the problem areas, we ideated on what we might change in order to alleviate those pain points. Most these ideation sessions came in the form of quick and dirty dump & sorts, flurries of ui sketches, and whiteboarding sessions.

Protocol Authoring UI Sketch

Protocol Authoring UI Sketch

Job Stories

During the ideation phase of each problem area we were always thinking about what situations users might find themselves in, what motivations they would be experiencing in those situations, and what outcomes they would be expecting. So naturally, we leaned heavily on the Jobs To Be Done framework. This framework was super useful in helping communicate to the team what an actual clinician or patient may need or want in a given situation such as authoring a protocol or filling out a survey.

Example of how our job stories were structured

Task Flows

Each of these jobs was then mapped to a task flow to help the team gain a better picture of all the different states, actions, and decisions required from the user. From those high level task flows we were then able to transition into low fidelity UI flows pretty easily.

High level task flow of protocol authoring

Detailed UI Flow

Creation & Validation

Hifi mockups & HTML prototypes

After the team was done figuring out the details and iterating on paper, I'd produce some high fidelity mockups and go through a series of feedback sessions with stakeholders before creating HTML prototypes.

Protocol Authoring View

Selected day

Editing a day

Searching for existing events

Searching for keywords

Adding intervention rules

Conclusion

By first understanding the problem we were able to quickly iterate through solutions and test those solutions with real users. What we ended up with was a solution that helped clinicians do their jobs more efficiently and effectively—which in turn allowed patients to have even better experiences which greatfully impacted their quality of life.

This project was presented in front of tens of thousands of people at the Dreamforce keynote as an example of how to have success utilizing the salesforce platform.

Dreamforce Keynote featuring ecarecoordinator

Contact me

Hi, person.

If you've got a job that seems perfect for me, let me know about it! If you wanna get coffee or a beer, let me know about that too!