UX/UI, Product Design

Mochi Portal Messaging

Messaging app for our Mochi portals. My team and I had to create a whole messaging program from scratch. This was designed to connect our patients, providers, and admins together in one fluid messaging experience.

Roles: UX/UI, Product Design, User Research

Health Care Messaging for Web and Mobile

3-Way Messaging Feature

To create a system like this, we had to design with user flow first in mind. What are the do's and don'ts for each type of portal, which actions grant access to what, and then once that was figured out, I built the UI on top of it.

Patients who want to talk to customer service must reach out to our admins first, and if they need to talk to a provider, they cannot just chat with one directly and must still go through our admins. Then, it's up for the admins to decide if they want to forward it to a provider, or just settle with the issue themselves depending on the situation. This project defines the user flow, and different UI pages associated with creating e 3-way portal messaging feature as best we could.

PROJECT GOALS_

How does this feature work? 

Patients must always speak with an admin first, however admins and doctors can speak with patients directly. If the admin needs to connect the patient to their doctor, they have the ability to do that as well. This messaging feature is aimed to reduce the amount of unnecessary messaging and noise that may come from a simple 1-1 messaging system, so we put a lot of thought into how we could best design the flow so that if feels natural for all 3 portals to be messaging one another.

Patient Messaging

Patients reach out to customer service via their own UI that asks the subject of their case, the body copy, and and files they want to attach

Provider Messaging

Providers can message patients directly and can message customer service as well.

Admin Messaging

Admins take all patient requests and filter them out from there. The admin messaging system has it's own inbox that admins can access and grab to avoid convolution as much as possible

Patient Messaging Process

Here's a visual chart of the user flow for patient messaging access. Below that also contains images of how the UI looks when patients need to compose a new message to customer service

Admin Messaging Process

Here is a visual chart for the UI of our Admins portal. Below that also shows images of the inbox system and how it looks once an admin takes a look at a specific case.

After a case is taken, that case is then moved into that admins inbox and they can start messaging with that patient. If the admin wants to forward that patient to their provider they con do so from there as well.

There was a ton of UI elements that played into making a messaging program. Here a few examples

Provider Messaging

Here's a chart for provider messaging's user flow. They can message patients directly, and if they want to message admins, that will also go into the inbox for an admin to take. Below that are images of the UI of providers that receive a message that was forwarded to them by an admin

CASE STUDY_

The Process

my programs_

This process was very similar to the process of making mochi portal systems. Did a lot of my sketches/drafts on procreate and then proceeded to finalize them on Figma. I was the only designed on the team, so a lot of this was on my shoulders to get right. We had a team of software engineers that couldn't get started on anything until I had created the user-flow and base UI for the messaging feature. It was definitely a lot, and was the feature that took the most time to make by a mile, which is why I decided to make a separate project page for it here on my portfolio. It was a lot of responsibility and required a lot of back and forth with the engineering team, but we made something quite amazing and I am proud to have played such a major role in creating it.

actual Figma drafts used for this project*