Insurance Enterprise AI-assisted · 2026

Insurance broking, reimagined around the people who make it work.

Client name and identifying details altered per NDA.

ANZ's largest insurance broker network ran on two old platforms that didn't talk to each other: INSIGHT, a 20-year-old CRM for policies and trust accounting, and SCTP, a separate multi-insurer quoting system. Together they served 400+ brokerages and around 17,000 people. I joined as the sole UX designer to lead discovery, then grew into leading a team of six through build. The work: seven personas, six end-to-end journeys, and a backlog connecting 117 business requirements to what a broker actually does all day. That fed the user flow, wireframes, and the hi-fi prototype the client showed off at a major ANZ broker summit.

Role UX Designer → Lead · Discovery solo, then led 6 through build
Timeline ~16 weeks · Nov 2025 – Feb 2026
Team 1 → 7 (solo discovery, then leading 4 UX designers + 2 design-system specialists through build)
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, split across INSIGHT and SCTP.

400+ brokerages across Australia, New Zealand, Asia and Europe sell 160+ insurance products through this network. Over the years, their tech stack had split into two systems: INSIGHT, for client records, policies, invoicing and trust accounting (7,000 users), and SCTP, for getting quotes from multiple insurers and used by underwriters on the other side (10,000 users). Around both sat risk tools, insurer portals, and Excel sheets brokers had taught themselves to stitch together.

The brief was simple on paper: merge the two systems into one product and grow the network's Gross Written Premium. Before any of that could start, the engagement needed a discovery phase. I joined as the sole UX designer to run it.

02 Problem

Not broken in one place — broken in the seams between INSIGHT and SCTP.

Both systems mattered, and both were half the story. INSIGHT held the policy record but couldn't take a submission to market. SCTP could reach every insurer but couldn't talk back to INSIGHT. Schedules and renewal forms sat as Word and PDF attachments inside INSIGHT: locked away, impossible to search or compare from one year to the next.

And INSIGHT isn't mandatory. Brokers can, and do, switch to Zoho or MS Dynamics instead. A replacement that didn't fix the gap between the two systems wouldn't bring users together. It would push them further away.

Behind the brief sat five business drivers: grow GWP, make brokers more efficient, give insurers a self-service path (cut 5–6 months down to minutes), cut cloud and ops cost, and reduce risk in a stack built in the early 2000s. "Consolidate two platforms" was the ask on the surface. Underneath it were five outcomes that all had to land together.

"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

Sole UX designer for discovery, then lead of a team of 6 through build.

I joined as the sole UX designer for discovery, building personas, journeys, an opportunity backlog, and user flows. On paper, the scope was narrow: run the research, facilitate design workshops, build the personas, map the journeys. Around me sat a cross-functional team: a BA, a solution architect, data and AI engineers, and around 30 client-side stakeholders and subject-matter experts.

The first few weeks showed a bigger picture than the statement of work described. Stakeholders had assumed the legacy problems were technical. Research told a different story: brokers were avoiding the platform, sometimes on purpose, because it had been built for engineers, not for them. That one finding changed the conversation. This wasn't a technical re-platform anymore. It was a design problem.

The client also handed us 117 business requirements. Personas and journeys alone couldn't connect them to what a broker actually does in a day, so I added four more artefacts to close that gap.

As the project moved into build, I grew into leading a team of 4 UX designers and 2 design-system specialists (one designer, one front-end architect) through delivery of the hi-fi prototype and the design system.

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, plus 40+ more across the other journeys. Each one is mapped to a requirement and prioritised with MoSCoW. The gaps I found while building it became new findings I raised with the client.
— Design system expansion. The client's Fluent-inspired system had been built for engineering, and it was missing most of the patterns the new flows needed. I expanded it so the prototype and everything built after it shared one 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, shipped first.

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. I grew and led a team of 4 UX designers and 2 design-system specialists (1 designer, 1 front-end architect) through this phase, supporting 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

Why brokers were avoiding the platform on purpose.

Discovery ran across roughly 40 sessions with stakeholders and subject-matter experts, covering quoting, binding, accounting, claims, packaging, premium funding, notifications, documents, onboarding, and insurer integration. I owned the design-led tracks, producing personas and journey maps. The business-function tracks were BA-led, and I sat in as the design voice in the room.

I also ran a co-creation workshop with around 15 stakeholders to shape an upcoming customer-facing surface. The 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 board, the whole picture

I put vision, scope, users, current state, the competitor read, and trade-offs on six fragments of one board, instead of scattering them across separate decks. That way, stakeholders could check any prioritisation call against the full picture without leaving the room.

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, validated by real interviews

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

I brought them into the first stakeholder sessions. Stakeholders pushed back, confirmed what held up, and shared their own research, which I folded in. By the time formal discovery opened, both sides were working from the same starting point. The seven personas below are what came out of that back-and-forth.

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.

Pitch & Bind: the journey that overlapped the rest

