01 Enterprise Insurance · Design Strategy & Leadership

ClaimsManagement System

The Problem

1500+ insurance professionals were managing claims in a system built around data entry, not operational decision-making.

Claims work was fragmented across manual queues, personal inboxes, spreadsheets, and IT-dependent contact updates.

The measurable cost: 3-5 hours lost every day, per person.

3
Stakeholder Groups
4
User Roles
3 Days → 30 Sec
Contact Update Time
14→8
Steps Reduced
85%+
Task Success Rate
Scroll
01Overview› 02Strategy› 03Discover› 04Insights› 05Ideation› 06Personas› 07Scenarios› 08Synthesis› 09IA› 10Old vs New› 11Prototype› 12Validate› 13Decisions› 14Impact
01 — Product Overview

What the system does,
who it serves, why it mattered

The Claims Management System is the operational backbone for an insurance brokerage — handling the full lifecycle of P&C, Management Liability, and Workers' Compensation claims for 1500+ internal employees across 4 distinct roles.

📉
My Role
Design Strategist & Team Lead — end-to-end ownership from executive brief through research, IA, prototyping and usability validation. Led cross-functional alignment across design, engineering, and operations stakeholders.
⏱
Scope & Duration
6-month intensive. Full redesign across 4 modules plus 4 net-new capabilities: Outlook integration, task automation, real-time sync, self-service contacts.
🛠
Tools & Methods
Figma · Miro · UserTesting.com · Heuristic Evaluation · User Interviews · Card Sorting · SCAMPER · Remote Usability Testing
6 usersRemote validation across Consultant, Co-ordinator, and Coverage Manager roles.
7 tasksProtocol measured real task performance, not only stated preference.
Round 1Exposed document-classification and status-escalation hierarchy gaps.
85%+Round 2 reached target success after focused iteration.
Design Strategy Brief

Before any research began, this brief aligned the team on executive intent, constraints, goals, and critical success factors — preventing scope creep and grounding every design decision in a defined business objective.

Design Strategy Brief — Executive Intent
Design Strategy Brief — Executive Intent
Artifact takeawayPurpose: align executive intent, constraints, and success factors before discovery. Finding: the redesign had to unify claims work across teams under a 6-month constraint. Decision: use the brief as the scope filter for research, IA, and engineering feasibility reviews.
📉 Executive Intent: Redefine the existing system and create a completely new experience with net-new features, workflows, and systems. Critical Success Factor: Provide a unified, seamless claims management experience across different teams.
Business Context — Why This Project Existed

This wasn’t a UX brief.
It was a business emergency in slow motion.

Before a single wireframe was drawn, it was critical to understand what was actually at stake for the organisation — because the problem was not just usability. It was operational risk compounding every single day.

The legacy CMS was a severe bottleneck. The UX was heavily fragmented, forcing users into "swivel-chair integration"—manually copying data between Outlook, spreadsheets, and the core system. The project mandate was a complete UX redesign to unify the workflow, integrate external communications, and recover operational efficiency.

💹
Operational Cost Haemorrhage
1,500+ professionals losing 3–5 hours daily to manual workarounds, application switching, and IT-dependent tasks. At mid-market salary benchmarks, this translated to an estimated £18–30M in lost productivity per year — not theoretical waste, but recoverable hours blocked by poor design.
⚠
Client Retention Risk
Delayed claims processing and communication breakdowns were creating visible service gaps at the client-facing level. In a market where policy renewals depend on service speed, every delayed adjuster response was a retention risk the organisation could not quantify — but felt acutely.
📋
Compliance Pressure
Without centralised audit trails, document tagging, and role-based access controls, the organisation was operating in a grey zone on data governance. A single regulatory audit could have exposed systemic gaps. Compliance was not optional — it was a non-negotiable design constraint.
The Business Trigger A new engineering leadership team had been brought in with a mandate to modernise internal tooling. They identified the Claims Management System as the highest-impact target — not because it was broken in an obvious way, but because its hidden friction was costing the business at scale. The project was greenlit at executive level with a 6-month hard deadline. This was a strategic investment decision made at the top, with measurable return expected.
Constraints — The Design Playing Field

What we could not change,
and how that shaped what we built

Great design does not ignore constraints — it uses them. Every limitation on this project shaped a decision that would otherwise have been left to preference or politics.

⏱
6-Month Hard Deadline
Non-negotiable. Set at executive level before design began. This eliminated the possibility of extended discovery or iterative prototyping cycles — which is exactly why the Design Strategy Brief front-loaded alignment work. Constraint response: compress ambiguity at the start, not the end.
🔒
Existing Tech Stack
The system had to integrate with EPIC, Outlook, and existing IT infrastructure. No greenfield architecture. Every proposed feature had to be confirmed feasible within those constraints before investment. Constraint response: lo-fi feasibility reviews before hi-fi, every time.
📏
Regulatory Compliance
P&C, Management Liability, and Workers’ Comp each carry different data handling requirements. Audit trails, role-based access, and document classification were legal obligations. Constraint response: compliance baked into IA architecture from day one.
Constraint as Creative Fuel The 6-month timeline forced a discipline that many projects lack: every feature had to prove its value before it earned design time. The SCAMPER ideation framework was chosen specifically because it generates improvement hypotheses from existing structures — not blank-slate thinking. In a constrained environment, structured ideation outperforms freeform creativity every time.
02 — Design Strategy & Stakeholder Alignment

Navigating compliance, engineering
and business — simultaneously

Delivering four enterprise-grade integrations in 6 months required constant cross-functional alignment. The design strategy had to speak three stakeholder languages at once — user needs, technical feasibility, and compliance boundaries.

