When natural disasters, power outages, and other major events cause excessive losses, insurers can’t pay out all their customers. Reinsurance is when insurance companies resell a part of their risk to other insurance companies.
An insurance underwriter goes to a reinsurance broker who would go into Relay to find other insurance companies to help. I built an application-quote-compare workflow. And the Risk Tower shows exactly how insurers will share the risk.
In the example above, I wrote a $50M policy, but I can only cover some of it (beige portions). So, I put out a call for quotes on the 3 dark layers. I’ve found a taker for 50% of the topmost layer (blue).
Product Overview
This case study focuses on the Quote Comparison screen, specifically the Risk Tower visualization. However, this 1-minute overview of the whole product I shipped may help to convey the bigger picture.
Where Risk Tower Fits Into Workflow
As I researched examples and interviewed experts, I saw that sophisticated brokers manually create visual aids for 3 reasons:
- Summarize request for providers
- Track progress/gaps
- Present to clients
Process for the Visual Design
Research on What Already Exists
I collected examples of how deals are structured, including various types of Excel spreadsheets and diagrams customers were already using. I found these online as well as from our customer partners. But there was a great deal of ambiguity in what type of customer and towers we should be designing for:
Exploratory Concepting
I concepted 4-5 different layouts on paper. Then I held a whiteboarding session with the team to figure out which design best fit what we knew and could commit to. We did dot voting and discussed the pros-cons of each.
I often do my divergent thinking on paper. It offers maximum flexibility without being distracted by aesthetic details. To test specific details I use a Figma or HTML prototype e.g., “Will a floating button here feel distracting?”
Questions for design included:
There was also the data entry UX that drove the tower visualization:
I experimented with different ways to create layers in bulk for larger deals:
Feedback & Iteration
I designed an early version of the Risk Tower and quote comparison screen. I got preliminary feedback from reinsurance brokers and made revisions. I then worked with engineers to ship an early version. Then over the next year and multiple projects, I iterated on this experience, adding new features to the Tower. There were a lot of unknowns, a lot of shifting customer requests and market focus.
There were many other UI/interaction challenges that I worked to solve:
- New ways of structuring reinsurance we didn’t anticipate, like taking sub-slices
- Showing layers that are too thin e.g., insurer quotes 1% of the width of a layer
- Tower sits on top of another tower (so the visual scale is skewed or unknown)
- Risks that require 2 or more towers with different structures
- Showing “non-quoted” retention = absence of a layer or different type of layer?
What Was Most Difficult
Domain Expertise
No one on the product team knew about reinsurance, but I quickly became a domain expert through research and customer conversations. Customers often shared contradictory information, used inconsistent language, and described complex, varying workflows. To address this, we hired former brokers, and I brought in external SMEs to prepare before engaging with customers.
Ambiguity and Scope
I was inundated with information, making it hard to see which risks are worth taking, which problems are worth solving, and which customer stories represent wider market opportunities rather than rabbit holes. To get unstuck, I used techniques like visual mapping, breaking down issues, making assumptions, and seeking input from others.
Big Picture Challenges
Brokers spent significant time assembling complex risk towers. But what qualifies as complex? Is complex really our target segment? Will what I’m designing scale?
Multiple Participants, Multiple Views
Designing multi-participant experiences meant always considering how a change on one side affected other parties. For example:
- Broker submitting an application users tower to request and view quotes
- Insurance Provider viewing the application uses tower to see where their quotes lie with respect to what is requested
Here is what it looked like for a broker to enter a risk tower and view quotes visually:
On the insurance provider side, things were similar but with important differences. For example, we had to be careful not to reveal information the broker needed to keep confidential for any given provider.
There were also multiple internal personas with different interests. For example, managers needed to a way to restrict how big of a tower you can put together:
Sample UI Challenge: Overlapping Layers
Quotes could overlap, hiding other quotes underneath. Over time, I introduced several features to help the users disambiguate layers and make it easier to assemble the Tower.
Version 1 simply ignored this potential problem while I continue with research. Later I added a disclaimer:
I later added an intro animation for visual interest and to highlight how layers stack:
Later, what I decided was to add interactions to tackle overlapping more directly:
- ability to hide/pin quotes to the graph
- on-hover dotted-line preview of where the quote is next to other quotes
- mini-preview on each quote card, showing that quote in isolation
Sorry for the quality but this screengrab from a public demo:
I carried this “mini-preview” component into this dashboard header for example:
Here is an exploratory concept for overlapping layers and making the tower more interactive. This one came from a conversation with a customer to resolve “oversubscribed” horizontal layers. Its advantage is that is shows the number of participants (which overlapping hides). It might have worked if most carriers quoted within the requested layer but it didn’t work more generally:
In a later iteration of this concept I explored the ability to show number of layers and drill into and sign down the oversubscribed layers:
Aiding Analysis
When speaking to one customer, I saw that they were using Excel to keep track of which quotes had conditions attached. One provider might take a layer as-is, while another might take it with strings attached. To help customers make an apples to apples comparison, I designed an interaction that highlighted the presence of conditions:
As a result, the user could prevent situations where a claim happens, and it’s not covered, because an exclusion was overlooked. That could be worth millions.
Growth Tactics: Interactive Widget
To give organic leads a taste of how our app visually structures risk, I designed a simplified widget for our home page. The visitor could add some layers and then was guided to sign up and continue their submission:
Other growth tactics included an onboarding flow with tips, such as this one here explaining how to Accept, Counter, or Decline an offer (screengrab from a demo video):
I also designed a role play tutorial which welcomed new users:
Measuring Success
We knew our feature saved time for brokers who put these together by hand, but this effort varied widely among brokers. We also knew from customer feedback that the Tower added a valuable “delight” factor.
To evaluate the overall submission workflow including the Tower visualization, I continuously interviewed customers and helped them quantify their time saving from getting, comparing, and choosing quotes:
In this 1 minute testimonial, a customer says they could process submissions 50% faster:
Future Iterations
I wanted to move layer labels into the tower itself. So I made the tower larger to fit them. I also explored the ability to add free annotations to any part of the tower:
I also spent time concepting replacing quote cards with a table comparison for more complex deals:
I also concepted ways to assign layers-to-providers if it should come to that (many-to-many):
Closing
Reinsurance was a complex enterprise product I worked on for 2-3 years. I played a key role is shaping vague and conflicting information into actionable concepts we could test and ship.