From UI to Working Process
In my previous article I showed how quickly an idea can become a working UI design, a few reference images, a prompt, and a functional HTML prototype created in hours. This time I wanted to go a step further: take that mockup and turn it into a working process you can actually demo to a client.
A UI prototype answers the question “does this look right?”. A process demo answers “does this flow make sense?”. They serve different conversations and both are needed.
A Note on Tooling Philosophy
Most prototyping tools give you a fixed feature set. You learn what the tool can do, and you work within those boundaries. If the tool doesn’t support something, you either work around it or switch tools.
I’m working differently here. My main tool is Claude Code, and the prototyping layer I use — cauliflower.studio — was itself created with Claude Code. That matters because it means the tool is not closed. When I hit a limit or need a capability that doesn’t exist yet, I can extend the tool during the work, on the fly. The feature set grows with the project.
This is a different mental model than “pick the right tool for the job.” It’s closer to “have a tool that can become the right tool.” In practice it means fewer context switches, full ownership of the output, and no frustration.
The Demo Use Case: First Notice of Loss
FNOL — First Notice of Loss — is the process a policyholder goes through when they need to report a claim. It’s one of the highest-friction touchpoints in insurance: users are often stressed, the information required is detailed, and the flow tends to be long.
It’s also one of the most common demos in insurance software. If you can show a client a polished, intuitive FNOL flow, you’ve demonstrated something they recognize as painful and shown them what better could look like.
That made it the obvious choice for this exercise.
From Mobile to Web in One Step
I had an existing mobile prototype from the previous iteration. The first task was adapting it for a web application — different layout proportions, different navigation patterns, a different relationship between content and screen space.
In cauliflower.studio this meant moving a few elements on the canvas and asking Claude Code to regenerate the layout for a desktop/web context.
Acceptance Criteria as the Specification Language
Once the base layout was ready, I needed to add FNOL-specific pages. Rather than designing each page manually, I provided Claude Code with acceptance criteria — the same kind of ACs a product owner would write for a development team — and let it build the pages from those.
The prompt looked like this:
“I want to use Lychee mockup as base to create FNOL pages. ACs for FNOL pages: 1) Page: What’s your policy number? Subtext: Enter the policy number from your insurance documents. Input: policy number field, e.g. PRD-OP-123123 2) Page: What happened? Section: Incident. Subtext: Describe the incident. Include anything that might help us understand what occurred. Input: textarea with 1000-character limit 3) Page: What kind of incident was it? Pick the category that best describes what happened. Categories: Collision, Fire, Glass breakage, Theft, Accidental damage, Natural disaster, Riot and civil commotion.”
A skill I had previously built into cauliflower.studio picked up the request and added the new pages to the journey automatically. The result was a coherent multi-step FNOL flow, visually consistent with the rest of the prototype, built from a specification rather than from manual design work.
These are not production-grade ACs, they’re prototype criteria, intentionally thin. But they’re real enough that a stakeholder can read them, recognize the intent, and react to what they see on screen. That feedback loop is the point.
Adding the AI Agent Layer
A static form-based FNOL flow is a useful demo. A conversational one is a more interesting demo.
To make the prototype more representative of where this product could go, I added an AI agent layer to the flow. At this stage the agent conversation is AI-generated and not connected to a real backend, it’s illustrative, not functional. But it’s enough to show the interaction model: the agent knows the context, it can guide the user, and it doesn’t require the user to read and fill every field in silence.
This is the part that tends to land hardest in client conversations. A form is familiar. An agent that understands what the user is trying to do and helps them get there is still surprising enough to make a difference.
What This Prototype Is and Isn’t
To be direct: this is not production software. It’s not close to production software. It’s a demonstration of a user journey, built quickly enough to be tested and refined before anyone writes a line of real application code.
What it is: a conversation tool. Something you put in front of a stakeholder and watch them react to. The reactions — what they skip past, what they question, what they ask to change — are more valuable than any requirements document written in advance of seeing the thing.
The Final Prototype
You can see the full FNOL demo walkthrough here:
The author has worked in Guidewire Digital Portal development since 2018.