Stakeholder Landscape

Three groups, each with different priorities and success criteria. No design decision was made without all three considered.

📉 Compliance Team
Data governance · Audit trails · Access controls
👤 Business Leaders
Efficiency gains · Client experience · ROI
📊 Claims Operations
Daily workflows · Adoption · Training time
🎯
DESIGN
LEAD
⚙️ Engineering Leaders
EPIC integration · Outlook API · Feasibility
🏢 IT Infrastructure
Contact database · Real-time sync · Security
👥 End Users (4 Roles)
Workflow simplicity · Speed · Reliability
UCD Framework — 5 Phases with Stakeholder Touchpoints
Phase 01
Discover
Heuristic EvaluationUser InterviewsRemote ObservationTask Analysis
Stakeholder moment: Heuristic violation report presented to business leaders — 4 critical severity issues used to justify full redesign scope and secure resource allocation.
Phase 02
Define
User ProfilingPersonasScenariosSWOTCompetitive Analysis
Stakeholder moment: Persona walk-throughs with compliance and engineering — role-based access controls baked into IA from day one, not retrofitted.
Phase 03
Ideate
SCAMPERCard SortingTask PrioritisationLo-Fi Wireframes
Stakeholder moment: Lo-fi before/after reviews with engineering leaders — Outlook integration feasibility confirmed before hi-fi investment.
Phase 04
Design
IAHi-Fi PrototypeInteraction Design
Stakeholder moment: Full hi-fi prototype review with business leaders — became the living contract between design, engineering, and operations throughout development.
Phase 05
Validate
Remote Usability TestingLevel-of-Success ScoringKPI MeasurementIteration
Stakeholder moment: Test results shared with all groups — prioritised Round 2 iteration. Engineering received final developer spec with interaction annotations.
Managing Competing Priorities

Three groups. Three agendas.
One design that had to satisfy all of them.

Stakeholder conflict was structural. Business leaders wanted speed. Engineering wanted feasibility. Compliance wanted control. Design leadership held these tensions in productive friction.

Where Conflict Emerged — and How It Was Resolved
Conflict 01
Outlook Integration
Engineering vs. Business
The tension: Business leaders wanted native Outlook integration for seamless adjuster communication. Engineering flagged API complexity and timeline risk.

Resolution: Lo-fi wireframes were built specifically to test the integration concept before any development investment. Feasibility was confirmed at the wireframe stage. Engineering got a clear spec; business got the feature. Neither side had to trust the other blindly.
Conflict 02
Role-Based Access Controls
Compliance vs. Operations
The tension: Compliance required strict role-based access. Claims operations wanted broad visibility for flexibility. Making access too restrictive would slow daily workflows. Making it too loose would fail governance requirements.

Resolution: The User Profile Matrix (4 roles x 6 characteristics) was built before any IA decisions. It made role-appropriate access a structural design principle, not a compliance bolt-on. Both groups saw their requirements reflected in the architecture before development started.
Conflict 03
Scope vs. Timeline
Business Leaders vs. Engineering
The tension: 6-month deadline. 4 net-new capabilities. Business wanted everything. Engineering said something had to give.

Resolution: The Design Strategy Brief — produced at project start — explicitly documented critical success factors, constraints, and out-of-scope items. It prevented scope creep and gave engineering the authority to push back when needed. Decisions stopped being design vs. business arguments.
03 — Discover: Understanding Users

Who uses the system,
what they do, and how they do it

Discovery started by mapping the users before interviewing them — establishing a research foundation that made every subsequent interview question purposeful, not exploratory.

User Profile Matrix — 4 Roles × 6 Characteristics
Strategic Insight Consultant and Coverage Manager share Expert computer experience and Post Graduate education — yet have fundamentally different primary expectations. This single artefact proved a one-size-fits-all interface would fail both and made role-aware design a non-negotiable requirement from day one.
User Profile Matrix — 4 Roles × 6 Characteristics
User Profile Matrix — 4 Roles × 6 Characteristics
Artifact takeawayPurpose: compare role capability, context, and expectations before designing flows. Finding: Coordinators needed speed and visibility while Coverage Managers needed deeper review control. Decision: role-aware dashboards, access rules, and information density.
🔍 4 roles mapped across language, education, domain expertise, computer experience, age/gender, and expectations. Co-ordinator (Proficient) needs speed and simplicity. Coverage Manager (Expert) needs complex review capability. Divergence confirmed role-aware architecture.
Task Profile — Role × Task Ownership

Tasks mapped against roles before prioritisation to identify shared vs. exclusive workflows. Only Coverage Manager can Review Claims. Service Team has read-only access — simplifying their interface requirements significantly.

Task Profile — Task Prioritization Matrix
Task Profile — Task Prioritization Matrix
Artifact takeawayPurpose: map task ownership by role. Finding: shared workflows and exclusive responsibilities required different entry points. Decision: keep high-frequency role tasks primary and move low-frequency tasks into secondary panels.
📊 Key finding: Shared Email Inbox is Co-ordinator exclusive — a unique integration need not in the original requirements. Task Management belongs to Consultant + Coverage Manager only — drove the role-aware task panel design.
Task Prioritization — Frequency × Importance

Tasks plotted on Frequency vs. Importance axes. Top-right quadrant tasks became first-level navigation items. Bottom-left tasks moved to secondary menus — directly reducing cognitive load on the primary dashboard.

