Nearly everyone who starts with Rork goes through the same phase: you type a prompt, something appears on screen, and you spend the next 20 minutes editing it back toward what you imagined. I did this for the first few weeks before I started paying attention to why the output kept diverging from my intent.
The shift came when I noticed that Rork's AI doesn't just answer "what to build" — it also tries to infer "who's using it," "what operations they'll perform," and "how complex the interaction should be." Once I started feeding those answers into my prompts, the generated output got much closer to usable on the first pass.
Describe User Actions, Not Feature Names
The most common mistake is prompting with feature names rather than user workflows.
❌ What doesn't work:
Create a task management list
✅ What works:
Create a list where users add 3–5 tasks each morning,
check them off as completed, and the checked items disappear.
No priority levels. The goal is to keep it simple.
The difference is that the second prompt answers who uses it, when, and how. Rork uses this context to decide component sizing, tap target dimensions, and interaction complexity. Without it, you get a generic interpretation.
What to Include in Form Prompts
Forms are where prompt quality has the biggest impact on output quality. Including a few specific details dramatically stabilizes what Rork generates.
Essential information:
- Field types and number (text, number, date, select)
- Whether validation is needed
- What happens after submission (navigate back, prepend to a list, etc.)
- The context the form appears in (onboarding flow, settings screen, etc.)
Example prompt:
Create an inventory item form.
Fields: product name (text, required), quantity (integer, min 1),
storage location (text, optional)
On submit, navigate back to the list screen and prepend the new item.
Show validation errors below each field in red.
Written this way, Rork generates validation logic, error display, and post-submit navigation as a complete unit — rather than leaving it to you to wire up afterward.
Always Specify the Empty State for Lists
The most consistently omitted detail in Rork's generated list components is the empty state. Without data, a blank screen looks like a bug.
Create a purchase history list.
Each item: product name, purchase date, amount
Tapping an item navigates to a detail screen.
If there's no history yet, show "No purchases yet" with an icon.
Adding "if there's nothing to show" to any list prompt causes Rork to include an EmptyState component automatically. Specifying it upfront takes two seconds; adding it manually takes considerably longer.
Communicating Visual Priority in Card Layouts
Card components need explicit priority signals. Without them, Rork tends to render all elements at the same visual weight, which makes cards look flat and hard to scan.
Create a recipe card.
- Recipe name at the top, large (this is the most important element)
- Square thumbnail image on the right
- Cook time and difficulty as small badge labels
- "View Recipe" button at the bottom
Phrases like "most important," "large," and "small" directly influence the typographic hierarchy Rork applies. Leaving these out means the font size distribution gets decided by a best guess.
Specify Multiple Related Screens Together
When you build screens one at a time, Rork generates each one without knowledge of the others, so you end up manually connecting the data flow between them.
Specifying connected screens together lets Rork design a consistent data model from the start:
Create two screens for a simple budget tracking app.
Screen 1 (Entry form):
- Amount (number), category (income/expense toggle), note (text, optional)
- "Save" button returns to Screen 2 and prepends the entry
Screen 2 (History list):
- Show this month's net balance in the header
- List entries from newest to oldest
- Plus button in the top right navigates to Screen 1
With the full context provided, Rork handles state management and navigation between screens as a coherent whole. The alternative — building them separately and then adding navigation — almost always requires a refactor.
Constraining What Rork Should Not Change
When you want to adjust only part of a generated UI, vague instructions often cause Rork to change more than intended. A constraint phrase prevents this:
Update the list item style only.
White background, dark gray text, thin colored left border.
Don't change the overall layout or navigation.
"Don't change X" scopes the modification to what you actually want adjusted. This is especially valuable when the navigation or data logic is already working correctly — protecting it explicitly is faster than fixing accidental regressions.
Building Reusable Prompt Templates
If you build similar UI patterns across multiple apps, templating your prompts speeds up the initial generation significantly.
[Category selector template]
Create a category selector for [context].
Options: [A], [B], [C], [D]
After selection: [next action]
Style: horizontally scrollable chips, gray when unselected, brand color fill when selected
Replace the bracketed parts per project. I keep these in a Notion template block and pull them into new projects as a starting point — it cuts the iteration from 3–4 rounds of generation to 1–2 consistently.
The Pattern That Makes the Difference
Rork will generate something from almost any prompt. The question is how much editing it takes to get from that something to what you shipped.
Context — who uses it, when, and how — is the highest-leverage addition to any prompt. Start with one screen you always edit heavily and rewrite its prompt to include the user's workflow. In most cases, you'll notice the difference on the next generation.