End to the Traditional Call Center
Redesigning the user experience of an insurance company’s response website in order to reduce call center volume.



North Highland Consultancy
UX/UI Designer


Jacqueline Wrona (Account Manager)
Tyler Scherr (UX Director)
Stephanie Lewis (Research and UX)
Jordan Reiser (UX Designer)
David Cook (Copyrighter)

August 2020 (one month)
The team was tasked with drilling down and understanding the home insurance process to provide a soluton that would fulfill the needs of Assurant’s customers that received an Action Required letter. In turn, this would reduce their customer service call volume.
I was part of a 6-person team bringing UX/UI skills to the table. We would drill deep into the home insurance process, identify the area of concern and pain-points, and then translate this data into a high-level experience for the user.
Product Design
User Research, Interaction, Information Architecture, Visual Design, Prototyping, & Pitching
Assurant is an insurance underwriter with home coverage as part of their repertoire. The problem was their customer service call center was receiving a large volume of calls in relation to letters they had sent to borrowers of insured mortgages with issues that needed to be resolved. An online portal was already in place to handle the requests but didn’t seem to be working. Ultimately the user would become frustrated and/or confused and revert to calling Assurant’s customer services. The team at North Highland was enlisted to define the problem through research and discovery and provide a prototype of the letter/email content, online portal, and phone IVR system to hand-off to Assurant for them to test and develop further.
Understanding the Process
Gaining an understanding of what the insurance policy process looks like was necessary to be able to create a successful solution. From this diagram, we can see clearly the different reasons a user would need to interact with Assurant because of the different letters that are sent out. We can also use this to build a more detailed journey map for the user in each instance.
Identifying the Issue
The below graphic shows understanding of where in the customer’s journey the issue is occurring. It’s not that the customer is unable to complete their task, it just becomes another step for them to take in order to revert from the online portal to calling into customer services. Also, the latter is struggling to handle the call volume.
User journey and pain point identification
The team was able to build an in-detail and extensive journey map with in-depth research and data collection which gave us deep insight into the whole process and validate Assurant’s concerns. With this, we are able to discover the pain points which will guide and validate our design decisions moving forward.
Macro Journey
The research and journey map creation checked-off some validations but also revealed some major issues beyond the scope of this particular project. Below are listed highlighted points from the letter being sent by Assurant, but issues also exist with the independent agents and inability to discuss information across company lines:


  • The borrower is unaware or unclear what they did pay at closing or where the premium goes (to insurer or to escrow).
  • Borrowers may not understand the need for a certain coverage type (e.g., flood insurance for a condo) or may not believe they have insufficient coverage.
  • Borrowers may not be aware that they are responsible for notifying when insurance changes over.


  • The letter scares borrowers because they don’t understand what the letter means.
  • The letter isn’t specific about which documents are required.
  • The wording of the letter is the biggest reason people call in irate. Update with letter content.
  • The letter still has a pin number that doesn’t work, frustrates customers, they still have to call Assurant.
  • The insurance company may send Assurant wrong information because letters are vague.
  • The borrower is unaware of what is needed of them (what they paid at closing, where the premium goes, etc.)
  • When the branded letter is sent, the transfer of the lender leads also to a welcome packet or cancelation notice which makes the borrower confused.
  • Employers think graduates are underprepared.
The research and journey map creation checked-off some validations but also revealed some major issues beyond the scope of this particular project. Below are listed highlighted points from the letter being sent by Assurant, but issues also exist with the independent agents and inability to discuss information across company lines:


  • The insurance agent is also unaware of the loan purchases.
  • Agents are paying Assurant, so they don’t want to do the work for us.
  • The borrower doesn’t understand why the insurance agent can’t just talk to us.


  • Assurant Rep can’t discuss the closing documents to talk about it with the customer. Has to call mortgage organization.
  • The borrower doesn’t understand that their mortgage company cannot just call and cancel their old policy.
  • No way for the borrower and Assurant rep to see the same information so becomes a game of telephone.
  • Assurant rep doesn’t have a good way to communicate to the borrower. A way to provide them with tools to provide to the agent about what’s needed.
  • Assurant doesn’t have visibility to client emails sent to borrowers, but they may cause borrowers to call Assurant.
  • The borrower is upset because the insurance company will not talk.
  • Assurant Rep required to do research on closing documents to understand what was paid, where premiums went, etc.
