A headline looks right until the browser makes it three lines. A menu feels simple until you try to use it with one thumb. A beautiful form becomes a different proposition when the first thing you enter is wrong.
These moments are useful. They put an idea in contact with the conditions it has to survive. That is why I like designing against a working build: it gives me something specific to question, instead of asking everyone to imagine how a finished screen might behave.
AI makes an early implementation easier to attempt. But getting something into a browser is only the beginning. The value is in the decisions that become possible once it is there.
Build the question first
An early build should answer a question. Can someone compare these two plans without opening a second page? Does the navigation make sense on a small screen? Is this interaction helpful enough to earn the extra step?
Consider a booking flow. The uncertainty might be whether people need to choose a service before seeing availability. Build those two routes with sample appointments. Let someone try them. You can learn about the order of decisions before you have a calendar integration, payment system, or beautifully resolved confirmation email.
That is a useful brief for AI, too. Describe the task, the existing components, the states to include, and the question the prototype should help answer. A focused implementation gives you something you can review closely. A whole product generated in one pass gives you many more decisions to untangle.
Put the content under pressure
Once the main route works, make the content inconvenient. Use a long name. Remove the image. Add enough results that the page has to scroll. Replace the neat two-line description with the copy the business actually needs to say.
Then use the interface in ways the original composition cannot show. Move through it with a keyboard. Increase the text size. Narrow the viewport. For ordinary vertically scrolling content, W3C’s reflow guidance sets a useful reference: content should work at an equivalent width of 320 CSS pixels without losing information or functionality or requiring scrolling in both directions, with exceptions for content that needs a two-dimensional layout.
Those constraints expose design decisions. A card that only works with a short title needs a more resilient hierarchy. A sticky bar that covers the action needs a different position. The browser is giving you material to work with.
Make room for taste
A functional build can still feel anonymous. The spacing may be consistent while the page has no rhythm. Every element may look equally important. The animation may work perfectly and make the task feel slower.
This is where a designer needs to look beyond whether the implementation follows instructions. What deserves attention first? Where should the page feel quiet? Which detail belongs to this brand, and which one arrived because it was easy to generate?
I would rather spend the time saved on setup refining those decisions than fill the page with more sections. Try a quieter transition. Remove the second accent color. Make the important sentence shorter. Judge each change in the context of the whole experience.
Keep the loop small
My preferred loop is simple: make one part tangible, inspect it, change it, and look again. Keep the next step small enough that you can tell whether it helped. Keep a record of what is simulated, so a convincing prototype does not quietly become a promise about finished functionality.
There is still room for sketches, layouts, and time away from the screen. Sometimes a few pencil marks are the quickest way to find the structure. The point is to choose the medium that can resolve the uncertainty in front of you.
A working build earns its place when it sharpens the next decision. It lets the design meet real content, real dimensions, and real behavior while there is still time to change your mind.
