Medical Malpractice Insurance Account & Self Service Portal
Scroll ↓
Overview
How might we create a user portal where medical malpractice insurance policyholders can easily access all the complex information they need to manage their policies and request customer service?
While this was a multi-part project, this portion of the redesign was completed within a month. I was the primary UX/UI designer on this project and worked with my team to untangle requirements and complete designs on lo-fi and hi-fi screens.
I was eager to dive into this project. First, there was a legacy user portal that had outworn its welcome by about a decade, and then my team was involved in a hasty temporary redesign on an extremely limited timeline and platform. We did the best we could under the circumstances, but with limited developer support and without any written requirements or established process, the result was less than ideal.
After that experience, I was chomping at the bit to implement all the usability fixes we had identified in an internal round of UAT. I had learned from all of the decisions, compromises and mistakes made in previous builds, and took a real sense of ownership over doing our best to get this one “right.”
Legacy Portal
Current Portal
Our Redesign
Business Objectives
Thoughts from stakeholders:
“Policyholders can access everything they need to manage their car insurance or bank account online. Why not their medical malpractice insurance?”
“We’re launching advice, claims and quoting portals soon. Policyholders need to get used to using our new customer service portal, so they’re already comfortable with it when we launch all these new features.”
“We want to differentiate our company as a technological leader in the industry. It needs to work and it needs to be sleek- we want to be the Apple of medical malpractice insurance.”
Stakeholders were very clear on their objectives for this project, but we had no one to translate business objectives into UX. So that was the first step in our process- figuring out what our objectives were for the redesign, and how those supported business objectives.
Discovery
Without a formal research process, the closest we can get to users is via customer support data. So, I reached out to the customer service team to start pulling data, and then worked with my team & the product manager to map and organize the data. We were able to find some interesting insights, but one of the key pain points was beyond our control (a vendor issue), so we moved that to the parking lot to address later.
The product manager had compiled a list of user stories from internal UAT of the current solution, so I hopped into Jira to figure out what was still relevant, what had already been handled, and what we had questions about.
Armed with that information, I did a heuristic evaluation of each screen- what’s on there, what major issues have we already identified and what are some questions we have.
I also kept a running glossary of terms documenting industry specific terminology. Spoiler alert: there was a lot and this became one of the major issues we’d address. Although doctors or practice administrators have been buying medical malpractice insurance for their entire careers, they’re ultimately in the medical field, not the insurance field. So we wanted to make sure everything made sense to them, not just insurance professionals.
My team then reviewed outstanding questions with stakeholders to gather as many answers as possible in a limited time.
While we worked through our many questions, I also built out lo-fi sketches. This both helped us uncover more complexities and begin to set design conventions.
The Miro board where we organized customer support data… and discovered one of users’ top pain points was due to a vendor limitation 😫
Problem
Confusing navigation and information architecture
One problem I was particularly excited to tackle with this iteration was the information architecture. We hadn’t gotten the chance yet to address the IA from the original legacy portal, so even in the current solution, navigation was confusing and difficult for users to navigate. For example, despite being divided into categories like policies, billing, and documents, there was billing information in policy tables and almost all documents were billing documents, with policy documents buried beneath months of invoices.
Also, tables as navigation. Yikes.
Tables as navigation will haunt my dreams for years to come…
Previously, customers had to call into the company with any question about claims, billing, their policy, or anything else. Self service support had been introduced with the current solution, but we were not involved in the design at that stage. So when we began the redesign, we not only wanted to update the visual design, but also investigate each element so that we could understand how to make seeking support a more intuitive experience for the user.
Forms asked for redundant information, creating an inconsistent experience across various support forms. There was also so much jargony, confusing UX writing lurking in forms.
Complicated self service options
Want to see a form where the user provides critical information AFTER submitting their support request? 😱
New user access levels to incorporate
Not only were we tasked with redesigning the portal, but new user types were being added, as well as a new feature to allow admin users to manage access levels for all users within their medical practices.
In the current solution, users were split into two access levels- customer or practice admin. But the only thing the customer user type could access was support- not much of a portal! With new capabilities coming soon, we had to totally rethink how access levels were defined.
Only insurance agents could add or edit portal users, and what they could edit wasn’t much.
Solution
Improved navigation and information architecture
To understand where and how to display all the data shown in the portal, we first had to understand where it was coming from and how each access level related to the user. For example, policy documents are at the policy level, but some billing documents are at the account number level. An account can be composed of multiple account numbers, which may be broken down into multiple policies.
On the billing screen specifically, data was all over the place and it was unclear how information related. With redesigned invoices recently rolled out, we decided to bring some of that information to the screen to paint a clearer picture of the practice’s financial information.
Seeing that documents were all either billing or policy documents, we got rid of the documents section altogether and placed links to downloadable documents contextually within relevant tables.
We definitely got rid of tables as navigation!
Not a table as navigation in sight
We started tackling the support forms by breaking them down to spot inconsistencies we could streamline. For example, some forms asked for the “requester’s name” and others didn’t– because these forms all live on a portal connected to a user’s salesforce record, we already have their name and quite a lot of their other information.
We were able to use our analysis and the tools on the back-end to simplify the forms and make them more cohesive.
We moved the ability to upload files *onto* the form, instead of after it was submitted. (That one was an easy win for usability.)
The forms’ confirmation and summary pages showed automatically generated information, not necessarily what was most relevant to the user. We redesigned these pages to suppress irrelevant information and prioritize what the user actually needs to know when submitting a support request.
Intuitive self service options
It’s usually not anyone’s favorite task to contact their insurance provider for support, for any reason really. We wanted to make the process itself as painless as possible.
First, we had to do a deep dive to understand the desired user permissions and access levels. Initially requirements for the new access levels was still role based, by job title. So a healthcare provider would have the most basic level of access while a purchasing program administrator would have access to everything. But as we dug in, we found that there were cases when a provider would need admin access, but still need to be designated as a doctor for the upcoming educational portal.
We worked through all the scenarios and edge cases and arrived at a feature based access structure rather than role based. The admin assigning a user access level could check on access for billing but off for policies, and so on.
Reimagined user access levels
Look at all those permissions options! We had to move from role based only to role & feature based access levels to make it make sense.
Conclusion
This project is now with the developers to implement. We will continue to stay involved as they build out and for any potential changes that may come through. I’m proud of how we improved this experience and ultimately believe that we designed a more usable and intuitive product. I’ll update with user engagement metrics when this product is launched, but I have high hopes 🙂
I was particularly proud of the way we decided to deconstruct the portal and put it back together again, really throughout, but especially the information architecture and user roles. When we worked on the temporary version of the portal, there was very little understanding of the role of UX/UI in the organization as a whole. Initially, the ask for converting the legacy solution to a pre-built template was “to send over colors, font and pictures.” By the time this redesign rolled around, not only had we introduced technology teams & stakeholders to the value of UX/UI design, but we’d also developed our team processes to be able to tackle this project effectively.
In diving into this redesign, I wanted to practice and strengthen my discovery skills. With no formal discovery process, my goal was to find all the guerilla research opportunities to best understand the user, their needs and their pain points. In past projects, I noticed that we raced to screens to meet a deadline, but that there was inevitably a huge amount of re-work once unnamed requirements surfaced. So I wanted to do my best to understand as much as early in the process as possible so that when we got to actually designing screens, our major questions were mostly answered.
I think taking a methodical approach to discovery helped us orient ourselves better as a team. We’ve both been able to minimize re-work (so far) but also I believe taking a step back before designing was part of what helped us to deconstruct the design we were given more thoroughly.