All work
Case 02 Verisk Germany · Oct 2022 - Present

The claims platform behind 90% of the German market

Lead product designer on the end-to-end redesign of a claims system serving 90% of the German insurance market. I ran the user research with medical, legal and administrative experts, then set the end-to-end user flows and the component system that made LLM recommendations legible and governable for 90+ enterprise customers.

Representative interface: Relay, a working claims system I designed and built end to end. Actual Verisk visuals are under NDA.

Role
Lead Product Designer
Company
Verisk Germany
Duration
Oct 2022 - Present
Milestone
Messe Conference: CTO Feature
Team
PM · PO · Developers · Design

Measurable gains across the workflow

+85%Higher productivity through automation of tasks that were previously completed manually
hrs → minClaims processing time reduced from hours to minutes per case
−8 to −14%Sustainable reduction in time spent structuring audit reports for customers

All figures publicly advertised by Verisk. See verisk.com.

Beyond the numbers, the system enabled quicker and more confident decision-making during claims assessments, reducing cognitive load for experts by surfacing the right information at the right moment, rather than requiring them to hunt through unstructured documents.

A full system redesign powered by AI

The integration of LLMs and Intelligent Document Processing (IDP) presented a rare opportunity, not just to improve the existing product, but to redesign and migrate the entire system from scratch into a new use case-based automation pipeline.

This required designing end-to-end user flows grounded in deep domain knowledge: understanding how insurance claims were originally processed by legal experts, medical professionals, and claims assessors, then unifying these into a single coherent, scalable system.

Before and after the migration. On the left, the legacy surface: eight separate applications, each with its own tab strip and its own version of the same screen, forked per customer so a change had to be made many times over. On the right, one shell: a single tab bar, a content area assembled from a small shared set of modules, and one component set underneath it that every business unit draws from. The screens did not get fewer; the things they are built from did. BEFORE · EIGHT APPLICATIONS Forked per customer: one change, made many times over MIGRATE AFTER · ONE SHELL ONE COMPONENT SET, EVERY BUSINESS UNIT Primitives that adapt across contexts, instead of a variant per business

Automation where it matters most

Manual claims processing was time-intensive by nature. Tasks that took hours were bottlenecked by repetitive document review, data extraction, and structured report writing. The emergence of LLM and IDP technology created a direct opportunity to automate the most labour-intensive parts of this workflow.

Why this matters

The challenge wasn't just building automation. It was designing it to be understandable, trustworthy, and adoptable by experts who had spent years doing this work manually.

Understanding where automation opportunities existed required granular knowledge of how different expert types (legal, medical, administrative) approached claims at each stage. This domain research informed every design decision.

90% of the German insurance market. One unified system.

Working directly with over 90 insurance customers, I mapped the workflows, edge cases, and expert mental models the new system had to absorb. Claim types, user roles, and legal contexts vary too much for one-size-fits-all, so the flexibility had to live in the components and the flows.

Research focused on where manual work could be cut without eroding the expert's sense of control, the deciding factor for AI adoption in high-stakes work like medical injury claims.

Research breadth: roughly 90 percent of the German insurance market and over 90 customers feed three expert groups, each mapped end to end. Which groups they are is withheld under NDA. Four findings come out: automation candidates, AI governance rules, component flexibility, and edge cases. THE FIELD ~90% of the German insurance market 90+ customers worked with directly Not one-size-fits-all: claim types, roles and legal contexts all differ MAPPED END TO END Groups under NDA WHAT CAME OUT High-friction, high-volume automation candidates AI governance: when to surface, when not to Component flexibility across 90+ configurations Edge cases the happy path never surfaces Reduce the manual work without eroding the expert’s sense of oversight

User interviews were combined with business flow diagrams to bridge the gap between real user behaviour and underlying business logic. This dual lens (qualitative research alongside process mapping) allowed me to build an initial proof-of-concept grounded in both user needs and operational constraints.

I championed the project internally, presenting the proof-of-concept to stakeholders and driving approval to proceed, translating complex UX rationale into business value to secure buy-in across the organisation.

Surfacing AI in a way experts could trust

The core design challenge was making AI recommendations legible and actionable, not just technically functional. Insurance claims involve legal liability and medical judgment, so the system needed to present AI outputs with appropriate confidence framing, traceability, and override capability.

I led the design and development of the AI recommendation layer, working through questions of AI governance: when should the system act autonomously, when should it recommend, and when should it stay silent?

Every recommendation stayed attached to its evidence. An assessment could be opened back to the documents behind it: which document, which agent read it, and what that agent took the passage to imply. The assessor sees the chain rather than only the conclusion, so checking the system's work costs a click instead of a re-read of the file.

The AI recommendation layer as a governance ladder. Low stakes with high confidence: the system acts and logs it. Medium: it recommends, with confidence framing, a one-click override, and a source that resolves to the document it read, the agent that read it, and the inference drawn from the passage. High stakes or low confidence: it stays silent rather than guessing. Every output carries confidence, traceability and override. WHEN THE SYSTEM MAY SPEAK ACTS Low stakes, high confidence Routing, deduplication, field extraction. It happens, and it is written to the log where anyone can find it later. RECOMMENDS Expert judgment still owns it Surfaced with confidence framing, the source it drew on, and an override that takes one action, not a support ticket. STAYS SILENT High stakes, low confidence Liability and medical calls where a confident guess is worse than nothing. Silence is a designed state, not a gap. lower stakes higher stakes, thinner evidence CARRIED BY EVERY OUTPUT Confidence framing Traceable to document and agent Override in one action One generic component set, 90+ configurations
Why this matters

Components were designed to be scalable and generic, adaptable to many use cases through industry knowledge and design expertise, making the system flexible yet targeted for quicker claims processing.

As Lead Product Designer, I had to balance trade-offs across user experience, business goals, technical constraints, and delivery timelines, especially for the MVP scope.

This meant prioritizing core user flows, clarity, and speed-to-market over edge cases, advanced customization, or long-term scalability in the first release. I also worked closely with stakeholders to align product vision with engineering feasibility and business priorities while managing scope and maintaining momentum.

NDA prevents naming the specifics. Here's how I categorize the judgment calls behind this work:

Systems that scale
  • Minimized components by mapping needs across business units. Designed primitives that adapt across contexts instead of building per-business variants. Reduced library entropy at the source.
  • Pushed back when generic went too far. The ask was one shape for every customer. Customer and user interviews showed claim types and legal contexts a single shape would have broken, so I mapped where the backend needs actually diverged and let the front end flex at those points, and only those.
  • Modeled the insurance E2E to predict downstream scale. Used claim-lifecycle domain knowledge to anticipate which components would absorb new states, integrations, and business rules over the next 2 to 3 years.
  • Reconciled overlapping business asks into a multi-year-adaptable IA. Structured the layout so new lines of business or AI surfaces could land without a re-platforming pass.
AI with accountability
  • Used PM/PO roadmaps as inputs to AI integration mapping. Identified high-leverage AI points from the established business flows, not retrofitted into screens after the fact.
  • Kept every output openable back to its evidence. A recommendation carries the documents it read, which agent read them, and the inference drawn from each passage. Experts audit the reasoning path, not just the answer, and that is what made them willing to act on it.
Shipping with judgment
  • Pushed back on data-modeling choices optimized for engineering shortcuts. Argued for product-first data foundations even when the easier path was tempting. Wrong shortcuts compound over years.
  • 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.

Next time, I'd cut irrelevant functionalities sooner and focus solely on championing those that would clearly make an impact. Simplification of old systems can spark opportunity. UX heuristics apply, and good ones can win over old habits of working.

More case studies