Insurance Enterprise AI-assisted · 2026

One broker. One pitch. Two platforms it had to escape.

ANZ's largest insurance broker network (~400+ brokerages, ~17,000 platform users) engaged us to consolidate a 20-year-old broker management system and a separate multi-insurer quoting platform into one product. I joined as sole UX designer for discovery: seven personas, six end-to-end journeys, an opportunity backlog bridging 117 business requirements to a real broker's day, plus the user flow, wireframes and hi-fi prototype for the MVP slice the client unveiled at a major ANZ broker summit.

Role Sole UX Designer · Discovery + Phase 3
Timeline ~16 weeks · Nov 2025 – Feb 2026
Team 1 designer · BA · Solution architect · Data + AI engineers · 7 client stakeholders · ~20 SMEs
Impact Pitch-to-quote 30→5 min · ~30% projected cloud-cost reduction · +6–8% revenue from new marketplace + ad streams · Platform unveiled at major ANZ insurance summit

OneApp broker dashboard — Steady AI floating assistant and dedicated workspace

OneApp composite — dashboard, risk report, go-to-market, quote comparison

01 Overview

ANZ's largest broker network ran on two platforms that didn't talk to each other.

400+ brokerages across Australia, New Zealand, Asia and Europe distribute 160+ insurance products through this network. Their broker stack had grown into two parallel systems: one for clients, policies and trust accounting (7,000 users), and another for multi-insurer quoting (10,000 users). Around them sat risk tools, insurer portals and Excel sheets brokers had taught themselves to glue together.

The brief asked for a tech upgrade: consolidate the two into one product, grow Gross Written Premium across the network. The engagement needed a discovery pass first. I joined as sole UX designer to run it.

02 Problem

The platform wasn't broken in one place. It was broken in the seams between them.

Both systems were essential and incomplete. The CRM held the policy record but couldn't go to market. The quoting platform could fan a submission out but couldn't talk to the CRM. Schedules and renewal forms lived as Word and PDF attachments inside the older system, impossible to query or compare year-over-year.

The CRM is also optional. Brokers can and do switch to Zoho or MS Dynamics. A replacement that didn't fix the seams wouldn't consolidate users; it would lose them.

Five business drivers sat behind the brief: grow GWP, make brokers more efficient, give insurers a self-service path (5–6 months down to minutes), cut cloud and ops cost, and reduce risk in an early-2000s stack. "Consolidate two platforms" was the surface ask. Five compounding outcomes were the real brief.

"Brokers were re-entering the same client info across two platforms and a dozen side tools, then stitching quote packs together from three document formats. The platform wasn't broken in one place. It was broken between places."

03 My role

Signed on for research and personas. Stayed for everything that turns research into a buildable product.

The statement of work was narrow: conduct research, facilitate design workshops, build personas, map the journeys. That was the scope on paper. The team around me was cross-functional: BA, Solution Architect, Data/AI engineers, plus ~30 client-side stakeholders and SMEs.

The first weeks made the picture bigger than the SOW. Stakeholders had assumed the legacy problems were technical. Research showed brokers were avoiding the platform, sometimes on purpose, because it had been built for engineers, not for them. That single finding shifted the conversation: the engagement stopped being a technical re-platform and became a design problem.

The client also handed us ~117 business requirements. Personas and journeys alone couldn't bridge them to a real broker's day. So I extended my scope to four more artefacts to connect the dots.

In the SOW

— Research & design workshops. Stakeholder interviews, SME sessions, and a co-creation workshop for an upcoming customer-facing surface.
— Personas. Seven personas from interviews and telemetry: Account Manager, Bookkeeper, Claim Handler, Principal Broker, Administrator, Underwriter, and the end client.
— Journey maps. Six end-to-end journeys: Pitch & Bind, Renewal, Claims, Policy Transfer, Underwriter, and Receipt & Pay.

Beyond the SOW: added to bridge 117 requirements to a broker's day

