Syclops Claims Platform
Replace a brittle spreadsheet workflow with a scalable, auditable claims platform and lay the foundation for a standalone B2B product
Overview
As Urban Jungle began handling insurance claims in-house, the existing Google Sheets workflow quickly became a bottleneck. What started as a temporary operational fix was limiting scale, accuracy, and collaboration across claims, ops, finance, and insurance teams simultaneously.
This project expanded the existing Syclops TPA claims information system into a fully fledged claims management platform, replacing the spreadsheet entirely and supporting 1,000+ concurrent claims without additional claims-handling resource.
The Problem
As claims volume grew and claim complexity increased (more intricate reserves, recoveries, and multi-party handling) the spreadsheet started breaking down in two specific ways.
Reconciliation errors became a persistent risk: With multiple people working from the same file simultaneously, payment updates, reserve changes, and recovery entries were being duplicated or miscounted. At one point, reconciliation errors were running at an average of 17% which was a significant exposure in a regulated, financially audited environment.
Ownership was equally fragile: There was no clear audit trail, no way to understand who had made a change or when, and no mechanism for a new handler picking up a claim to quickly understand its full history. As claim numbers grew, this wasn't just an operational inconvenience but a compliance risk.
Our manual claims tracking spreadsheet which we replaced with our Syclops claims platform
My Role
Lead designer with direct line management of one junior designer. I ran all user research internally with the insurance and claims teams, led cross-functional delivery with an engineering team of six, and owned stakeholder alignment across claims, insurance, product, finance, compliance, ops, and data throughout.
Early alignment with the other designer on our current claims handling workflows in order to understand user needs and platform requirements
Users
Syclops serves four distinct user groups, each with different needs from the same platform:
Claims Handlers, both internal and external third-party administrators, are the primary users, managing claims end-to-end from first notification of loss through to closure.
Finance and Compliance need clear, auditable access to payment data, reserve changes, and a full timestamped record of every action on a claim.
Operations need enough visibility to handle customer contact confidently without needing to involve the claims team directly.
Data and Reporting teams need structured, clean claims data flowing automatically into downstream pipelines for BDX, CUE, and technical modelling.
Discovery
Three formal user research sessions were run with the in-house claims team before a line of design work began.
The first session mapped their end-to-end claims handling process in the existing spreadsheet. The second focused specifically on day-to-day pain points. The third reviewed other claims handling platforms on the market, understanding what worked, what didn't, and what was worth bringing into our own system.
What the research surfaced:
Duplicated communication threads across email, phone, and documentation with no unified history
No clear payment timeline – handlers picking up an existing claim had no fast way to understand its current financial state
Compliance needed timestamps and action-level attribution easily visible and sortable and the spreadsheet currently offered neither
No flagging system for vulnerable customers, large losses, or potential fraud
Adding a payment update took 8–10 minutes in the old system due to multiple manual input points and individual finance approval steps at each stage
A design challenge: Claims handlers consistently led with solutions rather than problems during research.
One handler was adamant the platform needed fully integrated phone, email, and document communication built in from day one. Managing the difference between a user's stated solution and their underlying need (unified communication history rather than a new communication tool) was a recurring challenge throughout discovery, and shaped how we framed requirements going into design.
This Figjam was the outcome of our first and second user research sessions, with the claims workflow outlined and pain points recorded
Design Process
Design was delivered across three phases, with each covering all core pages before moving forward.
Managing feedback across seven teams required structure. I set explicit deadlines at each review stage and ran a mix of in-person sessions for resolving genuine disagreements and async Figma reviews for consolidating written input which kept the process moving without losing the detail that a compliance-critical platform demands.
Phase 1: Information Architecture
Mapping the full claims lifecycle from FNOL to closure, and establishing the relational structure between claims, actions, reserves, payments, and communications.
Phase 3: High-Fidelity Design
Refined with product and engineering before light-touch prototype testing with the claims team to validate functional clarity. Findings from that testing were integrated into final designs before handoff.
The visual system was deliberately UJ-agnostic. Clarity and usability were key rather than brand expression, with a system designed from the start to work for internal users and external TPA partners equally.
Phase 2: Low-Fidelity Wireframes
Reviewed by a wider group than typical: claims, insurance, product, engineering, finance, data, and compliance all provided input. Feedback was integrated before a full second round of review with the same teams.
Design Decisions
The Actions Tracker — One Timeline, Fully Filterable
The central design question for claim detail pages was how to display different action types (communications, payments, reserve changes, compliance notes) without fragmenting the interface into separate sections that a handler would have to navigate between.
We chose a single unified timeline called the Actions Tracker, filterable by action type. This gives handlers the broadest possible overview of a claim's lifecycle by default, with the ability to filter down to exactly what they need. A compliance team member can pull a full timestamped audit view. A finance team member can isolate payment history. A handler picking up an unfamiliar claim can scan the full thread before touching anything.
Reserve Management — Separating Financial Data from Claim Actions
Reserve management was the most technically complex interface on the platform. Five distinct payment types needed to be clearly visible and independently trackable:
Total Incurred
Paid
Current Reserve
Recovered Amount
Recovery Reserve.
Logging these alongside other actions within the Actions Tracker would have created more complexity and increased the risk of payment errors – the exact problem we were trying to solve. Instead, we built a separate Reserve Tracker to keep all financial data cleanly delineated from operational claim actions. The interface shows a full history of reserve movements, makes the current financial state of a claim immediately legible, and allows handlers to correct a payment update without disrupting the broader claim record.
The goal throughout was simple: reduce payment mistakes, make it easy to hand a claim to a different handler, and give finance a clear audit trail without requiring any manual reconciliation step.
A Design Miss
The most significant miss on the project was SLA tracking for the Operations team.
We integrated fully with the data platform to track claims data, generate bordereaux, and feed claims information into technical modelling. What we didn't build were the specific metrics needed to track internal FCA-reportable SLAs (response-to-customer time and claim lifecycle timing) that the Operations team was required to report on.
This was a gap in my stakeholder alignment sessions. Ops were included in design reviews but the reporting requirement wasn't surfaced clearly until the first month post-launch, when it became apparent the metrics weren't being captured. It had to be picked up quickly as an unplanned piece of post-launch work.
The fix was straightforward once identified, but it was a useful lesson in the difference between a team being present in a review process and their full set of needs being properly represented within it.
Key Data
1000+
claims handled in year one
<5%
reconciliation error rate, down from 17%
0
additional resource needed
9.2
handler NPS, up from 5.7
1.75hr
time saved per claim per week
2
underwriter audits passed
The B2B Opportunity
Syclops was designed from day one to work beyond Urban Jungle's internal team and that development is now actively underway. The neutral design system, relational data model, and existing TPA workflows provide the foundation, with current work focused on building out the third-party data integrations needed to make the platform fit for external sale. Urban Jungle's existing claims partners are the most likely first customers.
Reflection
Designing Syclops was a different kind of design challenge. It was not harder than other projects, but it had a direct impact on colleagues sitting across from in the office. Whatever I designed, they would use the next morning.
That proximity made it easier to understand pain points quickly and iterate with real feedback. It also raised the stakes on every decision in a way that consumer-facing product design doesn't always – there's no ambiguity about whether the product is landing when your users can walk over and tell you directly.
The cross-team collaboration required on this project was also broader than anything I'd managed before. Aligning seven teams across two phases of review, each with genuinely different needs from the same platform, pushed me to be much more deliberate about structuring feedback processes rather than relying on informal alignment. The SLA tracking miss was a direct result of a gap in that process and it's shaped how I approach stakeholder mapping on every project since.
Key Data
1000+
claims handled in year one
<5%
reconciliation error rate, down from 17%
0
additional resource needed
9.2
handler NPS, up from 5.7
1.75hr
time saved per claim per week
2
underwriter audits passed
Stakeholder Management
With seven teams involved in sign-off across two phases of review, managing feedback cycles clearly was as important as the design work itself.
I set explicit deadlines for feedback at each stage and ran a mix of in-person sessions and Figma-based async reviews, using in-person time to work through genuine disagreements and async for consolidating written input.
One example… Compliance initially wanted more detailed payment information surfaced within the Actions timeline, effectively creating a second audit trail within the platform.
After understanding that their underlying concern was being able to extract precise audit data quickly, we kept the Actions timeline clean and simple but added granular filtering and export options to the Reserve Tracker. This giving compliance exactly the data subset they needed, without adding complexity to the interface every other user would see daily.