Marcus White - Senior Product Designer Portfolio

Context

Bold Penguin's design system is called Emperor UI. According to its history, it was established several years ago alongside the development of Bold Penguin's flagship product—the Bold Penguin Terminal (formerly known as the Agent Terminal). Initially, the design assets were distributed across Bold Penguin's three primary products: the Exchange, the Bold Penguin Terminal, and Storefront.

Final result preview

View Protype

My role, team, year and timeline

Challenge

Status quo

Process

After understanding the initial problem statement, we explored various ideas about adding functionality to skip carrier question sets and discussed where this feature should exist in the application process. My starting point was mapping out basic user flows: both the standard "happy path" through an application and what a skippable flow would look like. Next, I created light mockups comparing two scenarios: one showing an application with a single carrier's questions answered and others skipped, and another showing the traditional flow with all carrier questions completed.

We began tackling this challenge with a kickoff meeting where all stakeholders gathered to share discovery questions. As this was my first e-commerce project, I needed to familiarize myself with common terms and elements in this space. Following the kickoff, I informed stakeholders that I would create wireframes for initial concepts of our new Quote Presentation page. These concepts would then be reviewed with our Product Manager and Director of Product for preliminary feedback.

At our initial kickoff meeting, we aimed to review product documentation, understand the core problem, and create design mockups for potential solutions. The design task seemed straightforward—I planned to draw inspiration from existing insurance documents and proposals, using a template-based approach for the PDF. Our engineering manager suggested an alternative: showing how the application would look using our design system's UI components for simplicity. Though I privately thought this wouldn't work, I created a demonstration to illustrate why UI components wouldn't translate well to print format. The team ultimately agreed that UI components weren't suitable for a PDF document.

After receiving feedback from our Director of Product on the initial mockups for skipping carriers, we tackled a new challenge: enabling users to jump between carrier question sets, whether completed or not. The main challenge was determining how carriers would appear in the Real-time eligibility panel panel (RTE) and how to display their statuses. Once users reach the carrier question sets, all carriers in the Real-time eligibility panel panel (RTE) become unlocked. We needed to clearly communicate this flexibility to end users.Through several rounds of design iterations and feedback, I tested various combinations of iconography, verbiage, and status indicators for carrier elements within the Real-time eligibility panel panel (RTE). After multiple team reviews, we began to reach consensus on the preferred design concepts.

Building on the wireframe concepts, our initial designs focused on the user journey from Quote Presentation through quote selection and checkout. Key discussions centered on two main questions: whether to include a shopping cart feature in version one of Bind & pay, and whether to create dedicated product detail pages for quotes beyond the existing tab view. We conducted extensive comparisons with traditional commercial insurance experiences, and the design phase extended several weeks as we incorporated various stakeholder feedback.

The initial designs received strong positive feedback from the team. During our brainstorming session, we identified a few minor changes to experiment with. The main suggestion was to organize the application with separate columns for questions and answers, making it easier to scan down the page and match answers with their corresponding questions. We also discussed what client and agent information should appear in the header, and whether to include Bold Penguin's logo. I implemented these subtle changes within a week and presented the updated design to the team for review.

After making design progress on the functionality of skipping and jumping between carriers, our next challenge was handling multiple insurance products from a single carrier. Within the Bold Penguin Terminal, agents choose which coverage types to include in their application. As they proceed to the carrier question sets, one carrier might offer multiple coverage types. For example, if Jane Smith wants General Liability and Workers' Compensation for her florist shop, a single carrier like Chubb might offer quotes for both types after she completes their question set.

The design challenge was deciding how to display multiple coverage types from one carrier in the Real-time eligibility panel panel (RTE). Should we show Chubb's General Liability and Workers' Compensation quotes in the same card or separate cards? While the decision was straightforward—multiple cards would take up too much vertical space—executing it elegantly was complex. Through trial and error and valuable team feedback, we created a clean, user-friendly solution that displayed multiple coverage types within a single carrier card.

