Insurance claims, rebuilt side by side

The problem

Provet Cloud is the software veterinary practices run on. Nordhealth builds it, clinics across a lot of countries use it, and its insurance claim workflow had been built for the Nordics. That is the whole problem in one sentence. It took a literature review to understand why it mattered.

In the Nordics, clinic staff file a claim themselves, one at a time, close to the consultation it came from. In the UK, a practice group often pays finance people to process claims in batches, days later, against rules the clinical staff never see. Same screen, two completely different jobs. The claim types in the product did not match what UK clinics were actually filing. In feedback that arrives as “the software is wrong”. Underneath it is a legal problem.

The group at the sharp end of it ran around 500 practices in the UK. Three months to fix their market without breaking the product for every other market it already served.

How can we improve the insurance workflow so it fits user and market needs, while taking less time and effort to complete?

What we tried

Research usually arrives too late to change anything. It gets handed over as a document and lands next to a design that is already built. By then it reads as criticism. I have met a lot of researchers who have never worked in design and have no way to say what they found in terms a designer can act on. Designers learn enough code to talk to engineers. Researchers should learn enough design to talk to designers. Mostly they have not.

Running research at Nordhealth mostly meant strategy, standards and the systems underneath. I did not moderate many sessions myself. I took this one hands on and sat next to the designer. It is the clearest evidence I have for why the gap matters.

So Hesam and I ran it as one job with no handover in the middle.

One file, both of us in it. The research lived in the same Figma file as the design. A finding sat next to the frame it affected. When something turned up on a Tuesday, it changed the design on the Tuesday.

Literature first, because the constraints here are legal before they are behavioural. Government sources and insurer portals, written up into one document on how UK veterinary insurance actually works. That surfaced the four topics everything else hung off: conditions, excess fees, continuation claims and debt allocation.

KWE with people who had done the job. Know, wonder, experienced, run with our internal veterinary experts who had worked in UK practice. For each of the four topics we separated what they already knew, what they were unsure about, and what they had personally lived through. Three different things that need three different fixes, and the gaps sent me back into the literature more than once.

The two workflows side by side. Hesam and I mapped what the product already did against what the UK actually needed, feature by feature. That is a design activity and a research activity at the same time. Doing it together took a fraction of the time it would have taken as two documents.

Walkthroughs on the prototype. Hesam ran the sessions, I structured them. Internal experts and UK users going through the flow while we recorded what confused them. Analysed in Dovetail and marked up in the file itself, so the fix landed where the problem was.

One method we dropped. A Jobs to be Done analysis was on the plan and we cut it. The literature and the walkthroughs were already producing more than three months could absorb. Running a method because it was in the plan would have spent time the design needed.

The design

Everything research found was written up as user stories and system stories, each with a scope and a priority. There was far more worth fixing than there was time. The requirements existed to force the argument about where to point the effort.

Automation aimed where the research said the load was. Fields filled in automatically, sections that start collapsed, fields removed entirely. Staff can review and change anything the system filled in, because a claim is a legal document and the person filing it stays responsible for it.

Invoices matched by the system. Finding the right lines on the right invoices was the slowest part of a claim and the easiest to get wrong. The system now works from the items on the claim and connects the invoices itself.

Administration after the fact. When an insurer replies with what they will cover, that used to be retyped line by line. The system now takes the reply row by row and applies the overall coverage itself.

Less on the screen at once. Clear section breaks, an obvious order, required fields and missing data marked as such, and copy rewritten to say what it means.

Outcome

In usability testing on the prototype, filing a claim went from five to eight minutes down to about three, and satisfaction with the flow went from 2.2 to 3.8 out of five.

Those are prototype numbers, from testing before handover. I had left Nordhealth by the time the work shipped, so I never saw the production figures and I am not going to claim them. What I can say is what was true when I handed it over, and that the flow is still in the product.

The part that transfers to any other project is the way it was run. A researcher and a designer working in one file, on the same day, produced a redesign of a legally constrained workflow in three months. The research never had to be handed over. It was already in the file the design was in.

Hesam and I wrote the long version of this together, with the workshop photos and the before and after screens: The magic that happens when you put design and research in the same room.