EMBROKER · FINTECH / INSURANCE · SHIPPED PRODUCTIncreasing multi-product insurance adoption
I redesigned Embroker’s multi-product quoting experience to help customers evaluate additional coverage, understand different product states, and move through a more complex insurance application with greater confidence.
The project in 20 seconds
Embroker is a digital insurance platform for businesses, offering multiple types of commercial coverage through one online experience.
Customers often arrived looking for one insurance product even when their business could benefit from additional coverage. Introducing more products created more value, but also more decisions, product rules, and application complexity.
Increase multi-product adoption while keeping coverage decisions understandable and the application experience manageable.
I led product framing and journey design through prototyping, testing, delivery, and post-launch optimization based on real user behavior.
Shipped and iterated.
The resultThe Law bundle submission rate increased from ~56% to ~64% after post-launch iteration.
After launch, real behavior showed where the multi-product application was creating unnecessary friction. Removing an extra pre-application step increased submissions immediately, while changes to how pricing appeared helped customers move through the application with less distraction.
The work also created a more scalable foundation for adding products to the same quoting and application experience.
Project details
Embroker
Digital business insurance platform
Multi-product quoting and application
Product / UX Designer
Existing product expansion and workflow redesign
Shipped + post-launch iteration
Product growth · Coverage selection · Complex forms · Conversion
Insurance products rarely exist in isolation.
Businesses often need several types of coverage, but customers may arrive at Embroker looking for only one.
The product opportunity was to help them understand when additional coverage might be relevant without turning an already complex insurance decision into an upsell funnel.
Bundling created more value and more decisions.
Bundling could create better protection for customers and more product value for Embroker. But every additional product also introduced another decision, more unfamiliar terminology, different eligibility rules, and potentially another application.
The design problem became: how do we increase adoption without increasing cognitive load faster than customer value?
When should customers discover additional coverage?
How much information do they need to decide whether it is relevant?
How do we preserve momentum once multiple applications are involved?
A simple-looking quote flow was carrying several systems at once
What looked like a single customer journey was actually a coordination problem across coverage selection, product-specific applications, referral states, pricing behavior, quote outcomes, and backend constraints.
I mapped those dependencies so design decisions could be evaluated across the whole journey rather than optimizing one screen at a time.
The core tension
Customer decision-making ↔ insurance rules ↔ pricing ↔ backend constraints
A decision that made one moment feel simpler could create complexity somewhere else in the flow.
Complexity map
Coverage selection
Application flow
Quote review
Referral states
Pricing behavior
Backend constraints
Post-launch behavior
Coverage selection
Application flow
Referral states
Quote review
Pricing behavior
Backend constraints
Post-launch behavior
Helping users evaluate bundled coverage
I didn’t want customers to choose additional products simply because they were presented prominently. The experience needed to explain why a product might matter, what it covered, and what adding it would mean for the journey ahead.
I explored different ways of presenting recommendations, coverage context, and bundle choices before converging on a model that balanced education with momentum.
Early exploration focused on where additional coverage should appear and how much explanation customers needed before deciding.
What we learned
Testing showed that customers understood the quote-estimate questions, but many felt there were too many clicks before reaching the estimate.
In coverage-selection steps, users liked the overall structure but wanted more detail on some products. A prominent benefits banner, however, was largely overlooked.
The lesson was clear: information helped when it appeared at the decision point, not when it was presented as extra explanation around it.
Move guidance to the moment of decision
Instead of relying on a separate banner to explain the value of additional coverage, I moved relevant product information closer to the choice itself.
The goal was to make guidance visible when users were actively deciding, without making the overall experience feel heavier.
Design for mobileMaking quote states clearer across products
Once several products could exist at different stages at the same time, a single bundle-level status was no longer enough.
I moved status communication to the product level, so customers could understand which products were eligible, referred, declined, or still in progress without interpreting the bundle as one ambiguous state.
Product-level states made it possible to communicate different outcomes without reducing the entire bundle to one ambiguous quote status.Fully Eligiblepartially declinedpartially referredreferredMake partial outcomes feel intentional, not broken
A multi-product quote could produce mixed outcomes: one product might be eligible while another was referred or declined.
The final direction used clear grouping, plain-language support, product-level actions, and reassuring save/exit language so customers could understand where they stood and what they could do next.
This made referred or partially declined states feel like a defined part of the process rather than an error condition.
BeforeAfterReworking the flow around backend and charging constraints
The experience couldn’t be designed as one clean front-end sequence. Different products had different backend requirements, eligibility outcomes, start dates, charging behavior, and application states.
I mapped those dependencies and redesigned the flow around them so the customer experience could accommodate variation without exposing the underlying technical complexity.
The important question changed
Early on, it was tempting to ask:
Which screen looks simpler?
But the more useful question was:
Which flow gives customers enough clarity while still supporting the business and technical logic required to ship?
initial flowRevised flowImpact
Launched in 4 months
From big-room planning to MVP release
Under 1 → over 1.4 policies per customer
Policies per customer in the law vertical increased within 6 months
+17% application submissions
After removing the “Before you begin” screen
~56% → ~64% law bundle submission rate
After removing persistent dynamic pricing from the application flow
What happened after launch
Four months after big-room planning, the MVP launched as a special two-product offer for the law industry.
The product became the company’s most successful product. The enhanced law experience meaningfully contributed to stronger multi-product adoption, higher premium per customer, and increased zero-touch producer interactions.
By July, policies per customer in the law vertical had increased from under 1 in January to over 1.4. Premium per customer continued to climb, and zero-touch producer interactions per customer increased from 47.5% in Q3 2022 to 51% in Q1 2023.
Later iterations improved the MVP, addressed issues that appeared after launch, and expanded the flow to include two additional products.
Post-launch optimization
Launch gave us evidence prototypes couldn’t: real behavior under real product conditions.
I used those signals to revisit assumptions in the original experience and make targeted changes rather than treating the first release as final.
Iteration 1: Reassurance became friction before users needed it
What we saw
Users were dropping before they reached the actual application.
What changed
We removed the standalone “Before you begin” step and moved the essential guidance into the application itself.
What this showed
Information intended to reassure users can become friction when it appears before they need it.
Removing the “Before you begin” page increased application submissions by 17%.
Iteration 2: Pricing helped when it supported the decision
What we saw
Customers were more likely to complete the application when pricing wasn’t persistently visible throughout the flow.
What changed
We removed fluctuating persistent pricing and surfaced the estimate at the moments when price actually supported a decision.
What this showed
Transparency still mattered, but timing mattered more.
The law bundle submission rate increased from approximately 56% to 64%.
What the final experience optimized for
The final experience connected coverage selection, quote review, application logic, pricing behavior, and post-launch learning into a more scalable multi-product model.
Coverage decision support
Customers needed enough context to evaluate additional products without feeling pushed into a bundle.
Application momentum
The flow needed to avoid intimidating users before they had started.
Product-level quote clarity
Different products could have different outcomes, so quote states needed to be visible at the product level.
Implementation-safe logic
The flow needed to support real backend, start-date, and charging constraints.
Pricing at the right moment
Price transparency mattered, but persistent fluctuating price visibility created friction.
Scalability
The MVP later expanded to include two additional products, so the structure needed to support more than the first release.
Reflection
This project reinforced that designing for trust doesn’t mean showing users everything upfront.
In insurance, there’s a natural temptation to explain every requirement, price change, eligibility detail, and edge case before customers move forward. Real behavior showed that too much information at the wrong moment could make the experience feel heavier rather than safer.
The strongest improvements came from removing unnecessary friction, reconsidering when information appeared, and continuing to refine the experience after launch.
It also reinforced how I like to work: treating complex workflows as living systems shaped by business logic, implementation constraints, and real user behavior — not just polished first releases.
The goal wasn’t to make insurance simple.
It was to make each decision clearer at the moment it needed to be made.
Next project →Rebuilding Micetro’s design foundation for WCAG AA readiness
Bringing a legacy enterprise interface closer to BlueCat’s design system while improving accessibility and implementation quality.