We also explored using a bottom sheet card to display estimated annual premiums and price ranges for selected coverage types. While leadership liked this concept, we ultimately chose a different approach for showing pricing information.

As our design effort progressed, we decided to put the shopping cart feature on hold and allow users to purchase only one policy at a time. The happy path user flow emerged with these steps: Quote Presentation page, a detailed Product Page for final application edits, and Checkout for selecting payment plans and completing legal acknowledgments. During a feedback meeting, stakeholders informed us that payment information would not be collected within the Terminal. Instead, we would overlay an iframe on top of the checkout experience, allowing users to enter payment details on the carrier's portal. After payment processing, users would see a policy bound page displaying their policy number, agent contact information, and downloadable policy documents.Through subsequent meetings, I discovered that carriers with the Bind & pay feature would implement different checkout payment experiences. Homesite would use an iframe overlay for payment information, Markel would redirect to their carrier portal for payment collection, and Hiscox would offer an iframe with direct bill options for customer invoicing. We uncovered these details during feedback sessions with our carrier partners, gaining deeper insight into their payment collection processes. This meant our Bind & pay happy path would now include three distinct variations based on the carrier.

Since there were no major questions during our final feedback session, we were able to finalize the designs and add the project to our development backlog. We held one refinement meeting with our engineers to discuss the designs and address questions, with only minor changes made afterward. From a product standpoint, we needed to decide on the official feature name and what to call the PDF document by default. Working with the product owner, we changed the title from "Bold Penguin Application Summary" to "Bold Penguin Documents."

After making significant design progress, my next task was to create a clickable prototype showing the ideal user journey. We planned to present this prototype to our target customers in user interviews to gather insights about their understanding of the new features and their expectations.

During a recent customer feedback session with InsureCherokee, we gained valuable insights about the product. The participant, an experienced user, praised the ability to skip to competitive carriers and the design's simplicity. They also suggested additional features to enhance the product's usability for their specific needs. Here are the key takeaways from the discussion.

The participant found the ability to skip non-competitive carriers highly beneficial, allowing him to focus on carriers that are known to be competitive for specific classes.
The panel design, particularly before and during carrier question sets, was well-received.
Grouping by carrier and presenting estimated premiums were highlighted as useful features, providing clarity and actionable information.
The ability to skip to carrier-specific question sets and bind directly without completing other steps was seen as a significant efficiency booster.
The participant emphasized that endorsements are critical for contractor policies, suggesting the inclusion of endorsements to showcase the full offering.
When asked for any dislikes or areas for improvement, the participant stated there was nothing he disliked, reinforcing the product’s helpfulness and usability.

The feedback session with InsureCherokee affirmed the product's potential to streamline workflows and deliver competitive advantages. We conducted six customer feedback sessions in total, and I participated in five of them.

After syncing with our product manager about the carriers' different payment collection methods, I revised the designs to show the user flows for Homesite, Markel, and Hiscox. I fine-tuned these designs and created prototypes to demonstrate the experience to agents. During the customer feedback session with several agents, our product manager led the discussion while I took notes, which I later reviewed to identify common patterns.After gathering customer feedback, we uncovered several key insights that raised important questions:

How would we handle additional interests on commercial insurance applications?
How should we manage payment failures on third-party pages?
How could we deliver policy documents for carriers without API support?

Additionally, we faced technical complexities around application editing during the checkout process. We needed to decide whether to implement this in a modal or full-screen page, and determine which application sections users could edit. While we had made significant progress with the overall design of Bind & pay, this feedback highlighted the need to prioritize features carefully for the initial launch.

In our final round of designs, my challenge was to showcase the entire application process with our revamped Real-time eligibility panel panel (RTE). This included demonstrating various scenarios: completing carrier applications and receiving quotes, handling error responses, skipping certain carriers, leaving some incomplete, and finally reaching the quote presentation page. The final layer of complexity involved showing how users could return to the application to complete remaining carrier questionnaires and see their quotes update accordingly. While this was a complex process with numerous design challenges, our team collaborated effectively to bring it across the finish line. We held two refinement meetings with our development teams to address edge cases and distribute the workload. Overall, this has been one of the most enjoyable projects I've worked on at Bold Penguin.

