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
The biggest feature to be implemented in our health portal - Messaging. Mochi patients, providers and staff all communicating and interacting with one another digitally. This was without a doubt the most difficult and complex feature our team had to build, but the end results were nothing short of successful. I was tasked on being the UX/UI and product designer for this feature, leading my team both visually and structurally.
Our messaging feature was built with Web scaling first in mind, as our three portals weren't built for mobile at the time. The UI for this was meant to still adapt our Mochi branding guide, as well as emit an interface that was both professional and straightforward.
The purpose of this feature is to avoid all clutter and have patients be able to talk to customer support/their doctors through traditional online chat. Doctors and admins can transfer patients to other doctors from there, transfer them back to customer support, or end the chat.
The patient portal is the portal that all Mochi patients will have access to. You are able to message customer service, and then from there be assigned to your current provider. This feature was designed to be as straightforward as possible, having a solid blue button standout to create a new message, and provide notification icons whenever you receive a new message.
The admin portal (customer support) will have the heaviest load in feature capabilities from the three. All patient customer service messages, or "cases" will be filtered through an inbox tab, and from there admins can select cases they want to take. Those cases are then taken into their inbox and will act from there as a traditional chat box. Admins also have the ability to transfer their case to a doctor, and hand over the chat that way. Designing this feature took a lot of user flow charting and mind-mapping with my team to decide the most orderly way to create an inbox and messaging system for our admins.
The provider portal was the simplest of the three. They didn't have to open a case like patients would to speak to staff, instead they could message admins/patients directly just by searching up their name. Providers could also transfer patients back to an admin if needed. Just like the two other portals, the UI for this portal was designed to be straightforward and orderly, as dealing with patients concerns and medical information need nothing other than clear, concise communication.
Below are some UI pop-ups I designed to be used regularly in the Mochi messaging interface
Mobile app for messaging. Also for doctors, patients and admins. Having this app further solidifies the idea of having easy and open communication with docotors, patients and staff.
The design language I wanted to use when designing this app was to still stay true to the desktop interface, while adding new ways to make messaging stand as on it's own as a mobile app. An illustration on the login screen to further push the design identity of connectedness with you and your doctor, as well as a new logo for the app icon.
App icon design - Staying true to Mochi's logo by using the M in the name and adding a message bubble next to it, making it stand on it's own in identity as a "Mochi Messaging" app. I didn't want to recreate an entirely new logo, losing the Mochi brand entirely, and I also didn't want to just use the Mochi logo, having it imply that the app was the portal app instead of just messaging, so this design addresses those two concerns.
I used Adobe After Effects to demonstrate the animation for the login screen. Designing with still images works, but designing with motion brings those designs to life, and bring out the most in product identity. The animation pacing had to be quick, but also fun. For example, prolonging the effect of the message bubbles was very intentional. When you are logging in, the bubble animation still shows, moving and floating around the screen - adding a bit of fun to the eyes as you enter a somewhat stale process as logging in or singing up.
For the two characters, the one to the left is a patient, and to the right is a doctor, leaning on each other and signifying connectedness and companionship with you and your doctor. It is also a more clear extension of the logo - with the 'o' and 'c' tilted towards each other, also signifying the same emotion.
I used Procreate on my Ipad to create the initial sketch, and then traced over it with Adobe Illustrator to vectorize it and clean up the lines. Also made sure that the colors used were complementary to the blue I used for the background.
I worked on this project as the lead designer for a start up company. However, just like most start ups in the initial stages, I had to wear many hats that I wasn't prepared wearing. Throughout designing the portal, and specifically the messaging feature, I took on the roles of graphic designer, UX/UI designer and product designer. Some of those roles I performed better than others, and some I was learning on the job. It was an extremely exhausting and taxing process, but extremely vital in my growth as a designer. Learning not only how to take risks and learn on the job, but to lead a team with confidence and humility.
The UX for this project was the biggest obstacle that me and my team had to tackle. The designs and the UI were very straightforward, taking influence what we already had from our desktop portal UI. And making the fun and stylish lock screen illustration was a lot of fun as well; but connecting everything and understanding the limits of each feature within the messaging ecosystem was definitely our biggest struggle.
Too convoluted, too messy - conducting interviews with doctors and doing a lot of user research on how modern communication goes with doctors and patients gave me insight on how all-over-the-place most healthcare services are. If you have a basic question for your doctor for example, most healthcare apps have you just text your doctor straight away - which sounds nice, but you come across a bunch of issues like what if your doctor has multiple patients and can't address all their patients questions? What if the question isn't even for the doctor and might be a general question that doesn't require medical input? The list goes on.
The solution was to create a messaging ecosystem that enabled patients to get their questions answered as quickly as possible and from the right people. This also meant that for doctors, the only messages that they view are questions specifically for them and their patient. For example, if a patient has a question about needing to reschedule a visit, or changing their payment method, then that would be a question for customer support and not their doctor. Now if a patient has a question about side effects, or having to request a higher/lower dosage for medication, then that would be a question for their doctor.
We had to solidify the process in which we nailed down the communication access/limits of each portal. This meant to be very intentional with our user flow and wire framing in the initial stages of design. If we create a faulty foundation, then everything we build on top of that will crumble. So we made sure that the structure for our messaging ecosystem is the first thing we get right.
What our each portal's limits? To put it simply: Patients can only message customer service, and when connected to a doctor through that, they can now message back and forth with their doctor. Providers may start a conversation with anyone at anytime (lucky..) and admins accept all patient requests, take their cases and answer the questions themselves, and if needed to be connected to a doctor, only they have the ability to do that. Admins can also message patients and doctors directly at anytime (also lucky).
But then how would we know which types of cases are basic questions for admins or urgent for doctors? Customers will have to select between 4 different categories that best describe their situation: Medication, side-effects, dosage and other. Some of these are pretty straight forward, and will usually be directed to their provider almost all the time. But each case is different, and so admins must look carefully and read the description text along with the (subject) title to determine whether or not this a case for themselves, or for their provider.
Once sent to the provider, providers can then talk with their patient and talk back and forth until the issue is resolved. Doctors can then end the conversation on their end, or forward them back to customer service if they have more questions not regarding their provider (e.g. scheduling visits, payments etc). When this is done, those cases will appear back into the case inbox where any admin can pick it up from there.
With the foundation established, and building a clean UI on top of all that, my team and I created the most seamless way to communicate with your doctor and costumer service within our health portal product. Acting as UX/UI designer as well as product designer was no easy feat, but it came with enormous growth and learning that I will take with me everywhere I go from then on.
Below a visual representation of our message ecosystem user flow
Examples of real world figma drafts that I used for this project