Making Product Decisions with Working Prototypes

The problem with reviewing static screens

Static design files are useful, but they can hide the questions that matter most: how a page responds, what happens after a click, how branded states vary, and whether a flow still makes sense when real content is present.

Those questions often surfaced after a direction had already gathered momentum. I wanted to bring them into the conversation earlier.

Building the product, not a presentation of it

I used Claude to create a working version of a white-label loyalty site in three days. It included responsive layouts, reusable components, branded states, and real interactions.

The goal was not production code. It was a more honest way to review the product. Stakeholders could use the experience instead of imagining the gaps between screens.

How the workflow changed

The prototype made feedback more specific. A client could react to how its brand appeared in context. Product could compare approaches using the same content and interaction model. Engineering could see the intended behavior and identify constraints before a formal handoff.

I now use this approach when interaction, responsiveness, or configuration is central to the decision. Simpler work still benefits from sketches and static design. The tool should match the question.

Establishing responsible practices

I have also led work on standards and operating practices for AI-assisted product design. That includes being clear about what a prototype is for, reviewing generated output rather than treating it as authoritative, protecting sensitive information, and separating validated product direction from production-ready implementation.

What I learned

AI-assisted prototyping does not remove the need for engineering or design judgment. It changes the order of the conversation. Teams can examine a working direction earlier, discard weak ideas at lower cost, and begin implementation with fewer unanswered questions.