Conversational AI journey builder

2026

An identity-verification company had an expert journey editor and wanted a conversational one: an AI assistant that builds journeys in chat and explains them.

The final design from the coded prototype: on the left the conversation, where a request to turn off liveness detection is confirmed as Version 2; on the right the journey panel with its estimated pass rate, steps and the excluded step greyed out

Context

Regulated businesses must verify every new customer before they can play, bet or trade. Designing that verification journey was expert work: a consultant engagement, or the client’s own journey editor. A global identity-verification company wanted a conversational, AI-powered builder alongside it.

Business goal
Self-serve: customers leave with a journey they can read, adjust and share, without a consultant.
Users
Analysts and operations teams at regulated businesses, who answer for what goes live.
Product
Describe the business or share a policy in chat. The assistant asks only what’s missing, builds the journey and explains it.

Problem

A chat can generate a journey easily. The design challenge was everything around it: how a conversation shows a journey, explains it and changes it, when someone has to answer for what goes live. If people can’t check and change what the AI built, they won’t use it, and customers go back to waiting for a consultant.

My role

Product designer in an Intellias AI Pod, from the first prototype to a release in development. Acting product manager for three weeks.

Frame
Pulled past research and decisions into one shared context.
Prototype
Built every idea as a coded prototype with AI agents, in days.
Test
Ran three rounds of moderated testing on those prototypes.
Specify
Wrote the release scope as acting product manager.

Process

With the platform UX lead, I ran six think-aloud sessions on the coded prototypes and coded 105 insights from them. Participants were internal, from sales and delivery; no end customers yet. Three findings set the direction.

Where it lives says whose it is
“I prefer it because I can see the history in one place.”
Sales colleague, round 2
If I can’t change it, I can’t trust it
“If I can’t edit this manually […] a way to edit it would be brilliant.”
Sales colleague, round 1
Every number is a promise
“It was actually banned […] you’re setting an expectation that you may meet and you may not.”
Solutions consultant, round 3

Solution

The journey lives beside the conversation

Challenge: On a separate screen, the AI's work read as someone else's tool. Relabelling it didn't help.
Solution: I moved it into the chat. When big journeys felt cramped there, I reopened my own decision and tested a side-by-side layout with versions; round 3 preferred it in a demo.

August · read as another tool
Early September · clear, but cramped
Late September · preferred in a demo

Changes are proposed, then confirmed

Challenge: People wanted to change the journey by asking, but a chat silently rewriting a compliance journey felt risky.
Solution: The assistant pre-fills the change and marks it “Proposed”. Nothing applies until the person saves, and every change can be undone: one extra click, in exchange for no silent edits.

Asked in the chat, saved as a new version.

Confirmed in a familiar form.

One number, explained

Challenge: Any figure on screen reads as a promise to the customer.
Solution: The team cut what we couldn't stand behind. I designed the one estimate we kept to say what it's based on and when it drops, and flagged whether to show it at all as a call for product and commercial leads.

The estimated pass rate with its tooltip open: what the figure measures, that it is an estimate from similar journeys and a best case, four conditions that lower it, and that a trial on the customer's own data gives the real figure — The number itself is a mock value from the prototype.

Outcome

The design became the release.

The side-by-side layout, versions and editing by conversation went into the next release, with the prototype as the reference it is built from.

Evidence, not opinion.

Every direction came from testing with people who set journeys up for customers, and I reversed my own decision when the evidence said so.

In code within three weeks.

The first parts were built within three weeks of the specs I wrote as acting product manager.

No customer has used it yet. Next I’d measure what the business cares about: journeys changed instead of restarted, and journeys published without booking a consultant.

What I learned

Test with real customers sooner
All my participants were internal, not the people who will sign off a live journey.
Remove the cause, don’t style around it
Relabelling cost a test round. Moving the work fixed it in one.
Let AI do the groundwork, not the judgment
Cheap prototypes left time for framing, testing and deciding.