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.
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...).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.