A motor insurance MVP, full scope in one month
Led design for Motor Insurance at Verisk Germany, prototyping rapidly in AI, covering MVP requirements, and launching the first version in under a month for continuous iteration.
Representative interface: Gauge, a working motor-claims assessment surface I designed and built end to end. Actual Verisk visuals are under NDA.
- Role
- Lead Designer, Motor Insurance
- Company
- Verisk Germany
- Duration
- Mar 2026 - Present
- Milestone
- First version in under a month
- Team
- PM · PO · Developers · Design
Problem space
Motor insurance processes are dense with regulation, edge cases, and domain-specific logic. The mandate was clear: prototype rapidly using AI tooling, define and cover all MVP requirements, and ship a working first version within a single month, ready for continuous iteration.
As Lead Designer, I worked under tight timelines alongside domain experts and engineers to translate intricate insurance workflows into clear, guided experiences that inexperienced users could operate confidently from day one.
Verisk Germany serves 90% of the German insurance market. Broader context at verisk.com.
Process
Speed was the constraint. I used AI prototyping tools to accelerate ideation, moving from rough concepts to testable screens in hours rather than days. This allowed rapid alignment with stakeholders while MVP scope was being defined in parallel.
The approach: immerse quickly in the domain (underwriting rules, policy structures, adjuster mental models), prototype in AI, validate, and ship. New technologies were applied deliberately, reducing cognitive load where it mattered most, not as novelty. The first version launched within a month and entered active iteration immediately.
The delivery ran on an : product intent to structured design prompts, prompts to working prototypes, kept safe by design review. More on this soon.
Design tradeoffs
Shipping a full MVP in under a month meant scope discipline was the default, not the exception. Every feature had to prove it belonged. The question wasn't "why cut this?" but "why include it at all?" Speed only worked because the foundations were tight.
- Token discipline over token sprawl. Only added new tokens when the user group genuinely needed a different value, not when "we could make it look slightly different." Discipline at the foundation kept the rest of the system fast.
- E2E consistency as a non-negotiable. Every new screen used the same primitives, the same patterns, the same logic. New work felt like extensions, not exceptions.
- Leveraged existing Verisk foundations. Reused tokens, components, and IA from the broader system; velocity came from leverage, not from shortcuts.
- Reviewed every AI-generated screen for hallucinations. AI tools could fabricate confident-looking outputs that violated underwriting rules or policy logic. Domain knowledge was the validation layer; nothing shipped unreviewed.
- Used AI to accelerate ideation, not to replace judgment. Every output passed a "does this match the actual rules?" check before any user saw it.
- Compressed design-validate-adjust cycles using AI prototyping, hours instead of days from rough concept to testable screen.
- Treated MVP scope as a sharp constraint. Features had to earn their seat; the bias was to defer, not include.
- Knew what would ship vs. balloon. HTML/CSS/JS and front-end library competency informed component decisions, including page-load and render-performance implications. The "should we build this elaborately?" question came up early, not at code review.
- Probed before designing. Asked: what's the goal of v1? What can we leverage from what already exists? What's the simplest, most intuitive path for this user group? We don't reinvent the wheel. We see what users actually need to do, then make the way.
Retrospective
Next time, I'd build AI-hallucination review into the very first prototype pass, not as a verification step at the end. Catching fabricated logic at draft stage saved us re-work; we caught some too late and paid the cost. The lesson: review AS you generate, not after.
The "ship fast" bias was the right default for launch, but a few cut features hit production immediately as users surfaced needs. Next time I'd weight critical edge cases harder, even in a velocity-first MVP. Speed and rigor aren't opposed when the foundations are tight.