Rebuilding Coalition's quoting flow: seven countries later, the information architecture has barely changed

How I reframed it

How do we reimagine the quoting flow as a guided intelligence layer, not just a form?

One that surfaces the right information at the right moment, adapts to what it already knows about the account, and gives our users a live signal on where the quote is headed before they ever hit submit.

I already knew the domain, so discovery was about testing assumptions rather than learning them. I audited every question in the flow against one test: what does the answer change?

That is where it broke. Attestation and application questions sat at the bottom, in the position you put paperwork. They were not paperwork: their answers decided which coverages appeared and how pricing calculated. Asking them last meant the whole session ran on inputs that did not exist yet, which is where the recalls came from.

My first explorations were smaller: simpler account creation, one question at a time, tighter sequencing. They tested well and solved none of it, because they left customization, pricing overrides and the extension problem exactly where they were. Killing that direction is what made room for the real one.

The stages are fixed: account, application, application questions, quote options, coverages, pricing. What appears inside them is not. Questions resolve at runtime from what the system already knows about the account, and geography comes from the broker's region instead of a dropdown. Admitted and surplus stopped being two versions of a screen.

Two years on the old tool meant I knew which of its rules were real and which were only habit. And I worked this out with the engineers rather than handing them a finished design, because what the screen shows and when it shows it is their problem before it is mine. Design it first and ask later, and the flexible part becomes a second project a year on. Second projects rarely get funded.

Adding a market stopped being a design task and became a data task. Someone adds a question set. No new screen, no new branch, no designer.

What the old flow would have needed instead

Decision 01 · The order of things

Application questions moved to the front, and the account locked behind them

Decision 02 · The pricing module

The pricing module stopped being there when it had nothing to say

In the old tool the pricing module sat in the right-hand column from the second you opened a quote. It showed a limit, a retention, an empty premium, and a live button offering to issue a quote it could not price yet. It was on screen for most of the session with nothing true to show, so people stopped looking at it.

Once attestation questions moved to the front, the fix was almost free. The module now appears when the answers that drive pricing exist, and not before. It is the same rule as the question ordering, applied to the one part of the screen that had been exempt from it.

Then it had to earn the space. The rebuilt module prices up to three options side by side against limit and retention, reprices in place, and absorbed the controls that used to be scattered: review process, quote controls, account owner, and the email controls, so whoever issues the quote sets who sends it, who is copied and who owns the account without leaving the screen. This module took more design time than any other single component in the project.

Before

After

Decision 03 · Validation

I held the line on inline validation and scoped it by ticket volume

End of section validation, flagging every error at submit, was simpler to build and matched the old tool. Inline validation needed field level state handling and more engineering coordination, and it was the direction research kept pointing at.

Rather than argue it as a principle, I made it a scoping problem. Customer success shared their support ticket data, and I used it to rank fields by how often they actually generated errors. Not every field got inline validation in the first release. The highest frequency surfaces did.

Post launch error rates confirmed the ranking. That is also the argument I would use again: a contested pattern is much easier to win as a prioritized subset than as a principle.

Decision 04 · The one I lost

I lost the argument on answering attestations in place

Moving attestation questions to the front had a cost, and it showed up twice. Change an answer late and the quote has to resolve again, which in the shipped design means resubmitting the application. And some coverages carry their own attestation questions, so adding a coverage late triggers exactly the same thing: answer the question, resubmit the application.

My proposal was a modal. Ask a coverage's attestation at the moment the coverage is added, answer it in place, and let the quote resolve without sending the whole application back. Same idea for changing an answer that already exists: edit it where it is, no resubmit.

Engineering scoped it and the answer was no for the first release. The field level state handling it needed was more than M1 could absorb, and it went onto the roadmap. I still think it was the right call for the user and the wrong call for the release, and those are allowed to be different answers.

What I negotiated in exchange was a single control pinned under the left navigation, in view at every scroll position. It carries one of two actions depending on the state of the application, Edit or Submit, never both at once, so whatever the flow will actually let you do next is the thing on screen. A user who changed an answer late did not have to scroll the length of the application to act on it. Smaller than the fix I wanted. It removed most of the cost.

The test came two years later, when Coalition decided account matching should be solved once across the company rather than separately inside each product. I was handed that work.

Making account identity a stage was worth something immediately. Duplicate account creation fell from 36.3% to 23.1% at launch, because the flow now had a place where identifying the account was the only thing you were doing.

Centralizing it was a far harder version of the same problem. Best match against attribute match. Multiple domains. An active broker of record on cyber against excess risk. A single line against all lines. The same agency with multiple brokers. Multiple lines across multiple agencies and brokers. Multiple match states where the original design had one, plus a feedback loop asking users to correct the matching itself.

It went into the account stage rather than around it, and it went into three platforms rather than one: the broker platform, Executive Risk and Cyber. Duplicate account creation fell to a 41% total reduction.

Doing it myself makes this a harder test, not an easier one, because I was the person who would have had to redesign the account step if it had not held. It held, so I extended it instead. The pattern I drew for one product is the one three platforms now use.

What the added states look like

The scale test, arriving now

In May 2026 Allianz Commercial announced it is transferring its standalone commercial cyber portfolio to Coalition and making Coalition its exclusive global cyber partner, phasing in through the US, UK, Australia, Germany, Denmark and Sweden.

Look at that list against the countries already quoting on this flow. The UK, Australia, Germany, Denmark and Sweden are on both. The book is phasing into markets the flow was already resolving question sets for, which is the difference between a partnership that needs a platform built for it and one that can start.

The deal is not mine. The internal tooling it lands in is: core platform design was my remit by then, so making the platform take that book came to me. It has not required the information architecture to change much. That is the argument of this page, tested at a scale I never designed for.

What it unlocked next

The flow became the blueprint for the work that followed: pricing overrides, endorsements, competitive intelligence, agency programs and commission overrides. Each of those used to mean navigating away from the tool. Each of them landed as another thing the stage sequence could hold.

The reissue recap: what changed since last year, read in place

What I would do differently

I scoped inline validation by ticket volume, which was right, and then did not scope the error copy with the same rigour. Handlers hit correct validation with unhelpful messages and called support anyway. We fixed it after launch. It should have shipped in M1, and the miss is instructive: I treated the decision as a systems question and the words as a detail, when the words were the part the user actually met.

I also under invested in migration communications. Adoption was strong, but the first week generated avoidable questions that a single annotated walkthrough would have absorbed. On a launch this size, the walkthrough is part of the design, not an afterthought.