Homeowners Insurance: Designing a 0→1 Product

Designing Obie's entry into the $100B+ homeowners insurance market while building reusable platform architecture for future growth.

Role: Senior Product Designer
Timeline: 6 months
Team: Product, Engineering, Underwriting
Platform: Consumer Insurance Platform

End-to-end quoting experience designed for agent efficiency and underwriting accuracy.

The Challenge

Obie needed to launch its first homeowners insurance product to expand beyond landlord insurance—but doing so required building an entirely new quoting system from the ground up. The product needed to be bind-ready on day one while also establishing a scalable foundation for future carriers and product lines.

Success meant balancing three competing pressures:

  • Agent speed - Enabling quotes in minutes, not hours

  • Underwriting rigor - Meeting strict carrier requirements without introducing risk

  • Platform scalability - Building reusable patterns, not one-off solutions

The Constraints

This wasn't a blue-sky design problem. Real technical and business limitations shaped every decision:

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 core design challenge: Build a safe, reversible quoting system that agents could confidently modify without introducing underwriting risk, performance degradation, or irreversible states—while ensuring the architecture could scale to future carriers without requiring a redesign.

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 system architecture through final interaction design — in close partnership with Product, Engineering, and Underwriting.

What I owned:

System Architecture Design
Defined how and when validation, enrichment, scoring, and re-rating occurred throughout the flow. Established re-rating checkpoints that balanced agent speed with carrier API constraints.

Cross-Functional Alignment
Framed high-stakes tradeoffs clearly and drove alignment across Product, Engineering, and Underwriting on decisions that balanced near-term usability with long-term platform health.

Scalable Patterns
Built a section-based, carrier-agnostic information model that could support future carriers and product lines without requiring a redesign of core flows.

The system shipped bind-ready on day one while establishing reusable patterns that later informed broader platform work under Project Runway.

Key Decisions & Tradeoffs

Four critical decisions shaped how this system balanced agent flexibility, underwriting safety, and technical performance.

1. When and how to trigger carrier rate calls

The Challenge
Markel rates were returned via live API calls 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

My Decision
I established explicit re-rating checkpoints within the flow. Changes that materially impacted risk (property characteristics, underwriting answers, package selection) triggered re-validation and re-rating, while non-rating changes did not.

Impact
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

The Challenge
Homeowners insurance required insurance score calculation for the first time at Obie — a fundamental shift from landlord insurance, which didn't require scoring. Scores required personally identifiable information (name, DOB) and could not be safely recalculated arbitrarily.

However, our existing backend infrastructure was built around immutable client records: every quote was tied to a client email, and the system wasn't designed for mid-flow identity edits. Meanwhile, agents routinely discovered corrections to names or dates of birth during the quoting process.

The constraint: Allow agents to correct data naturally while working within a backend architecture that assumed identity data wouldn't change post-score calculation.

Options Considered

  • -Lock identity fields after scoring (lowest risk, poorest UX, breaks agent workflows)

  • -Allow edits without recalculating insurance score (moderate risk, strong UX, requires backend coordination)

  • -Allow edits and recalculate score on every change (highest risk, potential compliance issues, backend performance concerns)

  • -Rebuild client infrastructure to support versioned identity data (ideal long-term, out of scope for MVP)

My Decision
I defined a model where identity data could be edited post-scoring without triggering a score recalculation, while clearly codifying when scoring occurred. I worked with Engineering to ensure the backend could handle these edits gracefully — preserving the client-quote association while allowing fields to update without breaking the scoring contract.

Impact
This decision bridged the gap between our landlord-focused legacy architecture and homeowners requirements without requiring a full backend rewrite. Agents could correct data errors naturally, the system remained compliant with scoring constraints, and we avoided forcing workarounds or flow restarts. More importantly, it established a pattern for how we'd handle other homeowners-specific requirements within existing infrastructure constraints.

3. Supporting package switching mid-flow (HO3 ↔ HO5 ↔ HO6)

The Challenge
Agents frequently adjust coverage recommendations based on client budget or property details discovered mid-quote. Early user research revealed that agents needed to explore packages fluidly — comparing HO3, HO5, and HO6 options without penalty.

However, packages have significantly different requirements: HO5 requires at minimum 10 additional property and underwriting questions compared to HO3, plus access to additional coverage options. With only 30% of questions universal across packages, restarting the flow to compare options would force agents to re-enter substantial amounts of data.

The added complexity: This needed to work not just for Markel's three packages, but scale to future carriers — where Markel HO3 and Nationwide HO3 might have entirely different question sets and coverage options.

Options Considered

  • -Lock package selection once chosen (simplest technically, broke agent workflows)

  • -Allow package switching but force a full flow reset (ensures data integrity, unacceptable time waste)

  • -Support seamless package switching with intelligent data preservation (best experience, most architecturally complex)

My Decision
I designed a section-based question architecture that mirrored how data was structured in the backend. Each section mapped to existing data calls and "save" moments in our infrastructure, making the system naturally package-agnostic.

When agents switched packages mid-flow:

  • The system created a new quote instance for each package explored (preserving progress if they switched back)

  • Universal question answers ported automatically to the new package (30% of data carried over instantly)

  • Only new or package-specific questions surfaced (e.g., the 10+ additional HO5 requirements)

  • No data loss occurred — agents could switch back and forth freely

I worked through this architecture in close collaboration with the lead engineer from day one, starting with rough FigJam diagrams, moving to screen designs, and then prototyping the switching behavior. Underwriting had to sign off on every question set for each package — a brutal but necessary validation process that ensured the mappings were correct.

Impact
This architecture enabled agents to explore packages naturally without friction or data re-entry. A discovery session that might have taken 20+ minutes with restarts now happened seamlessly in real-time.

More critically, this established a carrier-agnostic pattern: when we later added new carriers under Project Runway, their HO3/HO5/HO6 packages plugged into the same section-based architecture without requiring flow redesigns. New carriers became a configuration problem, not a design problem.

Quoting flow demonstrating seamless package switching: agents can start with one coverage level (HO-3), explore all available options across multiple carriers, and switch to a different package (HO-5) without data loss or flow restart.

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.