Case study
Shaping a flexible service design framework for one of the UK's largest retail banks and insurance providers, covering everything from simple digital self-service claims to complex colleague-managed journeys.
Client
Leading UK insurer
My role
Project Lead
Type
Service Design
Duration
10 months
Design Leadership
Service Design
Insurance
Journey Transformation
Digital Self-Service
Colleague Experience
SUMMARY
Overview
Processing an insurance claim is often one of the most stressful moments in a customer's relationship with their insurer. Customers need clarity, reassurance, and progress at exactly the point when they may be dealing with damage, loss, disruption, uncertainty, or vulnerability.
At one of the UK's largest retail banks and insurance providers, General Insurance claims journeys were still heavily shaped by legacy processes, manual handling, and operational complexity, with relatively low digital maturity compared with other major UK financial services providers.
I led the service design workstream for a 10-month transformation initiative to redesign General Insurance claims journeys across the full spectrum of complexity: from simple claims moving toward straight-through digital processing, to complex claims requiring colleague guidance, supplier involvement, fraud checks, and manual decision-making.
The Challenge
The client needed to modernize its General Insurance claims experience. Existing journeys were outdated and manual, creating friction for customers during stressful moments and limiting the organization's ability to compete with more digitally mature insurance providers.
But claims are not simple, linear service journeys. They vary significantly depending on the event, the product, the level of complexity, the involvement of third-party suppliers, the customer's circumstances, and the degree of operational judgment required.
"The challenge wasn't just to digitize claims. It was to design a scalable service model that could flex across very different levels of complexity, applying digital and human support in the right places."
A one-size-fits-all digital journey would not work. Some claims could be handled with a high degree of digital self-service. Others needed human judgment, sensitive communication, or complex coordination between internal teams and external suppliers. The work was to design a model that flexed according to the claim, not against it.
The framework I created
The single most important contribution I made was the framework the whole workstream used to reason about complexity. I conceived it and refined it with my team, and it became the backbone of how the program decided which parts of each journey should be automated, which should be assisted, and which required deeper colleague involvement.
It did not arrive fully formed. It evolved, and that evolution is the part I'm most proud of.
Where we started. The early model split claims into four graded tiers of complexity: Simple, Complex-Simple, Simple-Complex, and Complex. It was thorough, but it was built around internal operational categories, and it was hard for teams to actually design against. The boundaries blurred, and the model described the business more than it served the customer.
Where I took it. As discovery deepened, I simplified the model down to something more intuitive and more customer-centered: two complete journeys, plus a connector between them.
Self-service journey: high automation, straight-through processing, no colleague needed to move the claim forward.
Human-guided journey: a named claims owner the customer can reach throughout, for claims needing judgment, problem-solving, supplier coordination, or sensitive handling.
Hybrid handover: a micro-journey connecting the two, so a customer can move between self-service and human guidance as many times as the claim requires.
The hybrid handover was the key insight. Rather than forcing each claim down a single fixed track, the model lets the claim flow to the right kind of support at the right moment, and back again. Self-service handles what it handles well; the moment human help is needed, the customer is handed over cleanly, then returned to self-service when appropriate. That keeps colleagues focused on the cases that genuinely need them, instead of being clogged by routine admin.
Simplifying a four-tier operational model into two human journeys and a connector is the work I'd point to as the clearest example of how I lead: holding a complex system in view, then making it concrete and usable enough for a team to design against and a business to deliver.
My role
I was Project Lead for the service design workstream. I was part of the initial discovery team that scoped the transformation opportunity and helped quantify the benefits that supported the business case, contributing to the approval that unlocked the delivery phase.
Once the program moved forward, I led the design workstream end-to-end:
Scoped and planned the service design workstreams
Led a team of five: four service designers and a user researcher
Briefed designers, reviewed journey outputs, and maintained design consistency across all journeys
Created the complexity framework that guided the team's design decisions
Reported regularly to program stakeholders and senior leadership
Kept the design work aligned with business priorities and operational constraints
Working within constraints
This was not a blank-sheet redesign. The transformation required pragmatic enhancement of existing journeys, working within a complex ecosystem of legacy systems, established supplier relationships, and operational processes.
Discovery & business case
Journey design process
For each journey, the team began by scoping the claim type with client subject-matter experts. We then mapped the current state to understand pain points, operational dependencies, customer needs, colleague actions, system interactions, and supplier involvement.
Across the workstream we designed ~20 journeys covering the full end-to-end claims lifecycle, accounting for both frontstage customer experiences and backstage operational processes:
Enquiry
→
First notification of loss
→
Triage
→
Assessment
→
Settlement (repair/replace/cash)
→
Support
→
Complaints
→
Case closure
→
Recoveries
Each journey was designed within one of the two tracks, self-service or human-guided, with hybrid handovers connecting them. My job was to keep the design activity structured and consistent across all of them, while making sure each reflected the specific complexity of the claim type.
Stakeholder alignment
One of the biggest challenges was getting the right stakeholders into the right conversations at the right time. Claims journeys touched many parts of the organization, and without the right people in the room, the team risked designing journeys that looked good in principle but failed against operational reality.
I orchestrated input across:
Customer experience
Claims experience, digital channels, vulnerable customer specialists
Claims operations
Claims handling, recoveries, supplier relations
Technology & platforms
Solution architecture, case management, document processing
Risk & fraud
Fraud, risk, compliance, claims decisioning
Data & analytics
Analytics, claims decisioning, performance measurement
Program delivery
Business delivery, business analysts, program leadership
Impact
Over 10 months, the workstream delivered ~20 end-to-end journeys structured by the framework I created.
The framework I conceived became the program's shared language for complexity, giving designers, operations, and technology a consistent way to decide what to automate, what to assist, and what to keep colleague-led.
The future-state journeys were taken forward into the client's implementation phase as part of its wider General Insurance transformation.
The work shifted the program away from simply replacing human support with digital journeys, toward designing the right balance between automation, self-service, colleague guidance, and specialist handling.
The model was built to lower claims-handling effort by moving simple and moderate claims toward straight-through processing, while concentrating colleague time on the complex and sensitive cases that need it most.
Reflection
This project marked an important shift in my own design leadership. I was moving further from hands-on production into a role focused on direction-setting, team leadership, delegation, and senior stakeholder reporting.
I learned that when a service is this complex, the design leader has to work hard to communicate why the work needs time and care. There was real pressure to deliver at speed within budget and timeframe. If I were doing this again, I'd invest earlier in making the complexity of the journeys, the dependencies involved, and the risks of moving too quickly visible to stakeholders from the start.
For complex service transformation, design quality depends not only on design craft, but on stakeholder orchestration, clear decision-making frameworks, and protecting enough space for the team to understand the service properly.
My contribution
Design leadership
Journey framework
Team leadership
Stakeholder alignment
Business case input
Senior reporting
Collaborators
Operations
Claims handlers, recoveries, supplier teams
Technology
Solution architects, Enterprise platforms
Business
Product owners, risk, fraud, compliance
Methods Used
Discovery research
Competitor benchmarking
Current-state mapping
Future-state journeys
Service blueprinting
Stakeholder workshops
Next case study
Oscar Choi
© 2026 · Irvine, California