— Opportunity backlog. 33 opportunities for Pitch & Bind, 40+ more across the other journeys, each mapped to a requirement and prioritised with MoSCoW. Gaps surfaced new findings I raised with the client.
— Design system expansion. The client's Fluent-inspired system was built for engineering and missed most of the patterns the new flows needed. I expanded it so the prototype and downstream build shared a governable foundation.
— MVP user flow. Drafted the Pitch & Bind flow solo, then refined it with the BA, architect and stakeholders. Most of the original structure held.
— Wireframes & hi-fi prototype. SME-driven iteration rounds, then an interactive Figma prototype for the Assessment → Quote → Compare slice. This is what stakeholders demoed at one of Australia's largest broker summits.

04 Design process

Seven phases. One slice that had to earn the other six.

Phases 1 and 2 were owned by the client's internal team. We picked up at Phase 3 (design discovery). This case study covers that phase end-to-end.

01 Pre-discovery Bid response, stakeholder shaping, and platform context, owned by the client's internal team before I joined.
02 Foundations Brand, environment and existing-app reviews. Also pre-our-team. We picked up the work from here.
03 Design discovery Personas, journeys, opportunity backlog, scope decisions, user flow, wireframes, hi-fi prototype.
04 Platform build Engineering picks up the prioritised backlog through BRDs; design supports build with iteration and QA.
05 Adjacent journeys Renewal, claims, policy transfer, bookkeeper workflows extended onto the same platform spine.
06 Insurer + client portals Underwriter-side and customer-facing surfaces rolled into the unified platform.
07 Platform hardening Performance, accessibility, observability, and cutover from the two legacy systems.

05 Discovery

Brokers were avoiding the platform on purpose. Discovery had to start there.

Discovery ran across ~40 stakeholder and SME sessions covering quoting, binding, accounting, claims, packaging, premium funding, notifications, documents, onboarding flows, and insurer integration. The design-led tracks I owned produced personas and journey maps. The business-function tracks were BA-led; I was the design voice in the room.

I also facilitated a co-creation workshop with ~15 stakeholders to shape an upcoming customer-facing surface. A sticky-note board from that session became the starting brief for Phase 6.

Stakeholder co-creation workshop. The board became the feature spine for the Phase 6 surface.

40+ SME & stakeholder sessions
117 Business requirements bridged
~30 Client + delivery participants
17k Brokers across the two systems

One synthesis board to hold the whole picture

Six fragments on one board, so vision, scope, users, current state, competitor read, and trade-offs sat side by side instead of in separate decks. Stakeholders could check any prioritisation call against the full picture in one place.

Synthesis board

Vision and the five business drivers behind the consolidation: grow GWP, broker efficiency, insurer self-service, cloud-cost reduction, risk reduction.

Proto-personas came first, so interviews had something to push against

Before the formal sessions, I ran my own secondary research on the business model, the network's commercial structure, the ANZ competitor landscape, and the role archetypes the legacy platforms were built around. That became a set of proto-personas: best-guess sketches of the people who'd actually use the new product.

I walked them through the first stakeholder sessions. Stakeholders pushed back, confirmed, and shared their own internal research, which I folded in. By the time formal discovery opened, both sides trusted the same starting point. The seven personas below are what the validation pass produced.

Personas

Pitches new business and owns the client relationship end-to-end. The spine of the MVP journey: every opportunity flows through this role first.

Bookkeeper Broker

Detailed artefact protected under NDA. Happy to walk through it on a call or in person.
Claim Manager

Detailed artefact protected under NDA. Happy to walk through it on a call or in person.
Principal Broker

Detailed artefact protected under NDA. Happy to walk through it on a call or in person.
Broker Administrator

Detailed artefact protected under NDA. Happy to walk through it on a call or in person.
Insurer / Underwriter

Detailed artefact protected under NDA. Happy to walk through it on a call or in person.
Client (small-business owner)

Detailed artefact protected under NDA. Happy to walk through it on a call or in person.

One journey overlapped the most with the rest. That became Phase 3.

Six end-to-end journeys covered the network's operating model. Pitch & Bind a Policy for a new customer won the Phase 3 slot because its eleven stages overlapped the others the most. Get the seams right here and most of the other journeys would inherit the fix.

MVP journey · scroll horizontally to read

Pitch & Bind a Policy

New customer end-to-end: receive contact → validate → assess risk → quote → present → bind → invoice → receipt. The MVP journey.

Other journeys · protected under NDA

