0 to 1 · Enterprise SaaS · Health Insurance
Designing the Health Insurance Quotation Engine
Getting a quote used to mean emailing the underwriting team and waiting 2–7 days. I designed the flow that made it self-service by putting an actuarial pricing engine on screen without the broker ever feeling it.
Role
Product Designer
Timeline
2 Months
Team
Underwriting Head, Engineer, Me
No PM
I helped define the product
1 · Setting Context
The problem
Before this product, getting a quote meant emailing company details to the underwriting team, who manually consulted actuarial spreadsheets and replied days later. By then, the client had often moved on.
The real cost wasn't time , it was the deal. A broker who shows a live quote in front of a client builds trust in the platform. A broker who says "I'll email you in a few days" loses that client.
The two relationships:
Field brokers configure coverage in front of clients and need to convert interest into a number before it cools.
The underwriting team defines the actuarial limits behind every benefit and needs certainty that anything outside those limits routes to them, not silently approved.
2 · Discovery
The Matrix
Before designing a single screen, I spent time inside the actuarial pricing matrices. For inpatient alone: 30+ coverage rows × 10 family structures. Outpatient, maternity, optical, dental, and wellness each carry their own matrix.
Screenshots from underwriter's excel sheets. Figures shown in these screens have been altered from the real actuarial values, since that data is commercially sensitive.
Reframed Problem Statement
The design challenge wasn't making a form. It was making an actuarial pricing engine feel like something a broker could do in five minutes — without realising the complexity of the structure hidden underneath.
3 · The decisions
Three decisions that made the matrix disappear
Each decision below was tested with 3 of Eden Care's 5–6 active field brokers — roughly half the people who use this flow daily — across three moderated iterations.
Decision 1 — How should a broker set a benefit limit?
Every slider position maps to a row in the pricing matrix. The question was what control lets a broker land on a financially exact number fast.
Option A
Rejected
Flat form
All inputs visible at once. Looks like a
spreadsheet. Doesn't communicate which
values are valid for which context.
Option A: Flat form
Rejected. Testing showed brokers had to read and parse the pre-approved limit as text before they could even decide what to type. For one broker, this single step visibly slowed the entire flow.
Option B: Slider only
Rejected. Testing surfaced something we hadn't planned for: two of three brokers used the slider to get close to their target, then asked to type the exact number, a path the interface had no room for. The third skipped the slider entirely.
Option B
Rejected
Slider only
Brokers who know exact RWF amounts
have to drag precisely. Too imprecise for
financial inputs.
Option B
Shipped ✓
-
+
-
+
-
+
-
+
Slider with +- and input box
Brokers who know exact RWF amounts
have to drag precisely. Too imprecise for
financial inputs.
Option C: Slider + stepper + direct input.
Shipped. The hybrid the brokers were already trying to perform: slide to get close, step or type to land exactly. All three brokers reached their target fastest with this version and every position still resolves to the same actuarial sheet driving the pre-approved range.
Final UI of Option C: Slider + stepper + direct input.
Slide to get close, type to land exactly both behaviors testing surfaced, in one control.
Decision 2: Setting family composition
Family size feeds the same pricing matrix- each composition is a different row. Free-text number fields risked invalid entries and gave no sense of how composition affects price.
Steppers shipped: fast, tactile, hard to make large errors, zero stays zero until consciously changed, and the current state is always visible. The running "Total covered lives" count gives the broker one number to verify against the client's headcount.
Option A
Rejected
Number inputs in a form
Errors are invisible until submit. A broker types 500 instead of 5
and won't notice until the premium looks wrong.
Option B
Shipped ✓
Steppers — +/− controls
Fast, tactile, hard to make large errors. Zero stays zero until
consciously changed. Current state always visible.
Final UI of step 3: Configuring family size
Decision 3: The one that could'nt be fixed
We signalalled the moment a user selected something outside pre apporved limit that its outside limit , at the benefits step itself. We could only indicate that, we could not give them the actual amount that will be estimated unless all 4 steps are filled, because the quite not just depends on one input selected out of scope. Maybe the user selects a co-pay that balances out the exedding limit of outpatient and brings the quote in pre- approved range. What shipped: a "Custom quotation" tag offered as an option at the moment of excess- out side pre approved range, with the true path confirmed only at the summary. Some constraints are correct, not just inconvenient.
There are only two scenarios where a user can select options that would lead to custom quotation.
When broker enters a custom limit outside of pre approved limit, a modal appears immediately: "Custom Quotation"
When "Specify own co-payment" is selected, a modal appears immediately: "Your quotation will be reviewed by our underwriter." No surprises at the end.
Always telling them at the moment of choice
4· The core system mechanics
One flow, two silent paths
Every configuration a broker builds — benefits, limits, family composition, co-pay, period — is evaluated against the pricing matrices as a whole. By the summary step, the system has already determined which of two paths the quote belongs to:
Why there's no running premium
One feedback we received was to see a live premium ticking along as the broker configures. We deliberately didn't build it. Routing and therefore price depends on all five inputs together: a high inpatient limit can be offset by a conservative co-pay choice. Any number shown mid-flow would be a guess the system might have to walk back at the summary and a broker dispays one number at the start and another number at the end page to a client, in person, loses exactly the trust this product exists to build.
The premium appears once, when it's true.
5· The other side
What the underwriter receives
The underwriting team's requirement was that nothing outside the approved range gets silently approved. Save and Send delivers on it: an out-of-range quote arrives in the underwriting queue with the full configuration and the specific limits that triggered review — not a raw email to reconstruct from scratch. Underwriting attention now goes only where actuarial judgment is genuinely required.
If you have any underwriter-side screen, even lo-fi, it goes here. If you don't, this copy stands alone — but be ready for "what does the underwriter actually see?" in interviews. Designing even one v2 concept screen for this queue would strengthen both the case study and your interview story
6· Outcome
Outcomes
Eden Care publicly states this on their broker page: "Get customer - ready quotes in an hour"
Within pre-approved limits the premium itself is instan- the sub-hour figure covers the full broker workflow, from client conversation to a sent quote. Both figures were confirmed directly by the underwriting head against the field broker team.
Underwriting is now involved only in configurations that genuinely require manual review, not every quote regardless of complexity.
If I could revisit v1
Saved plan templates in v1
Brokers configure similar setups repeatedly for similar clients. Deferred to v2. Watching someone recreate the sameconfiguration from scratch is a specific kind of painful to watch.
Add a review timeline for underwriting queue
Custom quotations enter a queue with no visible turnaround. A rough estimate - even just "usually within 24 hours" would significantly reduce broker anxiety and support requests.
Add tier types.
Employers want to give their employees health insurance based on certain categories. We got this insight when the brokers reached clients with more than 500 employees.
7· What I'll carry forward
The Learnings
Watching two of three brokers switch between slider and manual entry mid-task made urealise that both kind of behaviours live in one interaction.
Letting the user know in the moment of choice which input is making the quotation go out of pre- approved range was important. But the total calculation of what the quotation would be can only be known once all 4 steps have been filled. Some constraints are correct, not just inconvenient. But we understood why the data only resolves once all five inputs are in. And I designed the solution so that users knew when the quotation is going out of set limits and might lead to custom quote.
We tested with people who would actually use our product on the field. 3 of many field brokers talked to us, and those insights drove the final design decisions.
