If you've generated screens with Rork AI, you've hit the moment where the UI just won't match what you had in mind. You retry, and retry again, and eventually settle for a compromise layout that you have to hand-tune anyway. When that loop repeats too often, the point of using generative AI starts to feel thin.
I was stuck in that same loop for a while. What changed things for me was shifting my prompts from "intent-first" to "constraint-first." The moment I rearranged that ordering, the accuracy of the generated output visibly changed. This article covers seven prompt techniques I use daily with Rork AI, each illustrated as a bad-example / good-example pair.
1. Write constraints before "what kind of screen"
The first thing to communicate is not the purpose of the screen but the constraints. Rork AI has high degrees of freedom, so if you don't give constraints upfront, it will make its own decisions and add elements you didn't ask for.
❌ "Make a product detail screen. Needs a photo, price, and buy button."
✅ "A product detail screen that fits in the first viewport without scrolling.
Card structure from top: hero image (40% of screen height),
title, price, one-line description, buy button.
Do not add anything beyond these elements."
Written the second way, the AI won't add elements on its own. To shut down the "well, let me throw in a reviews section too" and "related products would be helpful, right?" kind of unwanted helpfulness, you need an explicit boundary.
2. Always specify units for fixed values
When giving color, size, or spacing directions, always include units. Vague words like "large" or "generous margins" invite Rork AI to substitute default values on your behalf.
❌ "Make the button large."
✅ "Button height 52px, padding 12 vertical / 20 horizontal,
corner radius 12px, font size 16px."
When you communicate in numbers, the amount of manual fine-tuning afterward drops dramatically. I keep a scratchpad of my design system's "button size standard" and paste it straight into the prompt.
3. Reference well-known patterns by name
Rork AI recognizes famous design patterns by name. Naming a specific app or pattern is more accurate than explaining from zero.
✅ "Instagram-feed-style card layout. Avatar and username at the top,
image in the middle, action icons (heart, comment, share, save) at the bottom."
✅ "iOS Settings app-style section list.
Gray-background section headers grouping white-background rows."
Think of it as shared references. It communicates intent much more accurately than listing elements from scratch. But don't overdo "make it look like X" — saying it too strongly gets you into uncomfortable territory rights-wise. Keep it to structural pattern references only.
4. Explicitly state what should NOT be included
A good prompt communicates not just what to include but also what NOT to include. AI tends to want to fill whitespace, and explicit negation is the only reliable way to prevent unintended additions.
✅ "Make a loading screen.
Center of screen: a rotating spinner and the text 'Loading' only.
Do not include a logo, progress bar, or cancel button."
The more complex the screen, the longer I make the "do not include" list. This is the only reliable way to get the AI to honor subtractive design.
5. Describe responsive behavior concretely
Writing "make it responsive" alone doesn't tell the AI what to do at each screen size. Specify breakpoints and behavior per screen.
❌ "Make a responsive screen."
✅ "Two-column layout.
- Screen width 768px and above: left column 60% / right column 40%.
- Screen width below 768px: collapse to one column stacked vertically,
right column comes below the left."
For mobile apps specifically, I also use "landscape vs. portrait" behavior directives frequently. If you claim tablet support but leave it entirely up to the AI, the iPad view tends to fall apart.
6. Describe interactions as three states: before / during / after
For buttons, swipes, long-press, and similar interactions, breaking the state transition into three parts gets the AI to implement them accurately.
✅ "Buy button interaction:
- Before (normal): blue background, white text 'Purchase'.
- During (tap active): scale 0.95, opacity 0.8.
- After (payment complete): green background, white text '✓ Done',
modal closes after 1.5 seconds."
Written this way, you get consistent code that includes haptic feedback, transition duration, and post-completion navigation. Don't say "make the tap feel nice" — concretize each phase.
7. Include a self-check list in the prompt
The last one is about post-generation, but you can build it into the prompt itself. Instruct the AI with "after running this prompt, verify the result against these points and correct any issues." Sometimes it will fix its own inconsistencies.
✅ "After executing this prompt, verify and correct for:
- Every text is 16px or larger.
- Every tappable element is 44x44 or larger.
- Contrast ratio meets WCAG AA (4.5:1) or better."
This doesn't work on every generation, but my empirical hit rate for accessibility-related self-corrections is roughly 70%. Accessibility deficits in AI-generated UI are notoriously hard to catch in real-device testing, so nailing it down at the prompt stage is worthwhile.
A combined template
Here's the template I keep around, combining all seven above.
[Purpose] ...
[Constraints (most important)] ...
[Do NOT include] ...
[Fixed values] colors, sizes, spacing with units
[Pattern reference] "X-style" (structure only)
[Responsive] behavior per breakpoint
[Interaction] before / during / after states
[Verification] self-check against accessibility points
Using this template, Rork AI's output moves from "80% usable" to "nearly drop-in." It's the single largest quality lever I've found.
Iterating when the first pass still misses
Even with a tight prompt, about 1 in 4 generations still misses in some detail. Rather than rewriting the whole prompt, I've found it more effective to follow up with a minimal delta prompt like: "Keep everything else the same. Change only the buy button: use height 56px, corner radius 16px." Rork AI handles these incremental adjustments much more accurately than full regenerations, and the iteration cycle stays fast.
Another trick: when the generated layout has structural issues (wrong hierarchy, wrong spacing), describe the fix in terms of parent-child relationships, not pixel positions. "Wrap the title and price in a shared container with 8px gap" generates better than "move the price 8px closer to the title." The first gives the AI a semantic mental model; the second is instructable but fragile.
Common mistakes I keep seeing
Over the past few months I've reviewed a lot of Rork prompts from other developers. The recurring mistakes are remarkably consistent, and they all fall into three patterns.
Mixing design language midway. A prompt starts with "iOS-style settings" but partway through says "with a Material Design FAB in the bottom right." The AI tries to honor both and produces a chimera. Pick one design language per screen and stick to it.
Using adjectives as load-bearing instructions. Words like "modern," "clean," "professional," "playful" are decorative, not operational. The AI interprets them arbitrarily. If you mean "no drop shadows, no gradients, no rounded corners above 4px," say that. If you mean "use a serif font and generous line-height," say that. Adjectives are fine as flavor, but they can't carry the specification.
Skipping empty-state and error-state prompts. Most prompts describe the happy path only. The AI then either improvises empty states badly or omits them entirely. I now treat "empty state appearance" and "error state appearance" as mandatory fields alongside the main layout. The difference in shipped apps is night and day.
Try this first
Don't try to apply all seven at once. Start with just "1. write constraints first" and "4. explicitly list what not to include." These two alone roughly double the perceived accuracy of the output. Add the other techniques as your prompts grow. That's the order that let me absorb them naturally, and I think it'll be the gentlest entry point for anyone reading this.