You can now prototype the wrong product in an afternoon

The review stops on a screen that already has a customer's name in it. The filters click. A chat box answers back. Someone asks whether engineering can put it live next sprint.

A working version in a day

Megan Chan, writing for Nielsen Norman Group, describes what AI prototyping changed for interfaces with too many states to fake by hand. Filters, dashboards and conversational tools used to get a thin prototype, a few happy paths, and a wait until developers had built the real thing. A team can now put a realistic version in front of users first. She says a designer can produce a working prototype in a day, with believable data and many states, and can test earlier and more often.

A day is long enough to make something that looks decided, and short enough that nobody has sat with the person who has the problem. Building got cheap. The wrong product got cheap in the same sitting.

What shows up when a person can use it

At Ramp, senior product designer Pavan Garidipuri used an AI prototyping tool on the expense-policy editor because a conversation-based edit could not be faked with static screens. In testing, people opened a link loaded with their own sanitised data and used it as they would the product. The team found that the way edits were tracked and shown was confusing. Garidipuri said they could not have found that without a prototype close to the real interface. Concept to demo took three weeks, the changes came from customer feedback, and the work shaped the roadmap for the rest of the year.

Andrew Lucas, also at Ramp, prototyped a conversational expense report the same way. People in the study could type what they actually wanted. The team watched how the agent handled requests nobody had scripted. Chan's point is that those misses show up on a version close to the real product. One happy path keeps them hidden.

Researchers at Purdue built a filter for highway traffic engineers, 27 attributes with nested detail under several of them. Static wireframes drew comments on the look. On an interactive prototype people named specific problems, including how a filter behaved when they applied it. Chan asks for care. It was one project, the team's grasp deepened between the two versions, and she does not offer it as evidence that AI prototyping produces better research. AI cuts the time required to make a prototype that behaves like the product.

The fidelity trap

Chan names the failure mode the fidelity trap. The prototype looks polished, shows real data and clicks all the way through, and someone asks if you can ship it. The polish can persuade a team to stop. An AI-generated screen can look finished while it uses the wrong pattern, muddles the hierarchy or repeats elements that do not earn a place. Leave a gap and the tool fills it. Have someone with real design judgment review it before anyone calls it ready.

Before the prompt, write what a person must be able to do, and which question that answers. A simple prototype is sometimes enough. Full interactivity earns its cost when the question needs it. Then watch someone who has the problem attempt the task, after a short pilot so the test is sound.

1. Write the question, and the behaviour a person must be able to try.
2. Decide the layout, the hierarchy, the empty states and the errors. Then ask the tool to build that.
3. Test with people who do the task, on data you are allowed to use, before anyone asks to ship the screen.
4. When the screen looks finished, slow down and have someone who knows the design review it.

Our AI design sprints workshop takes a team through one live problem to a tested decision, with a real user in reach. The prototype is the cheap part. The test is how you find out whether the cheap thing was the right one.