Cover's internal system to administer auto policies.
Cover serves as an insurance brokerage searching across multiple carriers to find our customers the best rate. With an infrastructure as archaic as insurance, our sales agents face many technical hurdles and complications of gathering information across multiple sources, along with slow outdated systems. We sought to stand our own auto insurance entity to rebuild the insurance the right way, not only helping us serve our customers faster, but making our agent’s jobs easier. With our current process of binding a policy for a customer, sales agents would have to log into a carrier’s website and manually bind the quote for the customer. So in parallel, sales agents would need a similar Cover portal to service customers when they wanted to purchase a Cover Auto policy. This was the foundation of our Cover Policy Admin System.
At a very high level, the goal of the project was tied to increasing revenue. Standing our own auto product guaranteed higher margins so we would see increased revenue. Revenue for Cover was measured by sales per agent which was strongly correlated to time spent per customer that showed intent to purchase a policy. Currently, a sales agent can spend upwards of 45 minutes to help a customer purchase a policy. A large part of this number was the usability of different carrier portals the agent was required to log into. What we could fix was the portal for the Cover Auto experience, ensuring the UI was optimized for repeated use. With our own system, we could find ways to have APIs to fill out customer information removing manual tedious work. We wanted to design the portal in a way that was efficient to see everything they needed and then make it easy to update or edit information.
I worked very closely with our sales team to gather issues they currently face, but also to observe how they interact with different systems as they sold a policy. This was a long research part as each agent had their own individual process. There was effectively two streams of work that needed to be accomplished - Binding a policy (everything leading up to the customer purchasing a policy) and Policy management (everything that happened after a policy was purchased).
For policy management, it was simple to define the key functionality such as updating a customer's information for endorsements, scanning policy details during renewals, and customer support functions like easily looking up a policy. This was something we all felt was new so research was very speculative and more-so analyzing what other carrier systems entailed. Of course, we added general best practices to data tables and other minor optimizations that were low hanging fruits.
For the portion of binding a policy, this was more involved and required working closely with the agents to observe habits. I sat with various agents in one-on-one situations for 2 hour windows. The process was very similar across all the carriers but it was important to observe how each agents' process - how they accessed information to build trust when talking to a customer, how they objection handled education and confusion, and how they used the various levers of adjusting a policy. This task for me was less about gathering feature requirements but rather optimizations for task completion.
Naturally, I had to play around and analyze the competitor portals myself, and came to a solution that balanced agent preferences like a tabbed, streamlined process, while maintaining logical hierarchy of information so their conversations mirrored how they scrolled through the UI.
I designed an experience that avoided having information in a tabbed format because scannability was so critical for our agents. Switching tabs to find, review, and compare information was very cumbersome, so a single view with clear navigation was important. With a long single view, we had to design against easy navigation, so a simple table of contents UI element could help anchor agent's to appropriate sections.
We opted for a very focused workflow for our agents, only exposing what was important but making sure navigation was always available. I gathered anecdotal feedback on things the UI should include, while balancing the important features for MVP - being able to bind a policy vs. optimizations which would help the agents work faster. Examples, we opted to reprioritize was the ability to compare multiple prices to help a customer balance different coverages. However, things like education tooltips was important and something easy to implement.
I used an Invision prototype which was very helpful in gathering workflow feedback and general visual feedback, but wasn’t substantial to getting feedback on repeated actions. There was one particular screen that an agent would use 90% of the time, which was the initial price view - the starting point for conversations with customers. My initial draft of the price screen utilized designing for space, legibility, hierarchy, and scannability. I tried using very modern web components and maximizing real estate since we have to display large amounts of information which could feel overwhelming to scan so many fields. In order to get proper usability feedback, the team had an engineer build a quick demo.
With this working prototype, it was easy to test for scrolling fatigue, use of navigation, data input and information hierarchy. I had a few testing sessions with our agents and after observing a few of them, it became clear that there was a lot of scrolling to find information. Each agent had their own preferred screen resolution which added to the complexity of vertical real estate. It was never verbal feedback but you can see how the agents would scroll up and down and sometimes click the navigation when they skip past a section.
I had to revisit the screen as it was the most important and most utilized views in this system. I had to emphasize space in a different sense - maximizing real estate. Agents wanted their information always present without much scrolling. Scannability in this new design didn’t mean labelling and having headlines, but making it easier to scan large amounts of information - by focusing on fields they always confirm with the customer and then hiding the secondary information. The UI challenge here was balancing modern design components with what the agents loved about the old outdated systems - compactness of information. Tables were our friend.
The importance of testing designs with your users. Every textbook will tell you this, but in practice, it's easy to lose sight of this. The benefit of internal tools is that it lends itself to easy testing as our users were readily available and willing participants. There was no need to handle the nuances of external consumer testing so this allowed for more iterations.
Iterate early and often for the best results. At Cover, we have a large team with many sales agents, so it was easy access to a large pool of testers. With internal users, I could bypass formal sessions and even chat informally about designs and show my progress much quicker.