In Summary
Although there are issues with the letters/emails being sent to the borrowers, there are major issues outside of Assurant’s immediate control with the independent agents and the loan companies. These will be presented to the client but it needs to be made clear that we can not extensively solve the high call volume issue by redesigning the letter content, IVR system, and online portal.
Online Portal
<enter text here>
Product vision
For us to be able to develop a product that would solve all of the pain points discovered in a single product would be untenable. So we needed to use the data collected to determine a single product that would best help MCC increase their graduation percentage.
We wanted to give students insight and clarity into what their potential chosen majors would consist of in learning content and timelines, as well as showing tangible career opportunities post-graduation. This in theory would reduce the risk of students changing majors due to unsatisfactory experiences and unexpected surprises.
We also recognized that faculty expressed they were underpowered and falling behind with efficiently monitoring student’s progress and preventing dropouts.
This would be a white-label product, educational institutions would have the application branded in their specification to fit within their existing assets. Initial high-fidelity designs would be branded through the parent company and used as demos for client meetings.
Product MVP

We came up with the idea of using a pathway or tree-style interactive interface that would show student’s potential pathways through different majors and the potential career opportunities when they had graduated. The data for this interface would be collected in two different areas:

  1. The content for the majors would be supplied by the educational institutions
  2.  The career opportunities would be data taken from alumni and online data repositories

We would also create a parallel product that would be a tool for faculty to monitor student or cohort progress via a quick-glance platform.

Where would we get the data from?

We would need to pull from multiple sources of data to make the product viable. For the student major content, data would come directly from the institution on a year by year basis. For the careers section, data would come from Alumni networks through Facebook, LinkedIn, and the institutions themselves.

We understood that student participation was crucial to the success of their progress and the product as this would be ultimately optional for them. Therefore, making the product appealing to students in an interactive way is paramount. Enter the use of data visualization through D3JS coding technology.  Below is a quick introduction along with an example of how the interface would work and look.
Secondary product features

With the implementation of D3JS coding technology, we created 2 other smaller functionalities that would sit along-side our MVP:

For students
  1. A study group organizer, to promote a working community outside of the classroom
  2. A progress monitor that would use the same interface as the MVP to show the student their performance, whether they are meeting all targets, failing some or falling dangerously behind.
  3. A direct course to careers connection interactive platform that provides a quick and clear graphic of prospective career opportunities in correlation to major courses.
For faculty

The ability to message a cohort or an individual student, with the purpose of discussing their progress status.

White Paper

In preparation for pitching to educational institutions, we brought all our research and development data together to create a white paper.


From the flow-map I created a low-fi version of how the UI of the product would look and how the user would make their way through and interact app. At this point, we all made suggestions and edits in order to push the product to be A/B tested.

UI Guide

I created the UI elements, sections, and templates. I then created the high-fi front end version that we could take to client meetings and presentations.

Final UI Design
Outcomes & Personal takeaways
On the surface it was disappointing that we never managed to get the product into a live environment. We did however place second in two startup competitions, made substantial progress with MCC as our potential first client, and made numerous connections with students, faculty, and the start-up community.
Narrow my focus more
In hindsight, we probably tried to cover too many of the pain points we discovered, too early and this muddied the water with a concept that was brand new. This was a invalueble lesson to focus on one MVP, bring that to market and then branch out.
First impressions are key
Hackathons give us the oportunity to develop a dream product to address a problem, and this is where clients care mostly about how their users will interact with our creations. Being careful not to make the product too complex, no matter how sexy, is key to a successful conclusion.
Collaboration makes for better outcomes
2 heads are better than 1, well in this case, 4. This was the perfect collective, all bringing different skills to the table that we could push our product so far in a short space of time. It requires alot of care bringing the right people into a small team.
Next Project
States United to Prevent Gun Violence