Your AI Prototype Looks Too Good


Almost daily on LinkedIn or X, someone claims that AI helped them deliver faster and urges you to embrace it or become obsolete. No one wants to be a laggard, so the tech industry has widely adopted AI tools.

This transformation changed the interaction of the product-design-engineering triad:

  • Why should we waste time in meetings, documents, and bike-shedding discussions if we can write a prompt and get a working UI immediately?

  • Why can’t we take the concept of MVP to the extreme, going from prompt to prototype to user feedback?

These questions gained momentum among product and engineering leads, and AI-generated prototypes from Lovable and v0 started to creep into PRDs and team discussions.

As I watched these team interactions unfold, I recalled Bill Buxton’s Sketching User Experiences.

Sketching User Experiences is a book from 2007, which is prehistoric for the tech industry. However, the core idea remains: the process of designing a new product requires tangible experimentation and feedback, which only learning by doing can provide. With that in mind, sketches allow communication between designers, users, and other stakeholders.

Buxton insists on differentiating sketches from prototypes. The main reason for this distinction is that people have a natural tendency to reduce critical feedback when the thing presented to them looks polished. That’s why a sketch favors communication and exploration.

In product design, we often treat prototypes and sketches the same. For instance, paper prototypes would be considered sketches for Buxton, and many examples in the book show elaborate sketches that practitioners might call prototypes.

However, with the introduction of generative AI tools, the distinction began to take on more meaning for me.

AI as UI Designer

Barbara is a product manager. She spent the whole week in product discovery sessions and writing a PRD. She learned to use generative UI tools like Lovable, so she starts with a one-shot prompt by giving the LLM the PRD draft, plus some instructions about how the UI should look.

In 5 minutes, the AI shows a working prototype. It’s magic. The app appears to meet the requirements. There are details to improve, but overall, it looks like a good starting point.

“We should use this as the basis for the MVP!” she thinks. In fact, she learned from many entrepreneurship books, like The Lean Startup, that quantity trumps perfection. “We should ship this and measure the user response.”

So she comes back to the team and shows the PRD and the prototype. Of course, the design team will need to review the prototype, but at least we have a starting point right now. It’s a game-changer.

I’m going to pause the story here.

The main difference between the prototype that Barbara just vibe-coded and what Buxton describes as a sketch is that the sketch is a trigger for exploration, while the way the prototype is presented to the team aims to close a definition.

Even when Barbara reassures everybody that the prototype is just an initial iteration, the medium doesn’t invite others to collaborate. It’s a subtle distinction. You can experiment with the difference yourself (Buxton already did it in 2006): make two versions of the same UI, one that looks polished and finished, the other that looks sketchy and unfinished, and use it to gather feedback.

You may be thinking, “Why does it matter?”

It matters for multiple reasons:

  • Information Architecture: LLMs are good at reproducing patterns.They will reproduce well-known UI patterns that look good at first sight. But they usually don’t have the best information architecture to match user needs. We can argue that it’s just a matter of model quality and having the right context (prompt). But in that case, a high-fidelity prototype will distract discussions from information architecture to visual details.

  • Exploration: The process of exploration and refining is essential to come up with novel ideas. You can explore using prompting and LLMs, too, but the almost finished artifact immediately cuts the exploration short.

  • Design hand-off: When you discourage the flow of ideas between the product-design-engineering triad, communication starts to deteriorate, falling back to the usual design hand-off. (see Lean UX)

  • Communication with stakeholders: Sharing polished prototypes with stakeholders in decision-making is a double-edged sword. If you want to communicate that the solution is “closed” and show progress, they’re great. But if you expect feedback by sharing a half-baked idea that looks polished, be prepared for responses that range from bike-shedding (“Can we change the color to make it more AI-ish?”) to “This is good. Ship it!”

Of course, all of these reasons don’t matter much if your primary goal is to prioritize fast delivery over user experience and creative collaboration.

LLM Prototypes as Sketches

LLMs are really fast. They can map needs in text to common UI patterns. With the right prompting, they can also produce variations that spark new ideas.

So a better alternative is to use the output of LLMs as sketches.

How can you do that?

  • Context matters: Share prototypes produced by LLMs in the context of a design session where every participant is sketching too (either with pen and paper or prompting). If you need a more detailed explanation on how to do that, take a look at the Design Sprint book.

  • Sketchy look: Intentionally reduce the output quality of the prototype. You can ask the LLM to use “Comic Sans” or to add a sketchy effect. The goal is to communicate: “This is an open idea for things to explore.”

  • Problem vs Solution: Think in terms of “challenges.” The famous “How might we…” from design thinking helps to reframe the problem from the user’s point of view without being fixed on a particular implementation.

  • Intention: Make each prototype intentional and extreme. The idea is that by adding constraints, you can actually unlock more creativity.

  • Early feedback: Test the prototype with internal and external users. The most valuable thing about prototyping is to do an early test of ideas. While you can take the notion of continuous delivery to the extreme and create a release to test, I’ve found that testing a prototype has a much better ROI and helps to fix user experience problems faster.

Closing Thoughts

LLMs are a great tool for product managers, designers, and engineers. But when the whole design process is left to the LLM, it quickly erodes team communication and product UX.

As a product leader, pay close attention when this happens. Take into account that switching from prototypes to sketches is a matter of process and intention, not tools.