Task Prioritization Matrix — Frequency × Importance (Miro)
Task Prioritization Matrix — Frequency × Importance (Miro)
Artifact takeawayPurpose: decide what deserved first-level navigation. Finding: claim creation, overview, documents, contacts, and dashboard tasks were high-frequency/high-importance. Decision: prioritize these flows in the dashboard and claim workspace.
⚡ Priority 1 (High+High): Claim Creation, Claim Overview, Add Document, Add Contact, User Dashboard → all given first-level navigation access. Deprioritised: Workflow Management, Task Management → moved to secondary panel.
User Interview Protocol & Data Gathering

Structured script designed to surface real pain points without leading participants. Sessions run inside the Figma prototype to ground responses in the actual interface. Interview data captured per participant — questions mapped directly to answers for traceability.

User Interview Script — Structured Protocol
User Interview Script — Structured Protocol
Artifact takeawayPurpose: make interviews comparable and grounded in real claims work. Finding: questions needed to connect pain points to actual interface moments. Decision: use the same protocol to support traceability from research quote to feature decision.
🎙 Structure: Opening (ice-breakers) → warm-up (role + daily responsibilities) → main questions: current system experience, missing features, pain points, emerging technology awareness.
User Interview Data Gathering — Jack Ray Session (July 17 2023)
User Interview Data Gathering — Jack Ray Session (July 17 2023)
Artifact takeawayPurpose: capture verbatim workflow pain and missing capabilities. Finding: users struggled with search, status tracking, insurer contacts, and email context. Decision: smart search, inline status, contact directory, and Outlook integration moved into scope.
📉 Q: Current experience? A: Many things fallen in different places, hard to find proper process. Q: Critical missing features? A: Ability to track claim file, see insurer contacts, email integration, client visibility. Q: Pain points? A: Ineffective search, manual effort managing contacts, lack of automation capabilities.
Pain Point Synthesis — 7 Clusters

Interview data synthesised into 7 primary clusters. Each cluster became a named design requirement — ensuring no feature was added without a direct research origin.

Pain Points — Struggles and Confusion in Existing Application
Pain Points — Struggles and Confusion in Existing Application
Artifact takeawayPurpose: synthesize raw interview notes into design requirements. Finding: seven pain clusters repeatedly appeared across roles. Decision: convert each cluster into a named requirement before ideation.
⚡ 7 clusters surfaced: Complexity · Lack of User-Friendly Interface · Limited Personalization · Slow Processing · Collaboration Gaps · Integration Challenges · Missing Automation Capabilities. Each maps to at least one specific design decision in the final product.
Phase Summary:
04 — Research Insights: Heuristic Evaluation

Expert review of the existing system —
4 critical violations found

Parallel to user interviews, the existing system was evaluated against Nielsen's 10 usability heuristics. Four critical violations were identified. These became the non-negotiable design requirements and the evidence base used to justify the full redesign scope to stakeholders.

Severity 4 — Catastrophic
Visibility of System Status
No real-time status indicators. Users had to open every claim record to see its state. 60–70% of daily navigation time spent on status checks that should be instant.
Design Response6-state inline colour-coded badges on Claims Listing. Status visible at a glance — zero record opens required.
Severity 4 — Catastrophic
Recognition Rather Than Recall
Users required to remember claim IDs and policyholder codes across sessions. No search history, no recent items, no smart suggestions — pure memory load.
Design ResponseGlobal search with smart suggestions, "My Claims" bookmarking, persistent Today's Tasks panel on dashboard.
Severity 3 — Major
Consistency and Standards
Saving a document worked 3 different ways across Claims, Contacts, and Documents. Identical actions, different patterns — users had to relearn the same task in every module.
Design ResponseShared component system — standardised save/edit/delete/add patterns applied consistently across all modules.
Severity 3 — Major
User Control and Freedom
No undo capability. Users avoided features entirely out of fear of unrecoverable mistakes. Accidental archiving had no recovery path — fear of errors was itself a productivity blocker.
Design ResponseSoft-delete with recovery window, confirmation dialogs for destructive actions, version history on claim notes.
Research Convergence Point Both heuristic evaluation and user interviews independently surfaced the same root issue: the system was offloading cognitive work onto users that the system itself should be handling. This convergence gave strong confidence in the design direction — and made the stakeholder case unmistakably clear.
Phase Summary:
05 — Ideation: SCAMPER Method

Generating solutions from insights —
structured creative thinking

With research insights consolidated, SCAMPER was applied to challenge every assumption about the existing system. Each lens used real findings as the prompt — not generic brainstorming. Every idea generated was then scored against the task prioritisation matrix before being carried forward.

🔄
S — Substitute
Replace what isn't working
What if we substituted the flat claims table with a role-aware workspace? What if the IT-managed Excel contacts were replaced with a live self-service directory?
→ Role-based dashboards + Dynamic Contact Directory
🔗
C — Combine
Merge separate systems
What if we combined claim file, email, and documents into one workspace — eliminating 4 application switches per claim?
→ Integrated Outlook inside Claim File + Unified Document Hub
🔧
A — Adapt
Borrow from other contexts
What if we adapted the email inbox-triage model for claims prioritisation? What if the "Today's Tasks" pattern from Asana was applied to a consultant's morning workflow?
→ Today's Tasks Panel + Priority triage on Dashboard
✂️
M — Modify / Magnify
Amplify what matters most
What if we magnified claim status visibility so it's impossible to miss? What if priority clients got a dedicated amplified experience instead of a flat list entry?
→ 6-State Inline Status Badges + Client Prioritisation
🎯
P — Put to Other Uses
Repurpose existing data
EPIC had rich claims data never surfaced in the UI. What if we repurposed it into a live Snapshot widget — no new data collection needed?
→ W360 Dashboard Snapshot powered by existing EPIC data
🗑️
E — Eliminate
Remove friction at the root
Eliminate opening every claim to check status. Eliminate the IT ticket for contact updates. Eliminate the 14-step path through a standard claims task.
→ Inline status + Self-service contacts + 14 steps → 8
🔄
R — Rearrange / Reverse
Flip the existing logic entirely
What if instead of showing ALL claims, the system showed only the user's relevant work first? What if navigation reversed from module-first to task-first? What if claims surfaced by urgency, not entry order?
→ Role-aware landing: "My Active Claims" first + Task-first navigation (card sorting confirmed this model) + Claims ordered by urgency not entry order
06 — Define: Personas

