Prototyping with AI
AI tools can now turn a written description into a clickable, working-looking app in an hour. Used well, that puts a realistic prototype in a shop owner's hands the same day you think of it. Used badly, it produces a demo everyone mistakes for a finished product. This lesson teaches the first and protects you from the second.
By the end you can
- Write the question a prototype must answer before you build anything
- Use any prompt-to-app tool to build a clickable prototype in a day, with realistic fake data
- Test it with five real users on their own devices, and say what it can and can't tell you
- Keep prototypes safe: no real customer data, no secrets, no connection to live systems
- Hand over what you learned, not the code
The everyday picture
A film crew can build a street in a week: shop fronts, a bakery sign, a lamp post, a bus stop. On camera it looks real. Walk through the bakery door and there's nothing behind it but wooden props and a car park. Nobody minds, because the street only has to answer one question: does this scene work?
An AI-made prototype is a film set. The screens look finished and the buttons respond. Behind them there is no real data, no login, no link to the stock system and no plan for a phone with no signal. That's fine as long as everyone knows they are looking at a set, and nobody tries to move into the bakery.
A prototype is a question
A prototype is a model of a product that lets people experience part of it before it exists. Its job is to answer a question, so write the question first. The question decides what you build, who you test with and what you fake.
Questions a prototype answers well:
- Usability. "Can a shop owner find what he owes and reorder last week's list in under a minute, on his own phone?"
- Wording and layout. "Which of two balance screens makes it clear what is due, and when?"
- Desirability, partly. "When owners see this, do they ask to keep it? What do they try to do that it can't?"
- Alignment. "Is this the flow that the team, the vendor and the head of sales all mean when they say 'reorder'?" A clickable prototype settles arguments about words faster than any spec.
Questions it can't answer:
- Feasibility. Whether the back office can supply correct balances every day, or whether the Store app can sync on patchy Wi-Fi. That needs engineers and a spike.
- Lasting behaviour. Whether owners keep ordering without the rep for months. That needs real data over weeks, such as the concierge test in Testing ideas cheaply, and later a pilot.
- Scale and cost. How it behaves with 1,800 shops during a festival rush.
Match the fidelity to the question. A paper sketch answers "are these the right screens?". A clickable mockup answers "can they find it?". A working prototype with realistic fake data answers "does this feel like my shop?". That last kind is where AI tools shine, because realistic, working detail used to be the expensive part.
Quick check
Which question is a good fit for a one-day AI prototype?
Finding and reordering is a usability question that a realistic prototype answers in an afternoon of testing. The back-office question is feasibility, six months is lasting behaviour, and servers are scale. A prototype with fake data can't answer any of those.