Claude, ChatGPT or Gemini · Practical walkthrough

Turn a process brief into a clickable prototype with AI

Someone describes a new request process in a meeting and everyone nods. Ten minutes with a clickable mock-up shows the three cases nobody mentioned, as long as its Approve button doesn't pretend to approve anything.

Task by Task5 min read

What you'll make

a one-file clickable prototype of a process, with every rule’s route working on screen and any save, send or approve step clearly labelled as simulated.

What you'll need

the process rules written down, including what happens when information is missing or a request is refused, and an AI chat that can build a web page: Claude (opens it as an artifact beside the chat), ChatGPT (ask for an HTML file, download it and open it in your browser) or Gemini (open gemini.google.com, then Canvas below the text box). Use made-up data. Allow about 30 minutes.

Example result. A complete £500 request shows “Manager review (simulated). Nothing was saved.” At £501 it shows “Budget-owner review (simulated). Nothing was saved.”

1. Ask for a state table before the build

List the states, the actions that move between them and the rule behind each move. Then ask for the table first:

From these process rules, list every state, the action that leaves it,
the next state and the rule that allows it: [rules]. Include what happens
when information is missing, when a request is refused and at each
threshold. Mark anything the rules don't settle as a question. Don't
build anything yet.

[rules] is your process, pasted with a short ID for each rule.

Why this works: a table is much quicker to check than a set of attractive screens. Missing paths, such as “what if the date is blank?”, show up as missing rows.

What you should see: a table with a row for every route, including returns and refusals, and a short list of open questions.

2. Build it, with simulated actions labelled

Once the table is right, ask for the prototype:

Build a small clickable prototype from that table. Return one HTML file
I can open in a browser. Use made-up data. The buttons should really
change what's on screen, but label every save, send or approval as
"Simulated: nothing was saved". No network calls, accounts or
tracking. Show the rule ID behind each result. Then explain in plain
words what works, what's simulated and what a real system would need.

Why this works: a button labelled Save implies a real record. Saying “simulated” on screen stops a demo from being mistaken for a working system by the next person who sees it.

What you should see: a page that opens in your browser and moves between states as you click, with the simulation label on every final step.

3. Click through the awkward cases

Test the routes the table says should differ: exactly at a threshold, just above it, a missing field and a refusal. Use the keyboard as well as the mouse. A button that does nothing hasn’t shown the workflow; one that claims a real approval has shown too much.

Why this works: most prototype mistakes sit at the edges: the threshold that goes the wrong way, or the blank field that’s accepted.

What you should see: each case lands on the state the table predicts, and no screen claims a real save or approval.

Check the result

Every row of the state table can be reached by clicking.
The threshold case and the one just above it go to different routes.
A missing required field returns to the requester instead of moving on.
Every final action says it’s simulated; nothing claims a real save, send or authorisation.

The usual failure: the prototype ends with a cheerful a real approval and save. It looks finished, and it tells the reader something that never happened. Spot it by reading the last screen of each route. Send it back:

For [case], the prototype shows [wrong state or message]. Rule [ID]
says [what should happen], and nothing is saved in this prototype.
Fix that transition and its label. Keep the layout and other rules as
they are. Then rerun that case and show me the final screen text.

Worked example: a purchase-request prototype

Fictional example. A team sketched a request process before asking IT for a real form:

R1 Owner and needed-by date are required.
R2 Missing details go back to the requester.
R3 Up to £500: manager review. The manager can reject.
R4 Over £500: budget-owner review.

The first build looked tidy, but submitting a complete £500 request ended on:

Weak: “Request approved and saved ✓ — your manager has been notified.”

Three claims were invented. Nothing approved it, nothing saved it and nobody was notified. The repair prompt, with “a complete £500 request”, the false final message and “R3 says manager review, and the manager can reject”, changed the ending to “Manager review (simulated). Nothing was saved.”
The boundary went the right way. £500 went to manager review and £501 to the budget owner, matching R3 and R4. Testing only £200 and £2,000 would have missed a wrong “less than” in the code.
The blank date returned. Clearing the date sent the request back to the requester under R2, the row most teams forget.

Use your own prototype to compare a complete £500 request with a £501 request. Keep the rule table beside the browser while you test.

Go deeper

Keep the real system's requirements separate

Sign-in, permissions, where records are stored and who gets notified all need their own design, whatever the prototype shows. Take the prototype to the system owner as a picture of the flow, not as a build. The workplace AI workflow guide covers what to ask.

Test the edges like a form

Exactly at the threshold, just above it, a blank required field and an invalid date: these four cases can expose logic slips. The form validation guide shows how to write them as a short test list you can rerun after every change.

Keep a short review record

Note the file version, the rules it was built from, the cases you clicked and the open questions. A positive reaction in a meeting is useful feedback, not evidence that the process is ready.