One Language: Building a Living Journey System for Claims
The Problem
The Xactware family of products all support and tie back to the same underlying workflow: the life cycle of a property insurance claim. The trouble was that no two participants in that life cycle described it the same way. Carriers, third-party administrators, and contractors each had their own process, their own vocabulary, and their own tools for their pieces of the process. And those pieces frequently overlapped with other roles.
Our teams were making product decisions inside that confusion. A product manager talking to a carrier and a researcher talking to a contractor could come back with what sounded like two different problems, when they were often looking at the same moment in the claim from two different seats.
The Approach
I did some desk research into journey mapping operations and how other companies handle this kind of complexity. My “Aha!” moment was when I found a UXDX session by Maren Hotvedt, Lead Experience Designer at Atlassian, on their approach to journey layers — the idea of separating a journey into different levels instead of trying to capture everything in one flat map.
I proposed adapting that model for claims: an L0 layer representing the overall claim life cycle, macro flows for each major step within it, and micro flows underneath those capturing the actual moment-to-moment workflow for a specific role or scenario. I built the initial version of that structure with input from a few other senior UX people, and John Hill, one of my fellow UX Directors, built out the journey map template teams would actually fill in.
After the initial creation of the map, my specific contribution was the connective tissue: I built the Lucid board logic that pulled values out of the individual templates and rolled them up into the larger, linked map — so a step in the L0 view could be clicked open to reveal the specific customer workflow behind it. That mechanism was still a proof of concept when I left the role, but it worked, and it's what turned a folder of separate journey maps into something closer to a system.
Recreation of the Journey Map from memory. Actual details are different.
Getting the System to Fill Itself In
The template only works if people use it, and the biggest issue we ran into wasn't willingness — it was timing. No one wanted to be filling in a map while interviewing or observing a user. Whenever a PM, designer, or researcher came back from a customer visit, there was a gap between what they observed in the moment and what actually made it into the template once they were back at their desk. Details got lost in that gap.
Recreation of the journey mapping template we asked the team to fill out for each customer visit; actual details varied.
To close it, I added more processes to capture the information even if the team member didn’t fill out the journey template. If they filled out the journey map, amazing! But we didn’t rely on that alone. We also asked them to do two things they were already inclined to do anyway: drop their raw notes into whatever shared space fit their team (a Word doc, a Lucid board, a Confluence page), and give a short "Telling the Story" presentation to the rest of the company about what they'd observed.
I then built a custom Copilot Studio agent that took both inputs — the raw notes and the recording of the presentation — and extracted the target persona, company type, job-to-be-done, workflow steps, pain points, and insights into a structured staging table. I published the agent to my team so we could review its output before anything went into the actual Lucid map, rather than trusting it to write directly into the source of truth.
That change did two things at once: it lowered the effort required to contribute (tell a story, don't fill out a form), and it meant the map was being populated from what people actually said, not what they remembered to transcribe later.
Where it stood: 27 journey maps in the library, contributed by 6 UX team members and 4 product managers, covering the claim handling process from the adjuster's perspective along with the estimate review process, license management, and the policyholder's side of the claim.
Getting Buy-In
Adoption inside UX was straightforward — I could tell my own team this was the expectation and explain why. Product managers were a different conversation. There was no reporting line I could lean on, so John and I built buy-in the slow way: presenting the system and its purpose multiple times, and then, whenever someone raised the need to understand a customer workflow in an unrelated meeting, dropping the link to the map in the chat and reminding people the project existed and needed their input. Persistence and relevance, repeated, did more than any single pitch did.
The Insight the Map Made Visible
The real payoff wasn't the map itself — it was what having everyone looking at the same structure let us finally see. Once contractors, carriers, and adjusters were mapped against the same workflow backbone instead of described in each team's own language, a pattern that had been invisible became obvious: roles that sounded like they were doing different work were often doing adjacent pieces of the same job-to-be-done, aimed at the same outcome for the same homeowner.
That reframing did something a pile of individual research reports hadn't: it surfaced overlaps as shared problems instead of team-by-team complaints, which is what made them worth solving at a systems level instead of a product-by-product one.
Where It Stands
This work was still in progress when I moved into a different role, so I don't have a tidy resolution to offer. The Lucid linking mechanism was proof-of-concept, not fully scaled. The shared status taxonomy was an identified problem, not yet a shipped solution. What I can point to is a working system — 27 linked maps, a functioning AI-assisted capture pipeline, and a cross-functional group that had started speaking a common language about the customer journey for the first time.