Putting faces to the research —
validated personas, research-tested

Personas were built from interview findings.

Personas were used to clarify workflow differences, not to decorate the process. Interviews confirmed two different operating modes: high-judgment review work for Consultant/Coverage Manager users, and high-volume coordination work for Co-ordinators.

Persona 1 — Jack Ray, Claim Consultant / Coverage Manager
Research Pivot Initial hypothesis: Jack is primarily a reviewer of complex claims. Post-interview reality: Jack operates as a Consultant/Coverage Manager hybrid — he also needs cross-LOB search, holistic client view, custom policy management within claims, and integrated insurer contacts. This pivot reshaped the dashboard IA from a review-first layout to a full creation-and-review workspace.
Jack Ray — Validated Persona
Jack Ray — Validated Persona
Artifact takeawayPurpose: represent high-judgment consultant and coverage-review work. Finding: Jack needed fast access to complex claim context, policies, documents, and client communication. Decision: unified claim file with tabbed context and richer review surfaces.
Jack Ray represents the Consultant / Coverage Manager mental model: complex review, policyholder communication, document classification, and fast access to full claim context. His needs informed the unified Claim File, richer document states, and review-oriented workspace patterns.
Persona 2 — Sammie Roslyn, Claim Co-ordinator
Unique Research Finding Sammie's Co-ordinator-exclusive need for a Shared Email Inbox was first surfaced in the task profiling phase — not mentioned by her persona hypothesis. This drove an entirely new module (Shared Email Inbox) that was not in the original product requirements.
Sammie Roslyn — Validated Persona
Sammie Roslyn — Validated Persona
Artifact takeawayPurpose: represent high-volume coordination and creation work. Finding: Sammie needed speed, visibility, and reduced switching more than deep configuration. Decision: simplified creation flow, status visibility, and contact-management shortcuts.
Sammie Roslyn represents the Co-ordinator mental model: high-volume creation, status monitoring, contact updates, and rapid handoffs. Her needs informed simplified claim creation, stronger status visibility, and contact-management shortcuts.
Phase Summary:
07 — Define: User Scenarios

Where the existing system failed —
real failure scenarios, real consequences

User scenarios translate research into human stories. These two scenarios were used directly in stakeholder presentations to make the cost of the existing system visceral — not abstract — and to secure buy-in for the full redesign scope.

Scenario 01 — Jack Ray · Claim Consultant
Preparing for a Policyholder Update Meeting
Jack needs to review the current status of a specific claim before a policyholder update meeting. The system's convoluted navigation makes it impossible to locate the claim in time. Despite multiple attempts across different menus, he fails to find the information he needs. Meeting preparation fails.
Failure ModeNavigation complexity blocking time-critical information retrieval — happening daily across the consultant team.
Scenario 02 — Sammie Roslyn · Claim Co-ordinator
Creating an FNOL Claim File
Sammie creates an FNOL claim file after completing all required fields. She then discovers there is no way to see the processing status of the claim she just created. To update the policyholder, she must contact the consultant directly — creating a 3-person communication chain for information that should be immediately self-serve.
Failure ModeZero post-creation status visibility created a 3-person coordination chain for self-serve information.
User Scenarios — Research Artefact
User Scenarios — Research Artefact
Artifact takeawayPurpose: translate findings into stakeholder-readable failure stories. Finding: navigation complexity and missing status visibility caused avoidable coordination chains. Decision: use scenarios to justify dashboard, claim tracking, and post-creation status states.
🎭 Both scenarios presented to all stakeholder groups (compliance, engineering, business leaders) as the human cost evidence — this is what made the business case for the redesign scope unmistakable.
08 — Research Synthesis: Competitive & SWOT

What the market confirmed —
and what it told us to build first

Competitive analysis and SWOT were conducted before ideation, not after. The goal: confirm which capabilities were genuine differentiators worth investing in prominently, and which were table stakes already commoditised by competitors.

Competitive Analysis — 3 Competitors

Paradigm, ABD, and Vita evaluated across core feature sets. Key finding: Workflow Management and Insurer Management exist in no competitor — confirmed as highest-value differentiators to build prominently.

Competitive Feature Matrix — Paradigm · ABD · Vita
Competitive Feature Matrix — Paradigm · ABD · Vita
Artifact takeawayPurpose: separate differentiators from table stakes. Finding: workflow management and insurer management were market gaps. Decision: position these as strategic capabilities, not secondary utilities.
🏆 Unique to redesigned platform: Workflow Management, Insurer Management. Shared with Paradigm only: Integrated Solution, Client Management. Neither ABD nor Vita offer workflow or insurer management — significant competitive gap confirmed.
SWOT Analysis

SWOT confirmed both the strategic opportunity and real constraints. The EPIC integration and existing client/insurer data were irreplaceable strengths — to be leveraged, not replaced.

