What is AI prototyping, and what you get at the end
AI prototyping is building a rough, working version of an AI feature so people can try it, usually in hours rather than weeks. At the end you have something clickable, notes on where users got stuck, and a clear decision on whether to keep going.
AI prototyping comes up in a lot of meetings without anyone saying what it involves. Here is what it is, what happens in the session, and what you can show someone afterwards.
It is written for people who already know the idea sounds good on paper and cannot tell whether it works. Heads of digital who have to show their boss something real from the customer journey work. Operations people with one AI feature stuck in scoping.
Nothing about theory here, just what you end up holding at the end.
What AI prototyping actually is
AI prototyping means building a rough, working version of an AI feature so that someone can try to use it. A screen with a text box, a button, and a real answer coming back. Screenshots in a PowerPoint do not count.
The AI builder tools do most of the work for you. A prompt, a model, a simple front end that a non-developer can put together. That is why a business team can do this without waiting for developers. If you can write a decent prompt, you can get a working screen out of it.
The point of building it rough is that you find out what you got wrong while it is still cheap. Most people arrive with the idea written up in a PowerPoint, and once they start building, the slides turn out to be wrong. Usually in small ways. The input the customer actually has is not the one in the slides, and the answer comes back in the wrong tone. We wrote more on that in Build a rough working version of an AI feature instead of writing the business case first.
What you get at the end
A prototyping session runs one evening, in person, and you walk away with four things.
A link that works. Someone else can open it on their laptop and use it without you standing over them.
A short recording or a set of notes from watching two or three people try it. Where they paused. What they typed that you did not expect. The point where they gave up.
A list of what broke. Prompts that returned nonsense, inputs the thing could not handle, answers that sounded confident and were wrong.
A decision. Build it properly, change the idea, or stop. Written down, with the reason.
What you do not get is a finished product. The prototype is not secure, not connected to your core systems, and not ready for a customer. Treating it as nearly done is the main way these things go wrong afterwards.
A normal day without it
An AI idea gets written up. It goes round for comment. Scope grows because everyone adds their bit. Three months later there is a business case, a budget request and still nothing anyone has touched.
Then it gets built, and the first real user does something nobody planned for, and the team spends the next quarter fixing an idea that was never tested.
Building first changes the order. An idea can fall apart in a couple of hours of building, or sit safely in a deck for months. The couple of hours costs you less.
The same logic sits behind design sprints, which run longer and cover the whole customer journey rather than one feature. A large insurer we worked with ran a series of five-day sprints on customer-facing web journeys. Journeys that used to take six months or more were designed, tested with customers in two weeks, and live in four. The client measured completion rates on the new journeys going up 80 percent, and the old drop-off points disappeared.
Fix the journey before you add AI to it
One warning that comes up in almost every session. If the process is broken now, an AI layer makes it fail faster and at greater volume.
A prototype is a good place to notice this. You build the assistant that answers customer questions about turnaround time, and while testing it you realise nobody in the business can say what the turnaround time is. The prototype did not cause that. It just put it in front of you.
So when you sit down to build, be honest about which part you are testing. Are you testing the AI, or the process underneath it? Both are worth knowing. If you mix them up, the demo looks fine and the pilot fails.
If the answer is that the process is the problem, that is a useful result. Cheaper than finding out after procurement.
How to tell whether it worked
Most teams have no baseline, so when the boss asks whether it worked, the honest answer is a shrug.
Before you build anything, write down one number as it stands today. Average turnaround time on the onboarding flow. Percentage of applications that get to submit. Number of calls to the branch about one specific step. One number, measured this week, not estimated.
Then after the prototype test, you have something to compare against. Even a small honest number beats a big vague claim in a steering meeting. Minutes saved per case, times the cases you handle in a day. That is a sentence your boss can follow.
Keep the number somewhere other people can see it. Write it down, because the number needs to still be there when the sponsor moves on.
What to do this week
- Pick one AI idea that is currently stuck in scoping. The smallest one.
- Write down one number that describes how that task performs today, before anything changes.
- Build a rough working version using the AI tool your team already pays for.
- Put it in front of two colleagues who do the task daily. Watch, do not explain.
- Write one page: what broke, what surprised you, and whether you are carrying on.
More on AI prototyping
- Build a rough working version of an AI feature instead of writing the business case first
- Everything on AI prototyping
Questions people ask
How long does AI prototyping take?
A first rough version of one small feature can be built in an evening. Anything that needs real data, security review or a second feature takes longer, and that is normal.
Do you need developers to build an AI prototype?
Not for the first version. Someone who can write decent prompts and use a builder tool can get a working screen in front of a colleague. Developers matter once you decide to keep it.
What is the difference between a prototype and a pilot?
A prototype is thrown away if it fails and nobody is harmed. A pilot runs with real customers, real data and real turnaround times, so it needs sign-off and a baseline number.
What do you actually hand over at the end?
A working link, a short recording of people using it, a list of what broke, and a written decision to build, change or drop it.
On-Off Group trains teams, tests products with real customers, finds where a transformation has stalled and builds what gets it moving, for banks, insurers and enterprises in the Philippines, since 2015. How we help with ai prototyping.