Existing customer cycle: re-rate the risk, refresh declarations, compare to last year, re-bind.

Renewal of a Policy

Detailed artefact protected under NDA. Happy to walk through it on a call or in person.
New Motor Claim

Detailed artefact protected under NDA. Happy to walk through it on a call or in person.
Policy Transfer

Detailed artefact protected under NDA. Happy to walk through it on a call or in person.
Underwriter Provides a Quote

Detailed artefact protected under NDA. Happy to walk through it on a call or in person.
Receipt Invoice & Pay Insurer

Detailed artefact protected under NDA. Happy to walk through it on a call or in person.

Key insights

— Brokers were doing one job, pitching a policy, across two platforms and a dozen disconnected tools. The cost showed up everywhere: duplicate data entry, broken comparisons, manually-assembled quote packs.
— The broker management system is optional. Brokers can and do use Zoho, MS Dynamics or other CRMs instead. Any new platform has to be earned, not assumed.
— Risk-assessment tools weren't integrated with the main CRM. Brokers logged into a separate tool to validate each client, then re-typed the findings.
— Schedules and renewal forms lived as Word and PDF blobs inside the legacy system. Locked data that could not be queried, compared, or auto-populated for the next year.
— Comparing renewal schedules to last year was a manual read of 100+ pages. Assembling a quote pack from three document formats took 20+ minutes. Errors slipped through.
— Underwriters, the platform's other side, were the most under-served voice in the system. Every opportunity arrived in a different shape; they re-typed the same fields into their own tools to begin work.
— End customers had no platform at all. Policy holders coordinated with their broker by phone, email or in person. They couldn't view their own policies, lodge a claim digitally, or pay an invoice without help. The second under-served voice, and the second new surface on the roadmap.
— The brief asked for embedded-grade accessibility. Discovery showed the real friction was elsewhere: brokers were leaving the platform entirely for parts of their day.

06 Define

33 opportunities for Pitch & Bind alone. MoSCoW chose the slice.

Every pain point and idea from the journeys went into one backlog. Each row carried a stage, a problem, a future-state opportunity, a feasibility rating, and a link to the relevant requirement. Pitch & Bind alone produced 33 opportunities across 11 stages. The other journeys added 40+ more.

MoSCoW set the slice. Must items became Phase 3. Should and Could mapped to Phases 4–7.

The brief listed nine separate AI capabilities. The recommendation back to the client was to fold them into one in-product assistant. One place for the broker to ask, not nine to remember.

