CASE STUDY_
The Problem
The problem to solve for this project was that we needed 3 different user portals to all interconnect and have each one to serve it’s own unique purpose for the target audience at hand. The patient portal especially served as the branding face out of the three. It would be what our patients would use, meaning it would need to contain the cleanest and most intuitive UI. That's not to say that the other two portals weren't intuitive and thought out in its design, but with our limited time and deadline, the patient portal definitely got the proiority.
A problem we noticed was that a lot of similar patient portal websites like MyChart, FollowMyHealth and others, were not a good basis on how to design our own portal. The ux was clunky, the designs were not pleasing to see or use, and overall felt very "low-budget". Our portal also shares those same baseline features as those said apps, but ours contained that and more. We were implementing visit rescheduling, messaging, weight tracking, paying bills etc - and all that was just for the patient portal.
The provider and admin portal were just as much work or even more for this project. We didn't have any other apps to refer from and had to start from scratch. Admins to oversee all patient-provider activity, make necessary changes and override certain patient information at will, as well as take care of medication tracking and billing for all patients that have signed up for our company. There's no doubt it was going to take a lot of work and brainstorming to make it it all work.
Our provider portal was made to be taylored for doctors, but the problem was there wasn't an app or website out there that did that. So we had to create one on our own. Our doctors mentioned that they would have to open multiple tabs to view patient information, the webcam call, their notes, and other vital information that had to be seen at a glance. Our job was to fix that, and make it as intuitive as it can be.
The Solution
Our team's solution was to tackle this project from a big picture ux framework that served as the foundation upon what we would build upon. This meant that since all three portals are so interconnected, it was important that we established the blue print upon what our portals' limits and permissions were before we started designing on a smaller scale.
For example, when it comes to booking a visit, patients can book visits and can also cancel. After canceling, they are prompted to reschedule. For providers however, they cannot book visits and cannot reschedule, as they do not know their patients availability. It's the other way around. So when a provider cancels, the patient is then prompted to reschedule even if it was the provider that had done it. Admins can oversee everything and can book visits upon the patients behalf and can communicate with the patient/provider directly behind the scenes to make it all happen. This is just one example of how these portals are very much integrated but have strict boundaries around them, and defining these before anything else was an absolute first priority.
After going over the big picture design, we can now focus on the individual portals and how we can take these big ideas and refine them into tangible concepts. Let's use the provider portal for example. One of the biggest goals we had was to make the provider portal FOR doctors. This meant that we needed help by real doctors. One of our doctors on staff volunteered to have a 1-1 zoom call with me, and it was my task to take all of is requests and create concepts to present to my team. This doctor presented to me his real set-up for when he has appointments with patients. They consisted of multiple tabs on this computer, notecards that he would have to hand write, and also printed out forms of official documents. I took all of that and designed a concept in which all of those references were seen all in one page. Hence my design, which houses a section for viewing pdfs and files, a section for patient information, and a collapsable side bar for notes/encounters.
That is just one example for our solutions in creating our portal systems. All of these also ran multiple user tests with test audiences. The patient portal prototype was sent to friends and family of our boss, the provider portal was sent to some of our doctor staff, and the admin portal was sent to our admins.
Being the only designer in the company, my job was incredibly difficult. I had to take on the role of user researcher, product designer and ux/ui designer. And that was only for this project. Outside of that I was still responsible for being our web developer, brand designer, packaging designer, and blog illustrator. Our mochi portal systems team consisted of roughly 3-5 software engineers, and one designer - myself. All lead by our CTO and then replaced by our CEO. The project had to be designed from scratch, coded, tested, and ready to go live in only 3 months. Our team worked incredibly hard and we ended up making a groundbreaking 3 way portal design that was ultimately the foundation of the entire company's business.
