I Want to Click It Before I Build It

Give me something I can click

A screenshot can make an interface look convincing. I want to know what happens after I press the button.

Where does it take me? What information do I need before I can continue? Can I go back without losing what I entered? Does the next screen help me finish the thing I came to do?

A clickable prototype gives those questions somewhere to land.

Suppose I am designing an appointment flow. A calendar and a clean booking form might look enough like a finished product to move forward. But clicking through forces a few decisions. Do I select the customer first? Can I create a customer while booking? What happens when the selected time is unavailable?

Those choices affect the interface and eventually the implementation. I would rather encounter them while changing the flow is still easy.

The prototype can use fake data and simulated actions. It needs enough behavior to let me judge the experience. Connecting a database can wait until I understand what the interface is asking that database to support.

Put the feedback where the problem is

Once there is something to inspect, I annotate it.

“Make this cleaner” leaves too much room for interpretation. The agent might reduce the spacing when I meant that the screen asks for too many decisions at once.

An annotation attached to the relevant part of the interface can be specific:

This screen asks me to choose a customer, a service, and a technician before showing availability. Let me see the available times earlier.

Or:

Cancelling this dialog should keep the information I already entered.

Or:

The primary action is hard to find because these three buttons have the same visual weight.

Now there is an observable problem and a change we can discuss.

This also helps me notice when I am expressing a preference without explaining it. If I cannot say what feels wrong, I probably need to spend a little longer looking at the screen before asking the agent to rebuild it.

Annotations make that pause useful. They turn an impression into something another person, or an agent, can act on.

Review the changes before applying them

There is a temptation to turn every comment into an immediate edit.

I want to review the set of changes first. Some annotations describe the same underlying problem. Others conflict. Moving a field might improve one screen while making the next step harder to understand.

Before implementation, I want a short plan that explains what will change and what those changes mean for the flow.

For the appointment example, that might be:

• Show availability before asking for the technician.
• Keep the selected time when the customer opens and closes the customer dialog.
• Explain why a time cannot be selected.
• Leave recurring appointments outside this version.

That is enough to have a useful conversation. I can approve it, correct it, or realize that I am asking for more than this version needs.

The plan also gives the agent a clear assignment. It does not need to fill every unanswered question with another feature.

Approval needs a visible result

“Looks good” is weak approval when all I have seen is a description.

I want to click through the revised prototype and see whether the changes address the annotations. If I asked to preserve the form when a dialog closes, I should be able to try that. If I asked for a clearer primary action, I should be able to find it.

Approval means I have inspected enough of the proposed behavior to say: yes, implement this version.

It does not mean every decision is permanent. Implementation can reveal a technical constraint, and using the finished product can expose something the prototype missed. When that happens, I want to revisit the relevant decision with the new information.

The point is to begin implementation with a direction I have actually examined.

Then let the agent work

Once the prototype and plan are approved, I am much more comfortable giving the coding agent room to implement.

It has a reference for the screens, examples of the interactions, and written decisions about the changes. I have something concrete to review the result against.

The implementation still needs its own checks. A simulated save in a prototype tells me little about persistence, permissions, validation, or what happens when a request fails. Those responsibilities arrive with the working application.

But I am no longer trying to settle the layout, invent the workflow, and verify the backend in the same conversation.

That makes feedback more precise. I can point to a behavior in the approved prototype and explain how the implementation differs.