Several weeks into the Bind & pay design process, we reached an inflection point where I was asked to hand off the Checkout designs to our Lead Product Designer while I pivoted to focus on Quote Presentation designs. As a team player, I accepted this decision, but after returning from a week-long vacation, I discovered our lead designer had significantly altered many of my Checkout design concepts. While this was humbling for someone who takes pride in their work, I set aside my ego and had a professional conversation with our lead designer about the importance of design consistency across our efforts. I saw this as an opportunity to establish a more theoretical vision for our design system and its guidelines. He agreed, and together we worked toward creating and documenting a unified solution within our design system.

After handing off the checkout designs, I returned to redesigning the Quote Presentation page. Since we planned to rebuild this experience from the ground up, I saw an opportunity to create a traditional, familiar e-commerce layout. I explored both grid card and horizontal card layouts. Insurance being a detail-oriented industry, we faced the challenge of displaying comprehensive information while maintaining visual clarity. We ultimately chose the horizontal card layout and enhanced it with distinct sections. In rebuilding the Quote Presentation page, we organized it with sections for quotes ready to bind, an upsell section, and a bottom section for quotes needing attention or those ineligible. Our final design incorporated several use cases:

American Family quote feature choice option
American Family referrals for exploring other markets
Multi-carrier and multi-product options
Additional tabs for our exchange product
Commonly used ACORD forms
An Intercom button for user support

As we completed the designs for all primary screens within the checkout experience, we reached a solid foundation to discuss implementation with our development teams—focusing on how to bring this experience to life for our agents and carrier partners.

Final result showcase

Impact

Through the final design and several refinement sessions with our Development Team, we resolved many of the original challenges we set out to address, including:

E-Commerce Goals

Looking back, this feature was very significant for us to ship because, as I would later learn, we had future goals of adding e-commerce functionality within the Bold Penguin Terminal product line. This feature was implemented at the right time to build toward deeper policy purchase functionality.

Headstart on devwork

Fortunately, since significant backend work was already complete, the development team was able to work on this epic in Q4 of 2022 and deliver it on time and within budget. I'm writing this in Q4 of 2024, and the Real-time quote eligibility feature has required very minimal design or development maintenance.

The implementation of Homesite as the featured choice for initial quotes.

The ability for agents to purchase, issue, and finalize policies for their clients while remaining in the Bold Penguin Terminal.

We created better alignment on which features to prioritize in the initial release of Bind & pay based on what matters most to our pilot customers.

Looking ahead to 2025, the team has several tasks planned for Q1 before the full launch of this product feature. As a result, we cannot yet measure the full impact of how users will receive the Bind & pay feature once it's enabled.The main goal of Bind & Pay is to fulfill our contractual agreements with American Family Insurance. While this means the team has limited priorities for monitoring the feature post-launch, we will track several key metrics in the Terminal to measure its success and evaluate this new functionality.

Number of policies bound

Terminal conversion rate

Checkout abandonment rate

After launching the initial phase with our pilot customer, our product team will collaborate with the business intelligence team to track these KPIs within the Terminal to measure success. Bind & Pay is scheduled for a V1 release to our Enterprise customers in Q2 of 2025.

A successful release will be indicated by Terminal Users downloading the Application Summary primarily when they don't receive successful quotes. We hypothesize that Terminal Users will have fewer complaints about incomplete or incorrect ACORD form mappings since they can use the Application Summary as an alternative. Here are the metrics we plan to track through the Business Intelligence Team:

Number of downloaded "Application Summaries". Track from applications with and without quote failures

Usage of "Application Summary". Number of carriers that users receive quotes from & how many quote failures they receive on average