SWOT — Existing System Landscape
SWOT — Existing System Landscape
Artifact takeawayPurpose: connect internal constraints to external opportunity. Finding: legacy data and EPIC integration were strengths, but governance and workflow complexity were weaknesses. Decision: design within the current architecture while removing operational bottlenecks.
⚔️ Strengths: Integrated EPIC System, Legacy Claims Data, Client & Insurer Data. Weaknesses: Complex flows, LOB variety, lack of operational governance. Opportunities: Streamline contacts & workflows, Outlook integration. Threats: Technical constraints, workflow rule complexity.
Research → Design Brief: The 4 Non-Negotiable Capabilities All research streams converged on four capabilities that had to be built: (1) Role-aware dashboards — no two roles share the same morning workflow. (2) Outlook integration — 4 app-switches per claim is unsustainable. (3) Self-service contact directory — 3-day IT wait to update a phone number is operationally broken. (4) Automated task creation and allocation — manual handoffs are the root cause of most coordination failures.
09 — Information Architecture

Structure before screens —
IA shaped by card sorting results

The IA was defined before any hi-fi work and reviewed with engineering leaders to confirm every integration connection point. Card sorting with users directly shaped the navigation depth and groupings — maximum 3 levels deep across all flows. Role-aware entry points were built into the IA from the first version.

Role EntryUsers start from the work relevant to their role, not from a generic module list.
Task FirstHigh-frequency claims actions sit close to the dashboard and claim workspace.
Claim FileFacts, policies, notes, documents, contacts, to-dos, and emails converge in one place.
Secondary FlowsAdmin, reports, and governance paths remain available without crowding daily workflows.
Claims Portal — Full Information Architecture
How to read this Information Architecture:
  • Role-based entry points: Navigation adapts to user permissions.
  • Task-first navigation: Prioritizes active work over static lists.
  • Claim file as central workspace: Everything connects back to the core claim entity.
  • Admin/reports as secondary flows: Kept out of the primary operational view.
↗ Open full interactive IA view in new tab
Open full IA view →
Artifact takeawayPurpose: make the product structure inspectable before screen design. Finding: users navigated by task context and role, not by system module. Decision: build role-based entry points, a central claim file, and secondary admin/reporting paths.
🗺️ Role-aware IA: Navigation · P&C Flow · ML Flow · WC Flow. EPIC integration and Outlook integration nodes mapped explicitly — engineering used this to scope API work. Claim File tab structure (Facts · Policies · Notes & Activities · Documents · Contacts · To-Dos · Emails) redesigned to match user mental models, not system architecture.
Interactive Navigation Summary

Hover any node to explore the structure. Card sorting confirmed users group by task context, not system module — reflected in every level of this hierarchy.

Claims Portal Homepage
Dashboard
Calendar
Notes
Workspace Inbox
Documents
Client Directory
Reports
Role-based Snapshot
P&C Claims
ML Claims
WC Claims
New Claim
EPIC Integration 🔗
Outlook Integration 🔗
Facts
Policies
Notes & Activities
Documents
Contacts
To-Dos
Emails (Outlook)
Phase Summary:
10 — Design: Old vs New

The transformation — before and after
every major module

Lo-fi before/after comparisons were reviewed with stakeholders before any hi-fi investment — these were the alignment tool that made the redesign scope concrete and prevented design debt during development.

Claims Dashboard
Claim Internal Screen
Document Management
Insurer Contacts
⚠️ Existing System — Flat Claims Intake Dashboard
Old Claims Dashboard
Artifact takeawayPurpose: document the baseline dashboard experience. Finding: flat data tables forced users to open records just to understand status. Decision: replace the table-first model with role-aware workspaces and inline status badges.
✓ Redesigned — Role-Aware Workspace
New Claims Dashboard
Artifact takeawayPurpose: show the redesigned entry point. Finding: users needed their relevant work surfaced immediately. Decision: prioritize Today's Tasks, smart filters, and role-based claim lists.
📊 Before: Dense data-entry table, no status indicators, no task panel, no role context — users must open every record to check state. 14 steps to find a closed claim. After: Role-aware workspace with Today's Tasks panel (16 tasks surfaced automatically), 6-state inline status badges, smart filters by FNOL/Client/Status/LOB. Standard task path: 8 steps.
⚠️ Existing — Claim Internal Screen
Old Claim Internal Screen
Artifact takeawayPurpose: expose why the internal claim view slowed work. Finding: claim context was split across long sections and disconnected flows. Decision: consolidate context into a unified claim file.
✓ Redesigned — Unified Claim File
New Claim Internal Screen
Artifact takeawayPurpose: show the unified workspace model. Finding: users could work faster when facts, policies, notes, documents, contacts, and emails stayed together. Decision: tabbed claim file became the core product pattern.
📉 Before: Long-form data entry across 14+ left-nav sections, no status progression visible, policies and contacts separate flows. After: Tabbed Claim File (Facts · Policies · Notes & Activity · Documents · Contacts · Emails) with inline status bar showing Assigned → In Review → Notice → ACK progression. All claim context in one place.
⚠️ Existing — Document Management
Old Document Screen
Artifact takeawayPurpose: document the baseline document-management problem. Finding: files lacked meaningful classification at the point of retrieval. Decision: add document tags, filters, saved-by metadata, and higher-contrast labels.
✓ Redesigned — Unified Document Hub
New Document Screen
Artifact takeawayPurpose: show the redesigned document hub. Finding: users needed to distinguish adjuster and client communication at a glance. Decision: elevate tags from metadata into primary labels.
📄 Before: Flat file list with no tagging, no search, no categorisation — all documents equal priority regardless of type. After: Live Documents section + tagged Claim Documents with Search/SavedBy/Tag filters. Each document shows file type, saved date, and saved-by user. Adjuster Comm vs Client Comm tags make priority visible at a glance.
⚠️ Existing — Excel Spreadsheet
Old Contact Management
Artifact takeawayPurpose: show the spreadsheet/IT dependency baseline. Finding: contact updates were slow, stale, and outside user control. Decision: replace the spreadsheet with a self-service contact directory and approval workflow.
✓ Redesigned — Self-Service Contact Directory
New Contact Directory
Artifact takeawayPurpose: show the contact-management redesign. Finding: users needed contact data inside the claim workflow, not in a separate spreadsheet. Decision: place contacts inside Claim File and add global directory search.
📓 Before: Master Carrier List Excel file (last updated Oct 2021) — static, manually maintained, IT ticket required for any update, 3-day average wait. After: Live Contacts tab inside Claim File — carrier contacts grouped by policy, each contact showing name/role/phone/email with direct call and email actions. Always current, no IT dependency.
11 — Design: Hi-Fi Prototype

