How to build a clickable app prototype with AI

A working app is expensive to change. A fake app is cheap to change. That is why the best first version of many ideas is not software at all: it is a clickable prototype that looks real enough for someone to try.

You can build one with an AI assistant even if you have never designed a screen or written code. The goal is not to impress anyone. The goal is to discover what is confusing before a developer turns the confusion into real software.

What you are building

A clickable prototype is a small set of screens that behave like an app from the user's point of view. Buttons move to the next screen. Forms can appear filled in. A success message can show up. Nothing important happens behind the scenes.

For example, imagine an app that helps a dog owner book a local walker. A prototype might have only five screens:

1. A home screen.
2. A list of nearby walkers.
3. A walker's profile.
4. A booking screen.
5. A booking confirmation.

There is no real map, no payment system and no database. The names and prices can be made up. What you are testing is whether a person understands what to do next.

Step 1: choose one thing the user should be able to finish

Do not prototype the whole business. Pick one journey with a clear beginning and end.

Good first journeys:

• Book an appointment.
• Upload a document and see a result.
• Choose a product and request a quote.
• Create a simple meal plan.
• Find a service provider and send a request.

Write it as one sentence:

A new user can choose a dog walker for Saturday morning and reach a booking confirmation.

That sentence is your boundary. If a screen is not necessary to complete it, leave the screen out.

Step 2: write the screens as a plain list

Before asking AI to design anything, describe what must appear on each screen.

SCREEN 1: Home
- Headline: Find a trusted dog walker nearby
- Button: Find a walker
- No account required yet

SCREEN 2: Walker list
- Three walkers
- Photo, first name, rating, price per walk
- Button on each: View profile

SCREEN 3: Walker profile
- Larger photo
- Short introduction
- Price
- Available Saturday morning
- Button: Book this walker

SCREEN 4: Booking
- Saturday selected
- 10:00 selected
- Dog name field
- Button: Confirm booking

SCREEN 5: Confirmation
- Booking confirmed
- Walker name
- Saturday at 10:00
- Button: Back to home

This is enough information for an AI design or coding assistant to make a first pass.

Step 3: ask AI for the smallest possible prototype

Give the screen list to the AI assistant and ask for something deliberately simple.

Build a simple clickable mobile prototype from these five screens. Use realistic placeholder content. Every button needed for the journey should work. Do not add login, payments, a database, notifications or any feature I did not ask for. I only want to test the flow.

If you are using an AI coding assistant, ask it to make the prototype as a single small web project you can open in a browser. If you are using an AI-enabled design tool, ask for linked screens rather than polished branding.

The important phrase is do not add. AI assistants are eager to be helpful. Helpful extras are how a one-hour prototype becomes a three-day project.

Step 4: make the fake data believable

Bad placeholder data makes people behave differently. A screen full of "Lorem ipsum" does not feel like a real service.

Use believable names, prices and descriptions:

• Anna — 4.9 stars — €14 per walk.
• Mark — 4.7 stars — €12 per walk.
• Sofia — 5.0 stars — €17 per walk.

Give one option an obvious advantage and another an obvious drawback. Real products contain trade-offs. If every choice looks identical, you learn nothing about what people care about.

Step 5: use it yourself without explaining it

Open the prototype from the beginning and pretend you have never seen it.

Try to complete the one journey. Do not excuse confusing parts because you know what they mean. Write down every moment where you pause.

Check these five things:

• Can you tell what the product does within five seconds?
• Is there one obvious next action on each screen?
• Do button labels describe what will happen?
• Can you go forward without needing information the screen never gave you?
• Does the final screen clearly confirm that the task is complete?

Fix only those problems. Do not start choosing fonts or debating shades of blue.

Step 6: put it in front of three real people

Find three people who resemble the intended user. Hand them the prototype and give them the goal, not the instructions.

You want someone to walk your dog this Saturday morning. Show me how you would arrange that here.

Then stop talking.

Do not point at buttons. Do not explain what a screen means. Do not say "normally this would..." every time something is fake. Watch where they hesitate, what they tap first and what they expect to happen.

The most useful notes look like this:

Step 7: give the observations back to AI

Do not tell the AI "make it better". Give it the evidence.

Three people tested the prototype.

Observed problems:
1. Two tapped the walker photo instead of "View profile".
2. All three asked whether the price was per hour or per walk.
3. One wanted to see reviews before booking.

Change only what is needed to address these observations.
Do not add new features.

Then test the changed version again.

This is a much better use of AI than asking it to invent the product for you. The people provide the evidence. AI helps you turn the evidence into another version quickly.

Step 8: decide whether the prototype deserves real software

After two or three rounds, ask what you learned.

Move toward a real build when:

• People understand the main journey without help.
• The same problems stop appearing in every test.
• The result at the end is something the user actually wants.
• You can describe the first version without saying "and also".
• You have evidence that at least some people would use or pay for it.

If people are confused about the basic promise, keep changing the prototype. Code will not make an unclear idea clearer.

What not to build into a prototype

Leave these fake until you have a specific reason to make them real:

• Login. Pretend the user is already signed in.
• Payments. Show a payment screen and a success state, but do not charge anything.
• AI features. Use a prepared example output if you are testing whether the output is useful.
• Search. Show three believable results.
• Notifications. Show what the message would say.
• Databases. Use fixed sample content.

Those systems matter later. At prototype stage they mostly create work that teaches you nothing about whether the product makes sense.

The handoff when you are ready

Your tested prototype is much more useful to a developer than a long feature list. It shows the screens, the order, the wording and the decisions users already understood.

Pair it with the brief from how to explain your app idea to a developer: who it is for, what happens today, what goes in, what comes out and which rules cannot break.

If you have not yet tested whether anyone cares about the problem itself, do that before polishing the prototype. How to validate an app idea gives you the cheaper tests that should come first.