How to test a prototype built with AI: five people, one day

A classic prototype is a set of screens linked by hotspots. Only the path the designer prepared works, and a click anywhere else does nothing. A prototype from Lovable, v0, Bolt, Replit, Cursor or Claude Code is a real app: forms submit, pages have addresses, data gets saved.

For testing, that means three things:

• You measure real behaviour. People can take any path, including the one you did not expect. You see where they actually go, not just whether they found a prepared hotspot.
• Success can be detected automatically. When a task ends at /thank-you or on a button click, the tool records that it worked and times it.
• A fix takes minutes. Whatever the test finds, you fix with AI the same day and run another round. Testing in small rounds has never been cheaper.

There is a trap too: an AI prototype looks finished. That makes it tempting to skip the question of whether people can find their way around, because it “looks like a normal app”.

1. A public address. Lovable, v0, Bolt and Replit publish a prototype with one button. From Cursor or Claude Code, deploy it to Vercel or Netlify. People must not need your computer or access to the editor.
2. A working main path. Go through the task yourself from start to finish. If something breaks on the way, the test will only tell you that it is broken.
3. Test data. If the prototype asks for a login or a payment, prepare a test account or turn off the payment gateway. Participants should not enter a real card.
4. One question. Write down what you want to learn. Not “is it good”, but “can people sign up without help?” or “do they get what the app does from the home page?”.

An unmoderated testing tool needs a small script in the prototype. It shows the participant a panel with the task, records the path they take and detects when they complete it. With Tack it is one line:

<script src="https://trytack.io/r/v1.js" data-site="pk_…" async></script>

You do not have to add it by hand. Tell Lovable, v0 or Claude Code “Add this script to the head of every page” and paste it. Then click Verify installation in Tack to see that it loads.

A good task is a short scenario with a goal, not directions on where to click. Instead of “Click Pricing and choose the Pro plan”, write “You want to use the app with your colleagues. Find out what it would cost per month”. People then search their own way and you see whether they find it (Nielsen Norman Group).

For each task, decide how you will know it is done. Tack gives you three options:

• A page address, such as reaching /thank-you.
• A click on an element, such as the button of the chosen plan.
• A custom event the app sends, such as window.tack.track('signup_done') after a successful sign-up. AI will add that line to the code for you too.

One to three tasks are enough. The templates ask after each one how hard it was (the SEQ metric), and at the end you can add an overall usability rating (UX-Lite). The quickest start is a template with the tasks, rules and questions ready.

To find usability problems, about five people per round are enough. According to Nielsen Norman Group they uncover around 85% of the problems a larger sample would hit (NN/g). Three small rounds with fixes in between give you more than one big one. The article How many people you need for a usability test goes into detail.

Where to find people:

• Existing customers or people on your waitlist.
• A community where your audience spends time: Slack, Discord, LinkedIn, a forum.
• Friends of friends who match your audience. Not colleagues from your team.

People open the link in their own browser, on a phone or a laptop, whenever it suits them. You do not have to book calls or watch anything live.

Results come in as people finish. For each task you see:

• Success rate: how many people made it and how many gave up.
• Time: how long it took them.
• Difficulty: how hard it felt, on a scale of 1 to 7.
• Paths and heatmaps: where people went and where they clicked, including places that do nothing.

After five completed sessions, Tack writes up recommended improvements on its own: what gets in people’s way most, what to change and what they said about it. One click copies it as a brief for the AI you build the prototype with. Fix it and send the link to the next five people.

• Testing with colleagues. People who know the product no longer read it. They find different problems than a new customer does.
• Explaining the prototype first. What people do not understand on their own, customers will not either. Keep the intro short and general.
• Asking whether they like it. The answer is nearly always yes and tells you nothing. Give people a task and watch whether they manage it.
• Too many tasks. After fifteen minutes people speed up and answer superficially. Three tasks and five minutes is a sensible ceiling.
• Fixing everything at once. Start with what stopped the most people. Then test again, because a fix can create a new problem.