The living contract between
design, engineering, and business

The full interactive prototype was built in Figma and served two purposes: presented to business leaders as the alignment contract before development began, and used as the live starting URL for all remote usability testing sessions on UserTesting.com.

Hi-Fidelity Design — New Claims Workspace
Hi-Fidelity Design — New Claims Workspace
Artifact takeawayPurpose: align business, engineering, and testing around one prototype. Finding: the prototype exposed interaction risks before development. Decision: use the validated prototype as the implementation reference.
🖥️ The fully designed Claims Management workspace — role-aware dashboard with Today's Tasks, inline status badges, smart filters, and integrated navigation. This screen was presented to business leaders as the alignment contract before development, and served as the live starting URL for all UserTesting.com remote sessions.
▶️ View Live Prototype in Figma Opens the full interactive prototype used in business review sessions and usability testing
12 — Validate: Remote Testing & Measurement

Did it work? Testing with
real users on the real prototype

Remote unmoderated sessions on UserTesting.com with 6 participants across Consultant, Co-ordinator, and Coverage Manager roles. A 7-task protocol measuring real performance — not self-reported ease. Level-of-success scoring instead of binary pass/fail to surface iteration priorities.

Test Setup & Protocol
Test Setup — Screener & Protocol
📉 Target: 6 computer users, Age 18–65+. Screener filtered for recent claim file creation experience. Session intro: 'Imagine you are helping your consultant to create a claim file.'
Test Tasks — 7-Question Protocol
🧪 Task 1: Frustration/like (verbal) · Task 2: Information priorities (verbal) · Task 3: Find client + create claim (active task) · Task 4: Binary success · Task 5: Difficulty 1–5 · Task 6: Clarity 1–5 · Task 7: Additional needs (verbal).
Session Results
UserTesting.com — 6 Participant Session Data
UserTesting.com — 6 Participant Session Data
Artifact takeawayPurpose: capture real task performance from representative users. Finding: binary success would hide severity differences. Decision: score levels of success and use issues to prioritize Round 2.
📊 Nov 10–11 2023. Participants: Female/Male, Age 24–39, UK & US. Roles: Consultant / Account Executive / Claim Coverage Manager / P&C Consultant. Notable quote: 'I liked how informative the site was. I was given precise details about how to create a claim file.'
Level-of-Success Scoring & KPI Framework
Measuring Success — Level of Success Table (n=50)
Measuring Success — Level of Success Table (n=50)
Artifact takeawayPurpose: quantify task quality, not just completion. Finding: 30% major issues showed users could finish while still struggling. Decision: iterate information hierarchy before shipping.
📊 Complete: 20% (10/50) · Minor Issue: 40% (20/50) · Major Issue: 30% (15/50) · Failure: 10% (5/50). 95% confidence intervals via Adjusted Wald method. The 30% major issue rate was invisible to binary scoring — this method found it and triggered Round 2 progressive disclosure redesign.
Usability KPI — Performance Framework
Usability KPI — Performance Framework
Artifact takeawayPurpose: define success before evaluating the prototype. Finding: efficiency, effectiveness, errors, memorability, and satisfaction needed separate measures. Decision: map every final metric back to a starting KPI.
📈 5 KPIs defined before testing: Efficiency (claims file <1 min) · Effectiveness (85%+ create claim success) · Errors (no lost track) · Memorability (complex tasks after gap) · Satisfaction (Outlook + Insurer Contacts + Claim Track).
Round 2 Iteration Trigger 30% major issue rate in Round 1 pointed to information density in claim creation flow. Round 2 introduced progressive disclosure — fields shown contextually by claim type. Targeted fix, no full redesign required.
Iteration Arc — Where the Design Failed and What We Learned

Round 1 usability testing
did not go as planned.

The first round of remote usability testing revealed a gap between what we designed and what users actually needed. This is what happened — and how it made the final product stronger.

Round 1 — What We Found
🔍
Task 3: Document Navigation
Success rate dropped below threshold on document retrieval tasks. Users could locate the Documents section but could not distinguish Adjuster Comm from Client Comm quickly enough. The tagging system was present but not surfaced at the right moment in the workflow.
📐
Task 5: Status Escalation
Coordinators struggled to identify when a claim required escalation. The status indicators existed but did not create sufficient visual urgency. Users relied on institutional knowledge rather than the system to know when to act.
💡
Root Cause: Role Assumption
We had designed too heavily for the expert mental model. The User Profile Matrix had already shown that the proficient Co-ordinator role — the highest-volume user — had different scanning needs from the Consultant/Coverage Manager role. Round 1 proved the prototype underweighted that difference, so Round 2 corrected the hierarchy for Co-ordinator workflows.
Round 2 — What Changed
Fix 01
Document Tags Elevated
Adjuster Comm / Client Comm tags moved from metadata row to primary document label. Colour contrast increased. Filter panel defaulted to expanded on Documents entry. Result: users could classify documents at-a-glance without reading filenames.
Fix 02
Status Urgency Signals
Status escalation triggers redesigned with a three-tier visual system (neutral / attention / action). Coordinators could now detect escalation-required states without needing expert domain knowledge. This directly reduced missed escalations in the Round 2 test.
Outcome
85%+ Task Success
Round 2 testing achieved 85%+ task success across all 7 test tasks. The iteration was not a failure — it was the mechanism by which the design reached production quality. Testing failure at prototype stage is cheaper than discovery at deployment.
13 — Strategic Design Decisions

