Product Insurance Microservices
Streamlining policy management and underwriting reports
Product
Desktop Web App
Client
Confidential BC Government Ministry
Role
UX/UI Designer
Project Management
Michael Hostettler
Market research
Hey there, this is the
Persona
Hey there, this is the
Wireframes
Hey there, this is the
High-fidelity UI
Hey there, this is the
User Research
Hey there, this is the
Flow diagrams
Hey there, this is the
Visual Design
Hey there, this is the
Usability Testing
Hey there, this is the
Hey there, this is the
Hey there, this is the
Hey there, this is the
Hey there, this is the
Confidentiality
In order to preserve the privacy and confidentiality associated with this project, designs, subject matter and branding have been changed to mask the subject matter and keep the true designs in the hands of the client.
The target user group has been slightly altered and the research findings have been edited as to not reveal the specific subect matter of this work.
Problem Space
Summary
Product insurance microservices utilize underwriting to assess risks associated with insuring specific products, thereby determining appropriate coverage terms and insurance premiums for policyholders.
Context
An insurance premium is the fee that a company pays to an insurer to protect their products against potential losses or damages.
Underwriting is a process within insurance that involves evaluating the risk of insuring a product, considering factors such as the product's value, susceptibility to damage, environmental risks, market conditions, and insured entity's risk management practices. This evaluation assists insurers in setting policy prices that accurately reflect the risk associated with insuring particular items.
Product insurance microservices are digital tools or systems designed to manage and handle insurance policies for specific products or items. They focus on ensuring that these products are protected against damage, loss, or other risks, and they facilitate the process of claiming insurance benefits if something goes wrong.
Market Research
The Claim
The Canadian insurance market is anticipated to expand significantly, reaching a gross written premium of about CAD $157.7 billion by 2024. Non-life insurance segments are expected to dominate, projecting a market volume of about CAD $112.7 billion in the same year.
While Canada's insurance market growth is notable, the United States leads globally with a projected gross written premium of CAD $6,314.7 billion in 2024.
The Opportunity
Looking ahead, the Canadian insurance market is poised for further growth, with a projected annual growth rate of 2.85% from 2024 to 2028, potentially reaching a market volume of CAD $176.10 billion by 2028.
Notably, there is increasing demand within Canada's insurance sector for digital platforms aimed at enhancing customer experience and operational efficiency. The insurance industry is experiencing a profound digital shift, leveraging technologies such as AI, machine learning, and blockchain to enhance operational efficiency, improve customer experiences, and introduce innovative products.
User Research
User research and business requirements were gathered leading up to and throughout the design process.
Overview
IThe project manager for this work gathered most requirements related to user and business needs. These requirements were communicated to me to provide efficiency and allow for more design time. Designs were reviewed with the business users and various stakeholders for feedback. This is an overview of the business and user needs collected over a period of 4 months where there was ongoing discussions of requirements with both the technical and business team.
Key Findings
Data Visibility
There was a strong need to improve the amount of data being presented within the tables on the policy profiles. This was important to the users because this is where they spend most of their time while using the product, inputing and reviewing data. It was important that we showed more information within this section while also ensuring that information was easy to consume and data was still easy to edit and manage.
Color Coding
Another key request from the business was to use color coding in order to provide a constant reminder to users about which pages they were editing. This was a solution brought forward to minimize mistakes while inputing and managing policy information.
Visual Distinctions within Cells
Something that I had noticed while doing my preliminary usability analysis was that different cells with the policy profile tables had different abilities. Some cells could be edited by typing text into the cell, some cells required the user to open a modal to edit the cell values, some cells provided a drop down of potential values, and some cells were read only.
An important aspect of usability is that users have some sort of visual to help them distinguish what actions are available to them and this was falling short in the original design. This was a complex challenge to solve, but an important one to improve the overall usability of this table.
Research Analysis
I created a persona to consolidate my research findings and to keep my users' needs at the front of my mind throughout the design process.
Flow Diagram
To outline the primary functionality, I created a simple site map of the primary feature flows.
Wireframes
Once the flow diagram was established, low-fidelity wireframes were created of the primary flows.
Policy List
Policy Details
Visual Design
Once the initial flow was complete, fonts, colors and branding elements were defined for use during high-fidelity design work.
Color Palette
Blue Shades
Policy Color Coding
Grey Shades
Text Colors
Font Styling
Noto Sans
14px, 15px, 18px, 20px, 22px, 26px
Regular, Medium, Semibold font weights
3 Body Fonts
3 Header Fonts
Primary Body Typography
Noto Sans, 15px font size, 20px line height, 400 font weight
Branding
The original branding for this project was altered to maintain client confidentiality. The updated branding chosen was centered around a very saturated blue. This color was chosen because it is associated with trust, dependability, and professionalism. It suggests security and reliability, which are crucial for an insurance product that deals with safeguarding people's assets and well-being.
Most of the iconography used throughout this product is from Google Material. This product relied heavily on iconography especially on the policy details tables in order to differentiate actions within the various cells. Iconography also acts to reduce visual clutter on the page. Special attention was paid to which iconography was chosen on the policy details page and the size and color of each icon to maximize room for data while still maintaining readability.
High Fidelity Designs
Discover
Search, filters and lists
When the user logs into the product, the landing screen is the policy list since policy management is the primary feature of this product. Users can find policy and manufacturer information by using the filters above each table.
On the policy list, the user can generate reports on the policies they select using the checkboxes in the table. Since reporting wasn't a high priority for this work, the ability to create reports continues to function from the policy list.
Minimal changes to the reporting feature were designed and implemented to ensure usability. One example is that prior to the re-design there was a a drop down in the filter section that had to do with generating a report, but did not actually filter the search results on the policy page. That drop down was removed and added to a pop-up modal that displays when the user selects the download button.
Policy Details
Primary Inventory
The policy details screens were where most of the design and development time was spent as this was the primary feature of the product where the majority of the user's time was spent.
As mentioned in the research section of this case study, the primary goal of the re-design was to make the policy tables display more information and make it easier for the user to input information into the table accurately. To help indicate to the user which page they are on, color was added to the three tabs that exist on the policy details page.
Before the re-design, color was added as a background color to the full page. In order to reduce the visual strain for the user, color was removed from the background and instead added to the information containers and to the alternating table rows. This way the color is present, but is also acting functionaly when it comes to the table, enabling users to more easily track which rows they are editing by using an alternating row color.
I was able to re-design the three views of the policy details screens in a way that displayed more data on the tables eliminating the need to scroll horizontally on the three primary views. I paid close attention to the potential values that each cell could hold to reduce the possibility of truncated text. In order to do this, I spoke to the technical and business team to find out what the typical length of characters would be for the various table cells. This informed the minimum and maximum width I set for each column on all of the tables on the three policy screens.
Secondary Inventory
Another concern with the UI was that different cells on the policy profile tables had different functions or abilities. Some cells could be edited by typing text directly into the cell, other cells required the user to open a modal to edit the values, some cells provided a drop down of potential values, and some cells were read only.
This difference was not indicated visually, initially the user would either have to learn which cells were editable and what actions could be performed through trial and error and then eventually learning and memorizing the interface. In order to address this, I used different iconography to indicate which cells allowed for different actions. For instance, all cells that could be directly edited on the page have an edit icon within them.
If the user selects the 'more columns' button, a larger table displays where the user will likely need to scroll horizontally even on larger computer screens. Fortunately, I was able to ensure that the primary information that would be most commonly used fit within a screen size that the business reported would be a typical size for employees.
Declaration of Production
All of the policy screens have three special scrolling behaviors to improve the workflow for the user. The first scrolling behavior can be seen when scrolling the full page. A portion of the information at the top of the screen remains fixed while the rest of the screen scrolls. This was important to the users because they needed to be able to reference information in the green container at the top of the screen regularly throughout their process.
The second scrolling behavior is that the table scrolls independently of the rest of the page. If the user hovers their mouse over anywhere within the table, the table rolls scroll within a container that has a fixed height meaning the amount of space the table takes up on the screen is the same despite the number of table rows. The purpose of this was to ensure that if the table happened to have 100 rows, then the information sitting below the table wouldn't be pushed too far down the screen making it less convenient to find that information or even risking the possibility of some users not realizing there is information below the table at all.
I also made sure that when the user is scrolling the table, the column headers were fixed so that the user always knows what type of information they are viewing and editing.
Policy Modals
Policy screen interactions
The policy details screens have a number of interactions where a modal displays to provide the user more information and functionality. Some of the functionality available within these modals includes the ability manage inventory comments, link policies details, add fields to the table and manage row item details. When designing the interaction modals, I made sure to keep potential warning in mind that may display after the user enters details into the form.
I also re-wrote various tooltips that display when the user hovers over iconography on the table to ensure clarity. I replaced iconography within the table where I anticipated potential usability issues.
Support Data
The designs I created for the rest of the screens within this product had minimal changes, which I confirmed during review with the technical team. If something added too much complexity, it was revisted in order to find a simpler solution.
Some of the additional screens that I re-designed included the support data screens. The information entered on the support screens impact policy data so it is an important part of the system. I created a couple of design solutions to improve usability and I ensured that the iconography used within the policy details tables was brought over to these screens for consistency.
Prototype
Prototypes of the primary flows were created to aid the design process and gather feedback from the users, business and technical team.
Design Validation
High fidelity designs were used to gather feedback from the users, business and technical team.
Feedback Sessions
Feedback sessions occured over Microsoft Teams with the business team, technical team and users/employees. I asked questions to ellicit feedback, such as how many potential policies could be related to each other to get a sense of whether or not the design solution I chose was suitable for the typical use cases.
Hide on Printout
One of the improvements the business wanted to see was to have a column that allowed the user to hide and show different rows from the printout. It was also important that these rows be highlighted in some way so that the user could easily tell while scrolling the table which rows would not be displayed on the printout.
There was alot happening visually on the policy tables with the added iconography and alternating row colors so I approached this request by ideating and creating many different options.
I presented the ideas to the development team and we discussed the technical complexity of each solution and the known user needs based on the research so far and we landed on a solution that highlights the row making it a shade darker with 1.5px thick border.
In addition to adding the border and highlight, I added a column to the table named ' Hide on Printout' with an icon that when selected changes to symbolize that this row has not been hidden on the printout.
Positive Feedback
There was positive feedback when the team saw the final designs and it was a rewarding experience to have proposed design solutions that addressed the concerns of the client while staying within the expected scope of the project.
Responsive Tables
In the original product, the tables were not responsive. In order to create responsive tables, I specified minimum and maximum widths for each column on the various tables present on the policy profiles.
Through discussion with the business team, I found out the most common length of characters used within each of the columns so that I could specify suitable minimum and maximum widths. I specified fixed widths for columns that only display icons or show more predictable content (such as dates) so that space would be used more efficiently.
By specifying minimum and maximum widths, the table is able to shrink or expand in width to accommodate different devices without allowing the columns to shrink to a size where information is no longer easily readible. When the content exceeds the width of the cell, it is truncated, but if too much of the information is truncated within the table cells, it could hinder the user's ability to accomplish tasks efficiently.
If the full table cannot be shown on smaller devices because the minimum widths have all been reached, then the table will scroll horizontally.
Handoff
Tickets
Once designs were completed and approved, I started writing tickets that would be passed on to the developers who would then review them and assign a time estimation based on the requirements outlined in the ticket. Within a ticket, I write a user story to communicate the user need that we are addressing as well as technical acceptance criteria. Technical acceptance criteria includes any changes to the current functionality and system behavior.
I also provided a link to the design within figma. When the developers click on the link they can see CSS styling details and spacing information to help them accurately implement the designs. I spent approximately 2 week writing tickets for all of the design improvements.
Quality Assurance
After development starts on the design tickets, I login to the dev environment to see the progress and to perform quality assurance on the design. If I notice anything that doesn't align to the designs, I will write a ticket. I will include a snapshot of the current implementation showing where I saw the issue and if it's not something simple and straightforward, I will include a visual of the desired state with some annotations to help communicate as clearly as possible.
Learning Opportunities
This was an interesting project for me because I noticed a shift in my work and communication style that was likely the result of the learnings I gained on the projects leading up to this one. I could tell that the structure of the feedback loop was well-designed for my work style and the overall team I was collaborating with.
Making space for more contemplation
One thing in particular that stood out was my ability to communciate design rationale to my review team and to allow myself to take things away to contemplate further if I did not have an answer right away. I found that I gave myself more time to contemplate issues further even if that meant getting back to people in a day or two. Often times this would also give me time to prepare a quick and simple visual explanation to aid the discussion and work through my thinking.
I also found that I took more time to bring forward additional visual solutions to my developers so that we could find the simplest approach when there were concerns about technical complexity. Sometimes these concerns weren't voiced directly. By meeting regularly we had become more familiar with each other and I think that this is an important aspect of effective collaboration.
Weekly design discussions
Having weekly check-ins with one or more people to discuss design and technical impacts was very useful not only in the way that it encouraged collaboration, but in how it created familiarity and understanding between cross-functional team members.
In the past I have been on projects where check-ins were as needed and whenever design work felt ready for review, but whenever I scheduled those meetings it felt like I never had enought time to go over all of the items that I wanted to discuss in detail.
On this project, I found that even if I didn't have an entire screen ready, there was often a section that I was ready to start reviewing and definitely a series of questions related to the design that had been brewing all week. Being able to ask questions ongoing about the user's needs was really important for the design work to progress at a steady pace on this project and to also feel like I had the right level of information to make informed design decision at each step of the way. I hope to continue this practice on future projects.
Ways to Connect
Feel free to reach out to me if you'd like to learn more about my experience and design work or if you would like to collaborate on something in the future.
© Jacqueline Williams 2024 • UX Designer