Residential Quoting Portal
Figma, Jira, VS Code
Designer, researcher, developer
As the threat of climate change has become more emergent, the flood insurance industry has had to evolve quickly to keep up with demand. The process of getting a flood insurance quote through reThought Insurance (and many other MGAs) was to email back and forth with an underwriter about property details, making tweaks to coverage numbers, all in order to get the premium to an acceptable amount. This back and forth via email could take all day and sometimes multiple days if the underwriters are busy (which they often are). We needed to make a change by creating a product that could be used by external users to cut down the turnaround time and increase the company’s profits.
Being a company that is trying to revolutionize the way that flood insurance is done, there aren’t a lot of competitors in the market to do a helpful competitor analysis. The market is also flooded (see what I did there?) with potential business and brokers are desperate for online quoting portals that will help them meet the demand for flood insurance.
Through my research, I found two main competitors, both with portals that I could interact with. One clearly had a design team, and was very aesthetically pleasing while also getting the job done. The other was clearly done by a developer without any designer involvement. It got the job done, but the aesthetics felt outdated and clunky. In addition to my own research, I had conversations with a select few brokers that reThought had good relationships with. I asked them which portals they used and their thoughts about the platforms. Brokers for flood insurance want the cheapest, best coverage for their clients, so they have a lot of great insight from "shopping" experience with different portals.
We already had a framework in place for the internal product that our underwriters use to get quotes, but it needed to be adjusted to fit within the confines of a quoting portal that could be accessed by external users. This meant paring down some of the more technical parts, as well as making components more accessible and usable for brokers unfamiliar with our process. Working with two developers, we made a list of specs that we wanted to include in our first round of releases.
An MVP would need these features:
Design related objectives:
These images and the final prototype link is the culmination of MANY versions, mess ups, successes and collaboration. The quoting portal, when boiled down to its core, is a giant form for brokers to fill out with their property information. The biggest part of my job as the designer was to create the pages that would guide them through the process, display their results in a digestible manner, and inform them of what can and can't be done through this portal.
View the interactive prototype here.
The image above is the dashboard page, the first screen that users see once logging into the quoting portal. I wanted this page to be like most dashboards you'd find in other digital platforms - an overview that gives the users a quick glance on the state of their quotes.
The image above is the exclusions page which is the screen that users see before they can even start filling out the form with all of their property information. One of the most painful user experiences out there is when you fill out a ton of inputs just to find out that the program can't accept your submission. I created this screen to try and avoid that painful experience by checking in with the user first to make sure that the quoting portal can even accept the property they are trying to create a submission for.
The image above is the quote overview page where users land after they have submitted their property details. The purpose of this page is two-fold. Firstly, this page needed to show all of the property details that they just submitted in a digestible way. When it comes to displaying a lot of data on one screen it is imperative to chunk things together and give space between items so that the user is not overwhelmed. By splitting these three main groups (policy details, files, and versions) into separate cards I was not only able to fit everything onto one page (a must from stakeholders) but it isn't too cluttered either.
After turning the hi-fidelity prototypes into code and deploying the quoting portal, I knew that it was time to learn how it was landing with our users. My first step was to get the green light from my project manager and CEO to reach out to brokers and launch a user testing campaign.
I led a meeting where I presented my ideas, detailing why user testing is important, who I was going to reach out to, why I chose those people, the tasks that I would ask them to complete, the script that I was going to use while testing them, and why it would be beneficial to the company. The response was positive, and I was given the go-ahead and to reach out to brokers for testing.
Since I was designing a product for a niche group of people that I'd been interacting with via email, zoom, and phone calls, I thought that I knew my users pretty well. That said, I wanted to ensure I was selecting as wide a variety as possible to represent a diverse range of users. I continuously reminded myself that there's no better way to lose track of empathy for users and their actual needs than to make assumptions about them. With that in mind, I came up with the following three main edge cases for my personas who best represented our target user group.
In order to eliminate as much bias as possible while testing with users, I created a script to follow when walking a user through their testing session. I didn’t want to include any leading questions, hints, or words that could contaminate my findings. I included four tasks that would thoroughly test each part of the quoting portal’s capabilities, and I made sure to add talking points that like making sure users knew our interaction wasn’t a test of their skills, but rather a test of our product. All user testing was done virtually via Zoom, and each 15 minute session was recorded.
Through this process, I was able to learn a great deal about how brokers were interacting with our quoting portal. We discovered some bugs, UI visuals that needed to be adjusted for clarity, and many user requests for specific enhancements. This user testing session spawned many JIRA tickets for both myself and the developers on our team, and it gave us a great window into the capabilities we could deliver to brokers in the future.
One of my personal goals is to always try to make new mistakes - things will always go wrong, but ideally we're able to learn from our past and adjust as needed.
At the time, the standard at reThought was to test after coding was complete, and trying to change that process was an uphill battle. If I could do this project all over again, I'd have pushed for user testing and design prototypes much earlier. In future projects, I want to advocate for more testing and designing before developers dedicate their time and efforts.
