
Auto insurance
crm application redesign
Overview
The client, an auto insurance product provider, tasked us with creating a replacement portal that would allow financial managers at auto dealerships to quote prices on their insurance products, and create and finalize the contract.

Take a Closer Look
my role
UI Designer, UX Researcher
Deliverables
-
Dual-Branded Design System
-
User Research Report
-
High-Fidelity MVP for Desktop and Tablet
GOALS
-
Create a new point of sale system that allowed financial managers to rate a product, take customer information, lookup VIN, and create and finalize a contract.
-
Take two legacy systems for two different brands and consolidate into one working system.
-
Create a flexible design system that accomodates two existing brands and can be easily adapted for other brands in the future.
-
Do a round of usability testing to verify the validity of the MVP.
How might we improve the rating and contracting process in order to reduce the cognitive load on insurance managers?
Initial
Research
The initial stage involved conducting a brief examination of competitors to gain insight into car insurance rating systems.
Findings
We discovered that competitor dashboards consisted of minimalists UI, easy-view dashboards and E-Signature capabilities.
We took inspiration from the dashboard design. E-Signature was shelved for a later iteration.

main features
The design of the new CRM revolved around three main features: Rating Matrix, Stepper, and Collapsible Menu.
Rating Matrix
The Rating Matrix was designed to be able to view all the different rates available for a vehicle to allow for easy and fast decision-making.


Stepper
The stepper was a feature brought over from one of the legacy systems. It allowed us to create a more intuitive process, while reducing the learning curve for users already accustomed to the stepper.
Collapsible Menus
The collapsible menus allowed for better organization on a platform that is information-heavy.
It allows users to focus on one task at a time, while simultaneously being able to see what they have previously done; something they weren't able to do before.

updating the flow
We created a service blueprint in order to map out the new flow. The original process was done in one scree and was not intuitive to new users. We wanted to update the process in order to reduce the onboarding time for any new users. The service blueprint helped establish the new process while taking into consideration current and future product environment.

Wireframes
Outcomes
We began the design of the new system with low fidelity screens. Because we had a quick turnaround for this project, we designed high-detailed low fidelity screens that could be swiftly updated once we established the final designs and any changes to be made during usability testing.
Below are detailed descriptions of the two most important screens.


Product Selection Screen
1. Dealership Access - allows hiring managers who work at multiple dealerships to quickly change their workspaces.
2. Vehicle Information - allows view and access to key information on every page.
3. Remove button - Quickly remove unwanted products
4. Added Icon - Easily see which products have been selected.
5. Add Payment Plan button - Easily view which products have a payment plan option and quickly make changes.
6. Quotes - Quick view of only the products that have been added.
7. Save Button - Save button allows user to save their progress. Auto-Save can be enabled or disabled.
8. Total - See a running total of all products.

Quote Summary Screen
9. Exit Button - Allows the user to exit the session. Session can be picked up at last saved point at a later date.
10. Product Summary - Product and details can be viewed before finalizing a decision.
11. Draft Contract - Draft of contract can be viewed before finalizing.
12. Edit button - Allows for changes to be made to a specific product.
13. Dealer View - Allows dealership to view their price versus the sale price and adjust accordingly.
14. Finalize button - Finalizes the purchase and generates the final contract.
usability
testing
For usability testing, we created a test script and conducted virtual testing sessions with employees from the client site. Since we were not able to test with actual insurance managers, we chose employees with close proximity to the rating process and adjusted our questioning accordingly.
Outcomes
Usability testing went well and there was no changes to the flow.
However, some of the content needed to be adjusted as the language differed from brand to brand. Adjustments were noted and to be changed during development.

Design
system
Along with the screens, we also delivered a style guide for two brands to the client.
In the style guide we included the variations for each of the components within the designs, as well as some edge cases that may potentially be needed for future iterations.

Below is an example of the the style guide created as part of the deliverables.
Responsive
Design
For usability testing, we created a test script and conducted virtual testing sessions with employees from the client site. Since we were not able to test with actual insurance managers, we chose employees with close proximity to the rating process and adjusted our questioning accordingly.
Outcomes
Usability testing went well and there was no changes to the flow.
However, some of the content needed to be adjusted as the language differed from brand to brand. Adjustments were noted and to be changed during development.

final designs
next steps
Development
The final designs were sent to the development team for production. At this stage, I was rolled off the project and had no visibility to any changes or outcomes.
Learnings
-
This was a fast-paced project. It was important to iterate quickly in order to deliver on time. Leaning on best practices was important, and experimenting was saved for important features like the rating matrix.
-
When conducting usability testing, it was important to pivot when we weren't able to test with actual users. In order to gain reliable information, deciding to test with users who have previously used the system or closely aligned to the ecosystem was the second best use case.