Four integrations — engineering,
compliance and design aligned

These weren't UI features — they were cross-functional initiatives. Each required negotiating engineering feasibility, navigating compliance constraints, and securing business priority. Each one retired a manual workaround that had been costing the team daily.

📧
Integrated Outlook Email
Eliminating 4 app switches per claim
Communication history lived in personal inboxes — invisible to the rest of the team. Critical emails were lost when consultants were absent. Every claim required switching between CMS, Outlook, and SharePoint to piece together a single communication history.
Engineering: OAuth implementation + "link-and-display" architecture (not storing copies) — reduced storage overhead while keeping full history visible.
Compliance: Email content couldn't leave Outlook's security perimeter — display-only integration with deep-link back to Outlook for replies. Compliance approved the bounded model.
Design: Emails tab inside Claim File — linked, tagged, filterable by claim. Co-ordinator Shared Email Inbox as a separate module (surfaced from task profiling, not in original requirements).
ImpactEliminated 3 of 4 daily app switches. Communication history visible to the whole team, not siloed in individual inboxes.
⚙️
Automated Task Creation & Allocation
Manual handoffs replaced by system-driven workflows
Every claim handoff between roles (FNOL → Consultant → Coverage Manager → Service Team) was manual. Tasks tracked in sticky notes, personal Excel sheets, or not tracked at all. Coordination failures were the leading cause of claim processing delays.
Engineering: Workflow rules engine built from scratch. Trigger logic defined collaboratively: claim status change → auto-assign task to correct role. Rule taxonomy established with operations before development.
Compliance: All task assignments needed full audit trail — who assigned, when, and what trigger fired. Assignment log designed as a native feature, not an afterthought.
Design: Task Management module with rule-based auto-creation + manual override capability. Today's Tasks panel surfaces system-generated tasks in priority order on the dashboard.
ImpactManual coordination overhead between roles eliminated. Tasks appear automatically at the right workflow moment — not discovered through team chat or memory.
🔄
Real-Time Data Sync
From stale batch snapshots to live data
The existing system showed batch-updated data — claim statuses and policy details were hours old. Users made decisions on stale information daily, leading to duplicate work and incorrect claim processing across the team.
Engineering: EPIC had a batch sync model. Negotiated hybrid approach — critical fields (status, assignment, policy) on real-time API calls; reporting data stays on batch. 15-second refresh confirmed feasible within EPIC constraints.
Compliance: Data freshness had to be explicit — timestamps required on EPIC-sourced data to prevent decisions on unacknowledged stale information.
Design: Live status badges with EPIC sync indicators. "Last updated" timestamps on critical data fields. W360 Snapshot widget shows live pending claims count on the dashboard.
ImpactDuplicate claim creation from stale data reduced. Status-checking as a daily task eliminated — inline badges replace the need to open records.
📓
Self-Service Contact Directory
Retiring the Excel spreadsheet entirely
Insurer contacts lived in a shared Excel spreadsheet — manually maintained, frequently out of date, requiring IT tickets averaging 3 business days per change. 7 of 12 interviewed users cited this as a major daily friction point.
Engineering: Required a new database entity — Insurer Directory — absent from EPIC schema. Data model defined collaboratively: Insurer → LOB → Contact → Role. Admin approval flow designed to satisfy IT governance requirements.
Compliance: User-editable contact data needed admin approval workflow and full change log. Approval queue built into the design as a native flow — compliance signed off on the controlled self-service model.
Design: Contacts tab inside Claim File + standalone Insurer Directory in global navigation. Search by LOB, insurer name, or contact role. Direct call/email action. Role-based edit permissions.
ImpactExcel spreadsheet retired. 3-day IT wait eliminated. Users update contacts directly via admin-approved self-service — cited as highest satisfaction feature in user feedback.
Change Management — Getting 1,500 People to Actually Use It

Deployment is not the end.
Adoption is.

A redesigned system that is not adopted is a design failure, regardless of usability scores. The change management strategy was built into the project from the start — not bolted on at launch.

📢
Stakeholder Preview Programme
Business leaders and compliance teams reviewed the hi-fi prototype before development began. This was not a sign-off ceremony — it was deliberate adoption groundwork. When those leaders communicated the change to their teams, they had already seen it, understood it, and could articulate the benefit. Informed champions reduce resistance.
🎯
Role-Specific Onboarding
Four user roles. Four different workflow patterns. Training was not generic — it was mapped to the specific task profile each role performed daily. Coordinators trained on contact management and status monitoring. Coverage Managers trained on claim review and document classification. Specificity = faster time-to-competency.
📊
Developer Handoff as Change Instrument
The final developer specification included interaction annotations, state documentation, and error state handling. Engineering was not left to interpret — they were given exact specifications. This reduced implementation decisions that deviated from tested designs, protecting the usability gains earned in testing. Fidelity from test to production.
14 — Impact & Outcomes

What changed for the 1500+ people
using this system every day

All 5 KPIs defined at project start were met or exceeded. Every metric closes the loop back to a specific problem from the original research — the design directly addressed what users said was costing them time.

85%+
Task Success Rate
3 app switches saved
App Switches Eliminated
3 Days → 30s
Contact Update Time
40%
Avg. Task Time Reduced