Underneath the backlog sat a two-level competitor read. A feature benchmark of INSIGHT against Ebix WinBEAT, and a market scan of Ebix (entrenched), JAVLN (cloud-native challenger), and Sunrise (Ebix's quoting platform, the one brokers prefer to SCTP because it asks ~6 questions instead of hundreds). That read set the bar Phase 3 had to clear.

Synthesis

Legacy CRM pain consolidated from BA sessions and broker interviews: system-switching, BLOB-stored documents, Excel-based rating, alphabetical insurer bias.

Opportunity backlog · problem → business requirement

Each row connects a journey-stage problem to one of the 117 client business requirements, so every prioritised opportunity has a traceable spec line behind it. Five sample rows below from Pitch & Bind. The full 33-row backlog is under NDA.

Opp ID	Stage	Problem	Linked BRD	Opportunity	Priority
OP-01	Receive Contact	Manual lead tracking across referrals, phone, email and social. Leads get lost and follow-up timing is inconsistent.	REQ-109 Tasking & Reminders	AI-prioritised lead inbox with automatic broker assignment.	Must
OP-02	Validate	Risk tools (iSurveyRisk, iProfileRisk, LMI RiskCoach) aren't integrated with INSIGHT. Brokers log into multiple systems.	REQ-040 / REQ-041 / REQ-042 External API Integrations	Risk-assessment hub launching all third-party tools from the client profile.	Must
OP-06	Assessment	Each insurer asks for the same information in different formats. Brokers re-enter the same data multiple times.	REQ-045 Standardised Insurance Product Objects	One Steadfast quoting engine: capture once, distribute to every insurer in their format.	Must
OP-11	Go to Market	Brokers repeat the quoting process across SCTP, Sunrise and insurer portals. Same client info entered again and again.	REQ-047 / REQ-048 Quote Request + Response	Single submission point that sends to all insurers simultaneously.	Must
OP-12	Go to Market	Brokers only see underwriting outcomes after a full submission. Wasted time when an insurer declines.	REQ-111 Communication & Tracking (NLP)	Pre-submission AI signal flagging insurers likely to decline a given risk.	Should

Remaining 28 rows protected under NDA. Walk-through available on a call.

MoSCoW prioritisation

Each requirement is tied to a problem, a solution, the persona it serves, the journey it sits in, and a Must/Should/Could call. Sample rows below; the rest of the matrix is under NDA.

REQ ID	Requirement	Problem	Solution	Persona	Journey	Priority
REQ-045	Standardised Insurance Product Objects	Each insurer asks differently for the same data, forcing brokers to re-enter and re-format.	Standard product objects with a unified question set, mapped per insurer.	Account Manager	Pitch & Bind	Must
REQ-047	Quote Request	Initiating quotes across SCTP, Sunrise and insurer portals is fragmented and repetitive.	Single quote-request flow that fans out to all selected insurers.	Account Manager	Pitch & Bind · Renewal	Must
REQ-068	Risk-Based Data Fields	Insight's risk capture lives in Excel custom forms — not searchable, not comparable.	Structured risk fields native to the platform, replacing Excel attachments.	Account Manager	Pitch & Bind	Must
REQ-103	AI Pre-fill Forms	Brokers retype the same client data into every new transaction.	AI auto-populates forms from prior interactions and documents.	Account Manager · Bookkeeper	Pitch & Bind · Renewal	Should
REQ-108	AI Policy Scan on Renewal	Renewal wordings change year-to-year; brokers manually read 100+ pages to spot gaps.	AI compares renewal docs to last year's policy, flags discrepancies before send.	Account Manager	Renewal	Could

Rest of the prioritisation matrix protected under NDA.

The brief asked for embedded-grade accessibility. Discovery showed brokers were leaving the platform for parts of their day. Scope shifted to match the real problem.

07 Ideation

Most of the first user flow held. Which meant the journey maps had done their job.

I drafted the Pitch & Bind flow solo, then refined it with the BA, architect and stakeholders. Wireframes ran the same loop: round one to surface assumptions, SME feedback to test them, round two through final to lock the structure.

User flow — Pitch and Bind a Policy for a new customer (MVP scope) — User flow — Pitch & Bind, MVP scope

Four wireframe rounds in two-to-three days, under a stacked deadline

Investor meeting, broker-community showcase, then the ANZ summit a month later. Two-to-three days per round. I used Figma Make and UXPilot to break the blank canvas, then pulled everything back into Figma as the source of truth. The harder problem wasn't drawing; it was keeping feedback consistent across stakeholders, BAs, the architect, and the data team while validating data and locking structure before any hi-fi work began.

Dashboard wireframe iterations

First-cut dashboard structure: navigation, KPI tiles, primary work surface. Quick scaffold to get a shared visual to react to.

Visuals carried in from the client's Fluent-inspired token set with an early Storybook. Discovery surfaced a parallel finding: the design system existed but no team was using it. With 5–6 user-facing apps scheduled across Phases 3–7, that gap was a real risk. It became its own workstream. A multibrand React design system on a Figma → Token Studio → Style Dictionary → GitHub → Storybook pipeline, staffed outside the MVP team so it could move at its own cadence.

08 The platform

Two legacy systems and a stack of side tools, replaced by one product.

One product doing the work of both INSIGHT (CRM, trust accounting, policies, claims) and SCTP (multi-insurer quoting), with the side tools brought in: risk, calendar, comms, document packaging, AI. The screens below are the flows brokers actually walked through.

Before · legacy platform (INSIGHT & SCTP)

Legacy platform — INSIGHT / SCTP.

Dashboard hi-fi · interaction loops

Scoped global search across Contact, Account, Application, Invoice, Notes and Client Policy. Drill-down dropdown cuts irrelevant matches and lightens DB load. Collapsible side nav frees the canvas for the work surface — KPIs, tasks, contact/account/application updates, and policy lookups during live client calls.

Create New Account — grouped form (7–8 fields per group), per-group progress, save-as-draft, summary review, post-create confirmation — Create new account · grouped flow Old flow blocked the broker until every field was filled. New flow breaks it into 4–5 groups of 7–8 fields, surfaces the must-haves first, and shows per-group progress (completed vs left). Save-as-draft picks up where the broker left off. A summary screen lets them review the client info and add anything missing before saving. On success, a confirmation with a direct link into the new account.

Account flows · list → 360 → risk

Single list view of every account: primary contact, policy updates (renewals coming up), account type, value, and status. Brokers search, filter, and configure which columns they want visible — the table flexes to how each broker reads their book.

Quote flows · application → market → compare

Every new quote or renewal runs through an application: client details, insurance type, industry, risk inputs. Known data prefills where it exists. Same grouped pattern — 5–7 fields per group with clear completed-vs-missing signal so the broker knows exactly what's left. Broker picks the insurers to go to market with in the same flow. A summary screen catches anything before submission, and AI predicts how many insurers the application is likely to be eligible with.

A minimal product in place of two legacy systems plus the side tools brokers were patching around them. Phase 3 shipped this slice. The next phases pick up with four UX designers and two design-system specialists running the remaining surfaces (renewal, claims, transfer, bookkeeper, insurer, customer portal) through the same model.

09 Impact

On stage at one of Australia's largest broker summits.

30 → 5 min

Projected pitch-to-quote cycle time on the new platform. ~30 minutes in the legacy stack, ~5 minutes walking the new flow end-to-end.

Source: Platform walk-through with brokers
~30%

Projected cloud-infrastructure cost reduction once the two legacy platforms retire. The existing architecture was a major contributor to the run-rate.

Source: Programme business case
+6–8%

Estimated additional revenue against an existing AUD ~1.6B annual base, from two new business streams: a third-party tool marketplace and an in-platform advertising surface.

Source: Commercial modelling
Unveiled

Platform presented to investors, the broker community, and unveiled at one of Australia's largest insurance broker summits

Source: Client engagement

Client signed off. The platform went to investors, then the broker community, then on stage at one of Australia's largest broker summits. The opportunity backlog became the engineering sprint plan. The design-system gap got its own workstream, two people, tokens-first.

Discovery also rewrote the engagement. The brief's embedded-grade accessibility ask was de-scoped once the real audience was clear. The bigger finding, brokers leaving the platform mid-day, became the thing the product had to fix. Stakeholders backed the recommendation, not the original ask.

The product on stage at one of Australia's largest insurance broker summits — On stage at one of Australia's largest insurance broker summits.

Group photo with stakeholders after the successful discovery and platform unveil — With stakeholders after discovery closed and the platform landed with investors and the broker community.

Two revenue streams fell out of the work that weren't in the brief. A marketplace for third-party broker tools, vendors list and the network takes a commission. An in-platform advertising surface for insurers to reach the brokers most likely to sell their products. Both modelled to add 6–8% against an existing AUD 1.6B base.

The two voices the legacy stack ignored, underwriter and end customer, get their own surfaces in Phase 6. Both sides finally sit inside the same system instead of routing through the broker's inbox.

Three things to carry forward. One I'd do differently.

Carry forward. The opportunity backlog as the bridge. A row that ties a persona, a journey stage, a problem, an opportunity, a feasibility rating and a requirement is the most useful artefact a discovery can produce. It survives the room.

Carry forward. Running design sessions and joining business sessions, not collapsing them. Keeping the formats distinct kept both kinds of thinking sharp.

Carry forward. Drafting the user flow alone before refining with the team. The first cut held because the journey work was honest.

Do differently. Surface the design-system gap in Week 2, not Week 10. By the time it had a workstream, platform work had already shipped on the old visual language. Some of it will need re-laying on the new tokens.

How did this land

A quiet way to react. No account required.

Got more to say? Send a note →

← Previous

Predicare

Healthcare · Enterprise · 2023

All case studies →

Back to index

Browse the rest

Working on something similar

Want to talk about it?

Discovery-led engagements, legacy-system consolidation, AI-assisted enterprise workflows. Happy to think through scope or framing before you commit.