Six end-to-end journeys covered how the network actually operates. Pitch & Bind a Policy for a new customer got the Phase 3 slot because its eleven stages overlapped every other journey the most. Fix the seams here, and most of the other journeys inherit the fix for free.

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

— Pitching a policy is one job. Brokers were doing it across two platforms and a dozen disconnected tools. That showed up as duplicate data entry, comparisons that didn't line up, and quote packs assembled by hand.
— INSIGHT is optional. Brokers can, and do, switch to Zoho, MS Dynamics or another CRM instead. A new platform has to earn its place, not assume it.
— Risk-assessment tools sat outside INSIGHT. Brokers logged into a separate tool to check each client, then typed the results back in by hand.
— Schedules and renewal forms lived as Word and PDF files inside the legacy system, locked away from search, comparison, or next year's auto-fill.
— Comparing this year's renewal to last year's meant reading 100+ pages by hand. Building a quote pack from three document formats took 20-plus minutes. Errors slipped through.
— Underwriters sit on the other side of the platform, and the legacy system barely served them. Every submission arrived in a different shape, so they re-typed the same fields just to start work.
— End customers had no platform at all. They coordinated with their broker by phone, email, or in person, and couldn't view a policy, lodge a claim, or pay an invoice on their own. The second under-served voice, and the second new surface on the roadmap.
— The brief asked for embedded-grade accessibility. Discovery found the real friction elsewhere: brokers were leaving the platform altogether for parts of their day.

06 Define

33 opportunities, prioritised down to one MVP slice.

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

MoSCoW decided the slice: Must items became Phase 3, and Should and Could items mapped out across Phases 4 to 7.

The brief listed nine separate AI capabilities. I recommended folding them into one in-product assistant instead, so a broker has one place to ask, not nine to remember.

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

Synthesis

Legacy INSIGHT 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 OnePlatform 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

From user flow to wireframes to hi-fi prototype.

I drafted the Pitch & Bind flow on my own first, then refined it with the BA, the architect and stakeholders. The wireframes ran the same loop: a first round to surface assumptions, SME feedback to test them, then rounds 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, two to three days each

An investor meeting, a broker-community showcase, then the ANZ summit a month later. Two to three days per round. I used Figma Make and UXPilot to get past the blank canvas, then pulled everything back into Figma as the source of truth. The hard part wasn't drawing the screens. It was keeping feedback consistent across stakeholders, the BAs, the architect and the data team, while validating the data and locking the 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.

The visuals came from the client's Fluent-inspired token set and an early Storybook. Alongside all this, discovery turned up another finding: the design system existed, but no team was actually using it. With 5 to 6 user-facing apps scheduled across Phases 3 to 7, that gap was a real risk, so 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 pace.

08 The platform

INSIGHT, SCTP, and every side tool, replaced by one product.

One product now does the work of both INSIGHT (client records, policies, invoicing, trust accounting, claims) and SCTP (multi-insurer quoting, used by underwriters too), with the side tools pulled in as well: 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

Search reaches across Contact, Account, Application, Invoice, Notes and Client Policy, with a drill-down dropdown that cuts out irrelevant matches and lightens the database load. The collapsible side nav frees up the canvas for the real work: KPIs, tasks, contact/account/application updates, and policy lookups mid-call with a client.

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 The old flow blocked the broker until every field was filled in. The new one breaks that into 4 to 5 groups of 7 to 8 fields, puts the must-haves first, and shows progress on each group so brokers know what's done and what's left. Save-as-draft picks up right where they left off. A summary screen lets them review the client's details and fill in anything missing before saving, and on success, a confirmation screen links straight 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, so 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 lean product now stands in for two legacy systems and the side tools brokers were patching around them. Phase 3 shipped this slice. The phases after it 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

Shipped, unveiled, and already paying off.

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

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

Discovery also changed the shape of the engagement. Once the real audience was clear, the brief's embedded-grade accessibility ask fell away, and the bigger finding, brokers leaving the platform mid-day, became the thing the product had to fix instead. Stakeholders backed that recommendation over 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 original brief. A marketplace where third-party tools list themselves and the network takes a commission, and an in-platform ad surface where insurers reach the brokers most likely to sell their products. Together, they're modelled to add 6 to 8% on top of an existing AUD 1.6B base.

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

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

Carry forward. Use 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 together is the most useful thing a discovery can produce. It's the one artefact that survives the room.

Carry forward. Keep design sessions and business sessions separate instead of folding them together. Keeping the formats distinct kept both kinds of thinking sharp.

Carry forward. Draft the user flow alone first, then refine it with the team. The first cut held up because the journey work behind it was honest.

Do differently. Surface the design-system gap in week 2, not week 10. By the time it had its own workstream, platform work had already shipped on the old visual language, and some of it will now need re-laying on the new tokens.

How did this land

A quiet way to react.

Got more to say? Send a note →

← Previous

All case studies

Back to the index

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.