Beyond task success — supervisors gained real-time team workload visibility for the first time. Not a UX improvement. A new operational capability that simply didn't exist before.

KPI Performance
Efficiency — Navigate to claims file✓ Met
Target: <1 min · All roles · Achieved via role-aware entry points
Effectiveness — Claim creation success✓ Met
Target: 85%+ · Consultant/Co-ordinator · Post Round 2 iteration
Errors — Created without losing track✓ Met
Progressive disclosure reduced creation abandonment
Memorability — Complex tasks after gap✓ Met
Role-aware patterns reduce relearning on return visits
Satisfaction — Integrated features✓ Met
Outlook, Insurer Contacts, Claim Track cited in all sessions
Closing the Loop
Outlook Integration3 of 4 daily app switches eliminated. Communication history visible to the full team — no more information siloed in personal inboxes.
Task AutomationManual role-to-role handoffs replaced by system-triggered assignment. Tasks appear automatically at the right workflow moment — not discovered through team chat or memory.
Contact DirectoryExcel spreadsheet retired. 3-day IT wait eliminated. Cited as highest satisfaction feature. A 3-day wait compressed to instant self-service.
Real-Time SyncStatus-checking as a daily ritual eliminated. Inline badges replace the need to open records to check state. Stale-data duplicate work reduced.
Key Takeaways
🏗️
Start with constraint mapping
Understanding compliance boundaries and EPIC integration limits before ideation prevented wasted cycles. Engineering feasibility reviews at lo-fi stage — not hi-fi — saved weeks of rework.
🤝
Stakeholder alignment is a design output
Personas, heuristic report, SWOT, and prototype weren't just research artefacts — they were alignment tools. Compliance approved integrations because they were involved in designing the constraints.
🗺️
IA is the highest-leverage UX investment
Card sorting shaped depth and role-based groupings. The resulting IA reduced claims access from multi-step search to role-aware direct entry — the single biggest efficiency win.
⚙️
Automation unlocks human attention
Automating handoffs and status visibility freed consultants from coordination overhead — redirecting cognitive energy to high-judgment work that actually requires human expertise.
📊
Measure what matters before you start
5 KPIs defined before a single screen was drawn. The 30% major issue rate was a design signal, not a rationalisation — Round 2 was targeted, not a full redesign.
🔗
Integration is user experience
The Excel contact spreadsheet and app-switching weren't UX problems — they were system architecture problems with UX consequences. The biggest wins came from eliminating boundaries between systems.
Business Impact — The Measured Return

Translating design decisions
into organisational value

Every design choice in this project had a cost or recovery attached to it. These numbers were used during the project to justify scope, prioritise features, and secure stakeholder alignment.

The Cost of the Status Quo
🕐
Hours Lost Per Year
1,500 professionals × 4 hrs/day × 230 working days

= ~1.38M hours lost annually

At average brokerage salary rates, this equates to £18–30M in unrecovered productive capacity per year — entirely attributable to workflow friction, not workload.
🔧
IT Dependency Cost
Every contact update required a 3-day IT ticket. Across the organisation, this consumed significant IT bandwidth on tasks that required zero technical expertise — just access that did not exist.

The redesigned self-service module reduced this to 30 seconds, freeing IT teams for genuinely technical work.
📊
Process Friction Tax
14 steps to complete a standard claims task. Each additional step carried a compounding error probability. The redesigned workflow reduced steps to 8 — a 43% reduction in task complexity that directly lowered re-work rates and training time for new joiners.
Recovery — What the Redesign Returned
85%+
Task Success Rate
Baseline ~60% · Target 85% · Final 85%+
43%
Reduction in Task Steps
Baseline 14 · Target fewer than 10 · Final 8 steps
3 Days → 30s
Contact Update Time
Baseline 3-day ticket · Target self-service · Final 30s
Unified
Communication Hub
Baseline: 3 Apps | Final: 1 Native Hub
Design as Investment The 6-month project cost was recovered not through a single feature, but through multiplied efficiency across 1,500 users. A 1-hour-per-day productivity recovery across the user base represents ~345,000 hours annually returned to billable or strategic work. At any reasonable cost-per-hour, the design investment paid for itself within the first quarter of deployment.
Post-Launch — Long-Term Business Outcomes

What changed in the organisation
after deployment

The immediate usability metrics were the proof of concept. The organisational outcomes were the actual deliverable — and they extended well beyond task success rates.

🏢
IT Department Freed
The self-service contact management module eliminated the category of IT ticket that had consumed significant bandwidth. Contact updates — previously requiring a 3-day IT cycle — became a 30-second user action. IT teams were able to redirect that capacity to higher-complexity infrastructure work.
📨
Communication Traceability
The Outlook integration with native adjuster/client comm tagging meant every communication was now logged, classified, and auditable within the system. For compliance teams, this closed a significant gap. For service teams, it meant any team member could pick up a claim mid-workflow with full context — reducing handoff errors and client-facing delays.
📈
Scalability Foundation
The new IA — structured around role-based access, modular task flows, and real-time data sync — gave the organisation a platform that can accommodate new claim types, additional user roles, and future system integrations without architectural rework. The redesign did not just fix today’s problem. It prevented tomorrow’s.
What This Project Proved
Design as Organisational Lever This project demonstrated that UX design, when positioned correctly within an organisation, is not a finishing layer — it is a strategic instrument. The business outcome was recovered productivity, reduced compliance risk, eliminated IT bottlenecks, improved client-facing response quality, and a scalable technical foundation. Every one of those outcomes traced directly to specific design decisions made during a 6-month project led by a single design strategist working across cross-functional teams simultaneously.