Homeowners Insurance: Designing a 0→1 Product
Designing a carrier-integrated homeowners quoting experience under real underwriting and API constraints.
Role: Senior Product Designer
Timeline: 6 months
Team: Product, Engineering, Underwriting
Platform: Consumer Insurance Platform
This work required evolving an existing production platform to support an entirely new business — without forking the legacy system.
The Problem: Obie was launching its first homeowners insurance product, requiring a brand-new quote flow that balanced agent speed, underwriting rigor, and strict carrier API constraints — while also laying groundwork for a future universal quoting platform.
This wasn’t an incremental redesign. It was a 0 → 1 system that needed to be bind-ready on day one without locking the business into fragile patterns.
The Constraints:
Carrier & Technical Constraints
- Markel rates required live API calls tied to risk profile changes
- Some data (insurance score, enrichment) could not be recalculated arbitrarily
- Rater performance meant we could not “ping on every keystroke”
- Validation rules varied by package (HO3 vs HO5 vs HO6)
Business Constraints
- MVP needed to support bind-ready flows
- Some coverages were required for underwriting but not agent-editable
- Scope had to align with broader Project Runway platform strategy
The challenge wasn’t simply designing a new quoting flow —it was designing a safe, reversible system that agents could confidently modify without introducing underwriting risk, performance degradation, or irreversible states.
That framing shaped every design decision that followed.
My Role & Impact
As the Senior Product Designer, I led the end-to-end design of Obie’s first homeowners quoting experience — from early system architecture through final interaction design — in close partnership with Product, Engineering, and Underwriting.
My primary responsibility was designing a safe, reusable quoting architecture that balanced agent speed with underwriting rigor under strict carrier API constraints. This included defining how and when validation, enrichment, scoring, and re-rating occurred, and establishing a section-based information model that could scale beyond Markel to future carriers without redesigning the flow.
I drove alignment across stakeholders on high-risk tradeoffs, translated underwriting rules into agent-usable patterns, and ensured the system remained predictable, reversible, and bind-ready from day one.
Key Decisions & Tradeoffs
Designing the Obie’s first-ever Homeowners quote flow required a series of high-stakes decisions at the intersection of agent experience, underwriting safety, and system performance. In several areas, there was no objectively “correct” answer — only tradeoffs.
My role was to frame these tradeoffs clearly, pressure-test options with Product, Engineering, and Underwriting, and drive alignment on decisions that balanced near-term usability with long-term platform health.
1. When and how to trigger carrier rate calls
Context
Markel rates were returned via live API calls and tied directly to the risk profile. While agents expect near-instant feedback, calling the carrier on every input change was both technically risky and performance-prohibitive.
Options considered
Trigger a rate call on every change (best UX, highest performance risk)
Lock risk-affecting data after submission (safest system, poorest UX)
Trigger re-rating only when validated, risk-meaningful changes occurred
Decision
I established explicit re-rating checkpoints within the flow. Changes that materially impacted risk (e.g., property characteristics, underwriting answers, package selection) triggered re-validation and re-rating, while non-rating changes did not.
Why this mattered
This approach preserved the perception of speed for agents while protecting the system from unnecessary carrier calls. More importantly, it made system behavior predictable — agents could understand when a change would affect price, rather than experiencing opaque refreshes or unexpected delays.
2. Editing identity data after insurance scoring
Context
Insurance score calculation required personally identifiable information and could not be safely recalculated arbitrarily. However, agents often discover corrections to name or DOB later in the quoting process.
Options considered
Lock identity fields after scoring (lowest risk, poorest UX)
Allow edits without recalculating insurance score (moderate risk, strong UX)
Allow edits and recalculate score on every change (highest risk)
Decision
I defined a model where identity data could be edited post-scoring without triggering a score recalculation, while clearly codifying when scoring occurred.
Why this mattered
This decision respected real agent workflows without introducing unnecessary underwriting or compliance risk. It was a deliberate compromise: optimize for usability where possible, and apply rigor only where it meaningfully reduced risk.
3. Supporting package switching mid-flow (HO3 ↔ HO5 ↔ HO6)
Context
Agents frequently adjust coverage recommendations based on client budget or property details discovered mid-quote. Restarting the flow to compare packages would have significantly degraded the experience.
Options considered
Lock package selection once chosen
Allow package switching but force a full reset
Support package switching with controlled re-validation
Decision
I designed the flow to be package-agnostic at its core, layering package-specific validation and rating logic on top. Switching packages triggered appropriate re-validation and re-rating without requiring a restart.
Why this mattered
This enabled agents to explore options naturally while ensuring underwriting accuracy. It also established a scalable pattern for future carriers, rather than hard-coding package logic into the flow itself.
4. What to expose vs. hide in coverage customization
Context
Many coverage options were required for underwriting but not meaningfully actionable by agents during quoting. Exposing everything risked overwhelming users and slowing quotes.
Options considered
Surface all adjustable and optional coverages
Hide advanced coverages entirely
Surface a curated set for MVP, with others available post-bind
Decision
I advocated for a curated MVP customization experience, exposing only high-signal, agent-actionable options while reserving more technical coverages for post-bind policy editing.
Why this mattered
This reduced cognitive load, accelerated quote completion, and avoided presenting false choice. It also allowed the team to ship a bind-ready product without over-designing edge cases prematurely.
Why these decisions mattered
Individually, each decision improved a specific part of the flow. Collectively, they established a guiding principle:
Design for flexibility at the agent level, safety at the underwriting level and repeatability at the system level.
This principle later informed broader platform work under Project Runway, ensuring the homeowners flow didn’t become a one-off solution that would need to be unwound as the business scaled.
Final Flow & System Architecture
Before finalizing screens, I defined the system architecture for the Markel Homeowners quote flow — focusing on how state, validation, and rating would behave as agents moved forward and backward through the experience.
The diagram below illustrates the final architecture that shipped.
System architecture for the Markel Homeowners quote flow.
⭐ indicates dynamic checkpoints where agent changes trigger validation, enrichment, re-rating, or eligibility enforcement.
Annotated Example: Section-Based Underwriting Architecture (Carrier-Agnostic)
While coverage customization reused existing landlord patterns, the core challenge was designing a reusable, section-based underwriting and property information architecture that could support Markel — and future carriers — without rework.Rather than designing a one-off homeowners flow, I focused on building a reusable, carrier-agnostic property information framework. This screen illustrates how underwriting rules, validation logic, and derived values were embedded directly into the UI without exposing complexity to agents.
What This Architecture Enabled
This architecture was finalized ahead of launch and designed to support initial release with Markel on 4/6, while establishing a scalable foundation for future carriers.
- Carrier-agnostic underwriting framework
Property and underwriting questions are rendered dynamically from carrier rules, allowing new carriers to plug into existing sections without redesigning the flow.
- Section-based reuse across products
The same property information and underwriting sections were designed to be reused across homeowners, landlord, and future products with different eligibility and rating logic.- Safe, reversible editing model
Agents can move forward and backward through the flow while the system deterministically controls when validation, enrichment, and re-rating occur—preventing accidental underwriting or performance issues.- Progressive disclosure of risk signals
High-impact underwriting questions surface early and contextually, while standard properties move through a low-friction path without unnecessary interruption.- Future carrier onboarding efficiency
New carrier requirements map into established sections rather than requiring bespoke flows, reducing long-term design and engineering overhead.
Rather than designing a one-off homeowners experience, this work established a reusable underwriting architecture intended to scale across carriers and product lines.
Launch Readiness & Measured Outcomes
While this flow launches on 4/6, success was defined and instrumented before release to ensure we could validate both agent experience and underwriting safety.
Key success signals include:
Quote completion rate across standard properties vs edge-case properties
Frequency of re-rating events per quote (guarding against excessive carrier calls)
Agent back-navigation behavior without forced resets or errors
Time-to-quote compared to legacy landlord flows
Underwriting exceptions surfaced post-bind
These metrics were chosen deliberately to validate that the system balanced agent speed with underwriting rigor — the core goal of the project.
This project reflects how I approach complex systems design: start with constraints, design for reversibility, and optimize for long-term platform health without sacrificing near-term usability.