Reimagining the Claims Experience at Tryg
System‑first conversation design that keeps working when AI does not
System‑first conversation design that keeps working when AI does not
I led the UX effort to transform digital claims for business customers at Tryg. The work covered design system governance, token architecture across markets and partner brands, a conversational First Notice of Loss experience, and an AI layer with explicit failure handling. The goal was simple to state and hard to execute. Reduce cognitive load for customers, increase internal maintainability, and ensure the flow remains usable even when AI is uncertain or offline.
Context and constraints
🚩 Multiple brands and markets with different legal and user needs
🚩 A shared tech base using Guidewire Jutro
🚩 Tryg’s own design system had to remain the source of truth
🚩 Complex water-damage claims with attachments and business logic
🚩 A requirement to introduce AI — without making users dependent on it
🚩 A shared tech base using Guidewire Jutro
🚩 Tryg’s own design system had to remain the source of truth
🚩 Complex water-damage claims with attachments and business logic
🚩 A requirement to introduce AI — without making users dependent on it
The main risk was fragmentation. Every partner or market tweak can become a divergence unless the system is governed well. We addressed that first.
Strategy in one sentence
Build a conversation-led claims flow on top of a governed token architecture — so that branding and behaviour can change without forking the experience, and AI can enhance the journey without ever being a single point of failure.
Token architecture that governs change
To prevent UI drift and styling chaos across brands, I aligned Jutro tokens with Tryg’s internal design system, Anchor — and introduced a layered token model:
🔹 Global tokens: core color roles, spacing, typography
🔹 Semantic tokens: intent-based naming like action, alert, success
🔹 Component tokens: tied to chips, banners, file uploads, etc.
🔹 Partner themes: visual tweaks that don’t break semantic structure
🔹 Semantic tokens: intent-based naming like action, alert, success
🔹 Component tokens: tied to chips, banners, file uploads, etc.
🔹 Partner themes: visual tweaks that don’t break semantic structure
Key decisions
🔸 Semantic layer stays stable — partner themes change values, not meaning
🔸 Layout rules stored as tokens — not spread across components
🔸 Exceptions allowed only with clear rationale (e.g., ADR notes)
🔸 Token changes documented in plain language with business impact
🔸 Semantic layer stays stable — partner themes change values, not meaning
🔸 Layout rules stored as tokens — not spread across components
🔸 Exceptions allowed only with clear rationale (e.g., ADR notes)
🔸 Token changes documented in plain language with business impact
Results
✔️ One shared flow worked across multiple brands
✔️ UI fixes applied once at token level, propagated globally
✔️ Designers and devs used the same names and references — no drift
✔️ One shared flow worked across multiple brands
✔️ UI fixes applied once at token level, propagated globally
✔️ Designers and devs used the same names and references — no drift
A conversational claims model that reveals complexity gradually
We redesigned the FNOL flow for business water-damage claims around a guided conversation — letting users describe their problem in plain language and shaping the structured flow around them.
🔹 Natural-language prompts instead of stacked forms
🔹 Chip-style responses for faster visual scanning
🔹 In-flow file uploads with clear constraints
🔹 A summary page showing chip-based responses for multi-select answers
🔹 Chip-style responses for faster visual scanning
🔹 In-flow file uploads with clear constraints
🔹 A summary page showing chip-based responses for multi-select answers
Why it works
🔸 Fewer context switches
🔸 Better for mobile and low-attention situations
🔸 Lowers pressure by letting the user focus one step at a time
🔸 Fewer context switches
🔸 Better for mobile and low-attention situations
🔸 Lowers pressure by letting the user focus one step at a time
Designing for AI — and for when AI fails
We assumed AI would sometimes be wrong or uncertain. So we made sure users always stayed in control — with fallback paths, gentle corrections, and a final review step.
Failure modes and how we handled them:
🔹 Low AI confidence → Ask clarifying question, don’t skip ahead
🔹 Wrong suggestion → Show Confirm and Change together, in-place
🔹 Unclear data extraction → Let user edit directly
🔹 AI delay or outage → Switch to manual flow automatically
🔹 Out-of-scope issue → Offer alternate route with clear explanation
🔹 Final confirmation → Show full summary in human-readable language before submit
🔹 Wrong suggestion → Show Confirm and Change together, in-place
🔹 Unclear data extraction → Let user edit directly
🔹 AI delay or outage → Switch to manual flow automatically
🔹 Out-of-scope issue → Offer alternate route with clear explanation
🔹 Final confirmation → Show full summary in human-readable language before submit
Principle:
The user never loses context. There’s no mode shift when AI struggles — only graceful fallback.
The user never loses context. There’s no mode shift when AI struggles — only graceful fallback.
Fallback conversational flow preview - Clickable Figma prototype used when the AI service is disabled or unreachable. Note: Only elements unrelated to AI logic are visible due to release constraints.
Cross-functional collaboration and testing
I initiated workshops with teams across the company and ran structured usability testing with real business customers.
Who I worked with:
🔹 Product owners and business specialists
🔹 Developers and architects
🔹 AI engineers and compliance/legal teams
🔹 Designers across Nordic markets
🔹 Product owners and business specialists
🔹 Developers and architects
🔹 AI engineers and compliance/legal teams
🔹 Designers across Nordic markets
What we tested:
🔸 Tone and clarity of prompts
🔸 Readability of chip-based summaries
🔸 Trust in AI suggestions and comfort with overrides
🔸 The usefulness of the review step
🔸 Tone and clarity of prompts
🔸 Readability of chip-based summaries
🔸 Trust in AI suggestions and comfort with overrides
🔸 The usefulness of the review step
How testing changed the flow:
✔️ Shortened prompts, removed jargon
✔️ Improved chip layout and wrapping on mobile
✔️ Added copy for fallback explanation
✔️ Made AI confidence handling more transparent
✔️ Improved chip layout and wrapping on mobile
✔️ Added copy for fallback explanation
✔️ Made AI confidence handling more transparent
Outcomes:
✔️ Deployed the first conversational FNOL flow for business customers
✔️ Established a governed token system across brands and markets
✔️ Delivered an AI-enhanced flow that remains usable even when AI fails
✔️ Created a scalable governance process using shared ADRs
✔️ Validated through real-world testing and cross-team feedback
✔️ Established a governed token system across brands and markets
✔️ Delivered an AI-enhanced flow that remains usable even when AI fails
✔️ Created a scalable governance process using shared ADRs
✔️ Validated through real-world testing and cross-team feedback
What I’d do next
🔹 Introduce a semantic event log to track system decisions and user edits
🔹 Extend token linting to CI pipelines to prevent contrast or layout violations
🔹 Add smart recovery flows for users reporting multiple incidents
🔹 Publish a conversation tone guide for other product teams
🔹 Extend token linting to CI pipelines to prevent contrast or layout violations
🔹 Add smart recovery flows for users reporting multiple incidents
🔹 Publish a conversation tone guide for other product teams
Reflection
This project taught us to design not just screens — but systems.
✔️ Tokens make UI scalable and predictable
✔️ Conversation reduces user effort and adapts to complexity
✔️ AI adds value — but only when the user can ignore it and still succeed
✔️ Conversation reduces user effort and adapts to complexity
✔️ AI adds value — but only when the user can ignore it and still succeed
The result is a claims experience that’s not just branded and user-friendly — but resilient, testable, and built to last.