Patient Portal — Portfolio

01

Overview

Health care has a notorious history of having outdated and suboptimal user experiences. In a world where people are being pushed to focus on wellness and health, doesn’t it make sense to provide users with the best? Best experience, best response times, and best practices in design to optimize their health?

One of the cool facts I learned was messaging is the #2 reason people use their patient portal. With that tidbit, it made sense to update the messaging experience so users can quickly communicate with providers, loop in caretakers or proxies into ongoing conversations, and even tap into AI for assistance.

Scope: Elevate the legacy messaging experience, shifting from a web-browser experience to responsive and ultimately a native mobile-first experience.

02

Design Process

Over the past 2 years, I collaborated with our Research team to comb through a plethora of research materials and user testing data, and understand what our users are looking for. The research validated some notions we already had: the legacy messaging experience was outdated, hard to navigate, and very slow.

As a cross-functional team, Research x Design x Product met multiple times a week to create personas, user goals and scenarios focused on pushing the limit of our designs. There were several iterations that focused on different goals, which I have shared below with annotations.

Iteration 1

Simplify and clarify what type of message the user should select in the new message workflow.
Usability tests told us having a dropdown of message types was confusing for the general public and actually led to users inundating their provider’s inboxes with many messages!

This told me users do not understand what these generic message types mean - for example, what does confidentiality request really mean?

Guided workflow
In this iteration, the team explored the idea of creating a guided workflow to include more descriptions of what each option means, and also aligned with the general model we created in other parts of the portal. I worked with our technical writer to ensure we aligned with Oracle’s standards and providing detailed descriptions.

Challenges

Legacy platform
As you can see in the screenshot to the left, the platform was originally designed as a desktop-first product. In order to keep up with competitors and the target audience’s current needs, the company identified and understood the importance of designing mobile first.

Single message responses
The legacy platform only allowed for single message responses; meaning each sent and received message was logged as separate list items. In order to see the full message history, the user would have to actively switch from their “inbox” folder to their “sent” one. This causes a huge burden on the user in order to maintain their health history. Additionally each list item creates a lot of bloat in the user’s inbox.

Goal
Our goal with the first iteration was to:

Align with Oracle Design standards, which makes our designs scalable and easy to update.
Move away from the plain text, email format towards a chat bubble-style message thread.
I pushed hard on threaded messaging to not only alleviate bloat, but it also gives the user context and groups all related messages of a single subject.

Iteration 2+3

Since the mobile-first approach was a completely new project, there were many ideas and priorities that were pushed to the team. Which made it even more important for Design to collaborate with Product, to map the roadmaps together, and priorities scenarios. Ensuring we’re on track and thinking of all use cases. The next changes we prioritized were:

Supporting different types of messages
The team saw the opportunity to including other items into the inbox, not just messages. The first thought was supporting medication renewals. Yes this flow could be initiated from the medication list page, but bringing this item to the inbox reduces cognitive load and burden to remember which medication our user needs to renew.

Design for iOS native app
At this point, there was a pivot in organizational priorities, and we were pushed to start designing an iOS mobile app version of our patient portal.

Push notification support
Push notifications are a must for native apps! I worked with Engineering to place this priority on their roadmap and worked with them to map notification type > landing page.
This was also an important step as our research showed our users not only expected deep linking, but this also reduces clicks.

Link specific message threads
My team lead and I also explored linking specific message threads to related pages. What this means is opening a message thread about a test result, and when you minimum the chat window you would actually be in that related page. This felt like a no-brainer as this gives users the context needed, especially when you’re coming back for more information days or weeks after the fact.
Unfortunately we could not agree upon the mental model when presenting the idea to leadership. Ideally, with this model in place no matter where the user creates a new message, it would follow you as you navigate across the portal.

Iteration 4

With the third iteration in GA, the team was able to gather some analytics and found a few pain points to improve:

Provide quick links to create a new message
This one was easy to solve - with the guidance of our research team, the team decided to have a sticky header with a “New message” button that can be found anywhere across the portal. We also made this a quick action on the homepage, as research informed us sending messages is the #2 reason users come into their patient portal. Finally, the user can ask Oracle assistant to create a new message, which would redirect the user to the workflow.

Iteration 5

The last iteration I worked on was expanding on the previous iteration and seeing how we can integrate AI into the model.

Incorporating AI
Due to our NDA, I’m unable to share the designs we worked on. However the general concept was to alleviate the user from having to make too many decisions. Why should the user be burden with selecting a message type or the recipient, when all they really want is to quickly get in touch with their provider and get answers. What if we used AI to gather those pieces of information, craft a message and even determine who is the correct recipient.

We explored this option and even looked for ways to introduce educational materials early in the user’s message thread. The purpose of doing this was to hopefully answer the user’s question and reduce the number of messages the provider receives.

Reflection
It was truly a shame I couldn’t work more on this project, but I’m so thankful for the opportunity I had to work with our AI team in the end! It was such a fun project and have so many more ideas I wish I could have shared with the team.