Our engineering team started work on this project in Q4 2024, but due to recent transitions within the product team, it has been placed back in our product backlog. We plan to launch alongside the rollout of our Bind & Pay feature in Q2 2025.

Learnings

From UI Kit To Organized Atoms - 2022 Recap

I joined Bold Penguin in Q1 2022. At the time, there was only one other designer—Lead Product Designer—and I worked under his guidance while collaborating with the product team. My first assessment of the design system revealed a basic UI kit with foundational "Atoms" design assets. I set out to inventory all our design assets and reorganize them into a more cohesive system.

This process required extensive communication with our Lead Product Designer to understand component usage patterns, brand guidelines, and how Emperor UI worked in practice—from initial wireframes to shipped code. Through trial and error, we refined our approach.

Enhancing the system through product epics - 2023 Recap

Bold Penguin's design system is called Emperor UI. According to its history, it was established several years ago alongside the development of Bold Penguin's flagship product—the Bold Penguin Terminal (formerly known as the Agent Terminal). Initially, the design assets were distributed across Bold Penguin's three primary products: the Exchange, the Bold Penguin Terminal, and Storefront.

Design system maintenance - 2024 Recap

Throughout 2024, we focused primarily on major features, particularly the "Buy and Pay" effort that consumed most of Q3 and Q4. This left little time to maintain our existing design system. Fortunately, we welcomed a new associate product designer to our team.

We assigned the associate extensive design audit work in 2024, which served as an opportunity for him to learn our products, features, and design system thoroughly. I spent considerable time answering his questions and explaining the nuances within our design system that might not be immediately apparent in our patterns. As our team grew, I recognized we needed to better document our visual language philosophy so that anyone at the company could understand our design patterns without requiring direct consultation. Much of this knowledge resided with our lead product designer, and I worked closely with him to document these nuances.

In Q3, our three-person design team developed an improved system for implementing small design fixes with our product owners. The process was straightforward: we would show the existing UI alongside the proposed new UI, provide clear descriptions for developers, create tickets in Jira, and discuss them during refinement meetings with product owners. This streamlined system helped our product and design teams make frontend improvements more efficiently without requiring full design audits.

Focus for 2025

Bold Penguin's design system is called Emperor UI. According to its history, it was established several years ago alongside the development of Bold Penguin's flagship product—the Bold Penguin Terminal (formerly known as the Agent Terminal). Initially, the design assets were distributed across Bold Penguin's three primary products: the Exchange, the Bold Penguin Terminal, and Storefront.

Vision

As a product designer, my vision for our design system centers on treating our tools and resources like Lego blocks—use the existing ones you need, discard those you don't, and create new ones when nothing suitable exists. When we create something new, we add it to the toolbox and document it to maintain a clear inventory. While the reality is more complex, my goal is to work in harmony with our engineering teams so we can both do our jobs effectively, bringing our visions to life with minimal friction. I've drawn significant inspiration from design system experts like Dan Mall from Design System University and Brad Frost, author of Atomic Design, whose deep domain knowledge has helped shape my vision.

Challenges

By far, the biggest challenge within our design system has been buy-in from all team members. While our Product Owners have been great and supportive advocates of our design system efforts, our Lead Product Designer has presented significant obstacles. To be frank, he doesn't follow many of our design principles—including ones he established himself. He doesn't use Figma components, Figma frames, or auto layout. Instead, his design style involves creating new elements and implementing them whenever he feels they fit, without seeking approval from others. Having worked solo for so long, this is likely his preferred method, but as our team has grown, it's become difficult for him to work collaboratively with other designers.

This has been one of the biggest challenges of my career. While I've learned much from him, I've also learned valuable lessons about what not to do. Though the majority of organizing our design system has fallen on my shoulders (with strong support from the Product Team), I recognize I can't do it alone. Moving forward, I'll continue working across the company to make our system easily understandable to everyone, clearly communicating how and why we make certain decisions, and gathering feedback for improvements.

More projects

Contact info