William Man
- 4 min read

Guy Carpenter - Data Visualization

Guy Carpenter & Company, LLC is a leading global risk specialist in reinsurance — wherein insurance companies divvy their liabilities with other insurance companies.

As succinct and defined as that description is, Guy Carpenter was a tricky client to design for, let alone understand. I was the sole designer for this project, responsible for synthesizing the madness that was their data models, currently existing in the form of thousands upon thousands of spreadsheets of context-specific data.

Without inundating you the reader with the endless glossary of terms that drove our team's cognitive load to its limits, the first challenge was in understanding the contrast between Dashboards, Views and Filters, best exemplified by a broker's ideal user flow.

Not only was the project a massive undertaking in creating three individual but co-dependent data visualization dashboards, I had to leave room for potential growth for other future platforms (wait till we get there...).

Loss Profile

Every screen in the Loss Profile dashboard is an aggregated data summary of projected losses for any combination of Perils, Regions, Lines of Business, In Force Dates, and Models. These could result in completely different data visualizations, table structures and could even affect options available in each other.

As you can see, the Filter options share View names minus the current view (e.g. We can see the summary of perils in the Perils view and narrow down the data to only represent their numbers under specific regions, lines of business, etc).

Nailing the concepts and flow in lower fidelity would have guaranteed quicker turnaround. Unfortunately, there was a push internally to move to design immediately — a decision I rued not pushing back on. After all, even the client themselves had difficulty comprehending their own business requirements and syncing them with the initial mockups made.

"What's the difference between the Perils View and the perils filter?" - The Client

Of course explaining the intention of the first few designs the client was important but each new iteration built on the idea that the design should speak for itself. Working in high fidelity without 100% certainty was a dangerous game we were playing, resulting in numerous time-consuming changes.

However, the requirements gathering sessions were always enlightening and gave us what we needed for the fifth and final design.

Elements were moved all around while new ones were being introduced to accommodate ideal user interactions. Ultimately, our revisions culminated all essential feedback and user needs:

In Force Dates and Models are co-reliant so they were intrinsically married
Business Units, Dashboards, Views and Filters (now made unhidden) were organized in respective order to match the ideal user flow
Views and Filters were reduced down to the essentials with Date selection moved to the graphs themselves
Slider controls have manual min/max inputs which update the chart and graphs programmatically
The legend was integrated into the chart for more visual clarity and to give the graph more emphasis to the user

Working closely with the development team to determine the logistics and effort of what's possible, I redesigned the page to simplify a seemingly non-simple platform. As we finally wrapped up what we thought were the phases into Zeplin, we would never imagine our subsequent dashboard views would inevitably get us back to Loss Profile.

Exposure

We worked with the dev team to understand the best practices for storing and saving the cache so information is not lost when moving to other dashboards such as Exposure, which allowed users to evaluate data on a more granular level. But step one was to set realistic design goals and resist the team's urge to move to designs prematurely.

With the foundation set from Loss Profiles, reiterations were kept to a minimum. But as someone who insists on preparing for the worst case scenarios, I realized that these initial wireframes would not cut it for situations with up to eight subview options.

The first thing to note was that Exposures had "In Force Dates" in the form of filters. The design solution could not be exactly identical to Loss Profile and so we truncated the other filters module to give room for In Force Dates.

The Overall module was made smaller and shifted to give more emphasis to the more granular information, which is what users care most about in Exposures

But how do we choose these perils/regions/LOBs/characteristics, you ask? This was done initially via "Edit" button which brought out a side panel wherein a user may manually select their options. However, we gradually realized that having more automated filter options would definitely streamline the experience without compromising the manual selection feature.

These new design solutions here were solved many issues but we would have to go redesign these shared components in Loss Profile

Data Quality

Data Quality was unique in that it contained sub-dashboard views, both quite distinct from one another, but both with the intent of comparing data.

Peer Comparison

A broker can compare their performance with the average, high and low ends of their peer median performance under any filter criteria, in the form of box-and-whisker plot charts. The first hurdle to overcome was how to categorically organize information with these charts as the In Force Dates were illegible placed side-by-side.

In all our wires and designs, we test to ensure that all information can and will fit on an average broker's screen, without compromising on legibility

Following some design patterns from Exposure, the information was grouped by dates while still giving the user a quick glance to compare the dates and subview performances simultaneously. A back and forth with the client regarding the overload of data onscreen indicated that some of the "user needs" were really more of nice-to-haves. Some satisficing had to be made without removing key features.

The user and peers' performance data, initially on the base level, was placed inside tooltips to reduce visual sensory overload

Your Comparison

For brokers wishing to see their overall performance evaluation going from one date to the next, the design for Your Comparison needed to be analogous to Peer Comparison but obviously subsisted of a completely different data visualization.

Initially, the supplementary information consisted of up to three subsets of numbers to the left of the bars, which would have been manually toggled on/off by users. We argued that less was more in this scenario and settled on the most minimally viable sets of data only.

Although it used the more straightforward bar graph format, the function of this view required more direct compare/contrast of the broker's score as well as providing supplementary information.

At this phase of design, we pushed forward as much as we moved took necessary steps backward to retroactively enhance previous views to keep our design patterns consistent (i.e. showing the quantity of regions/perils/etc., making edit functionality constant).

Pushing into Design System

Each step of the design process was meticulously made and revised to fit the needs of Guy Carpenter's day-to-day user. And certainly this CliffNotes' summary of this lengthy and arduous project definitely leaves out the clients' reluctance to give us immediate feedback until hours before delivery, the hurdles optimizing designs for development to fix bandwidth issues working with their colossal library of data, and the laundry list of industry lingo that would turn this case study into an odyssey.

When the full handoff had finally happened and I had accomplished my part in designing their overwhelming CAT-Modeling platform, the success of what we had created had spread to the rest of our client's team.

As of this writing, Guy Carpenter has requested us to design and document a full Design System for their future platforms. With the direction being geared more towards Angular Material as a basis to start on, our approach will be to borrow many needed components from the developed CAT-Modeling platform (saving our team tons of time and effort) while moving forward and exploring new areas which haven't been covered yet.

The Final Prototype

You can see the entire design deck made for this project here.

WILL MAN DESIGN