Your app works. Every feature does its job, but the whole thing still looks like what it is: a default the agent generated, generic type, flat gray boxes, no point of view. Making it production-grade starts at the surface, with how it looks and feels, before you make it faster and more accessible. This chapter gets you to hand your agent a real design direction, so the screens look like a product you chose to build, not a scaffold nobody styled.
10.2.1Sketch the screens first
The mistake is asking your agent to design and build a screen in one shot: you get whatever it invents, and it invents the generic. Decide the shape yourself first. A wireframe is a rough sketch of a screen, plain boxes for where things go, no color and no polish, just what sits where and how big.
Draw it on paper or type it as labeled boxes. Name the boxes top to bottom and mark which one dominates:
Hand that over and the agent builds your layout, not its best guess at one.
10.2.2One clear action per screen
Every screen has one thing you most want the user to do: add the expense, confirm the payment, start the trial. That is its primary action, and it should be the loudest element on the screen, one button styled stronger than anything near it. Secondary actions stay quiet, and anything that competes with it gets demoted or cut.
Rule of thumb: if you cannot point at the one button you most want tapped within a second of seeing a screen, that screen has no primary action yet. Fix that before you touch colors.
10.2.3Consistency, hierarchy, and feedback carry the polish
What separates a professional interface from an amateur one is three habits your agent skips unless you name them:
- Consistency: the same spacing, colors, and buttons on every screen, so the app reads as one thing, not ten. Reuse styles, never reinvent per page.
- Hierarchy: size, weight, and contrast that make the important thing look important, so the eye lands on the primary action first.
- Feedback: every action visibly responds. A tapped button shows it is working, a saved form confirms, a failure says what went wrong.
Put these three in your instructions and hold the agent to them.
10.2.4Show people their own numbers
You are about to build a screen full of data for yourself. Your users want a much smaller version of the same thing, about their own account, and almost nobody gives it to them.
Show them what they are quietly wondering: how much they have used, what it is costing, what happened to the thing they submitted, when it last ran, whether it worked. Every one of those answers is a support message you never receive.
Reach for a chart only where the shape says more than the number. Usage over the month is a chart, because the trend is the point. Their current plan is a number, and putting it on a graph makes it harder to read, not easier.
Rule of thumb: if a number would make a user calmer, show it. If it would only make you look busy, leave it out.
10.2.5Hand the agent a design direction, not "make it nice"
"Make it nice" gives the agent no target, so it hands back the safe average: another template. Give it a design direction instead: a named style, a few references you admire, and hard constraints. A reference is a real product whose feel you want, or a design language like Material Design your agent already knows in depth. Write it once as a short design brief and reuse it on every screen, because one brief everywhere is what makes ten screens feel like one app.
This prompt has your agent draft that brief and lay out your screens before it styles anything:
Do this now: paste the prompt, describe your app and the feel you want, and have your agent draft the design brief and screen sketches. Approve those before it writes a line of styling.
