Writing Prompts for Complex Screens in Rork Max

Generating simple screens in Rork Max is easy. Complex screens — dashboards with real structure, forms with validation, filterable lists with proper state management — are a different story. The quality of what you get depends heavily on how the prompt is written.

After building a lot of screens this way, the patterns that consistently produce usable output have become clear. Here's what actually works.

The Prompt That Doesn't Work

Start with what goes wrong. A typical underspecified prompt:

Create a dashboard screen with a sales chart and recent orders list.

What you get back: a sales chart placeholder with no data, a hardcoded list with three items, a layout too simple to use in production.

The problem isn't that Rork Max doesn't understand the request — it's that the prompt leaves every quality decision undefined, so it defaults to the simplest possible interpretation.

Four Elements of an Effective Prompt

1. Role and Context

Open with what the app is and what this screen does:

You are building an admin dashboard for an e-commerce platform similar to Shopify.
This screen is the "Today's Summary" view that store owners check every morning.

2. Data Structure

Passing the TypeScript interface is the single most effective thing you can do. It tells Rork Max exactly what data exists and how it's shaped.

// Use this data structure for the implementation
interface DashboardData {
  todayRevenue: number;
  todayOrders: number;
  pendingOrders: number;
  recentOrders: {
    id: string;
    customerName: string;
    amount: number;
    status: 'pending' | 'processing' | 'shipped' | 'delivered';
    createdAt: string;
  }[];
  revenueByHour: {
    hour: number;
    revenue: number;
  }[];
}

3. UI Component Spec

List the concrete UI elements you want:

Implement the following UI elements:
- Three summary cards at the top (today's revenue, order count, pending count)
- Hourly revenue line chart in the middle (using recharts)
- Five most recent orders below (with status-colored badges)
- Pull-to-refresh support
- Skeleton UI while loading

4. Quality Requirements

State explicitly what "done" looks like:

Quality requirements:
- TypeScript with types on all props and state
- Handle error state and empty state
- iOS/Android compatible styling
- Use StyleSheet, no inline styles

A Complete Prompt Example

Combining all four elements:

Build a React Native dashboard screen for an e-commerce store admin app.

## Context
Store owners use this screen every morning to review the day's performance.
Prioritize clarity — key metrics should be visible at a glance.

## Data Types
interface DashboardData {
  todayRevenue: number;        // e.g. 1285.00
  yesterdayRevenue: number;    // for day-over-day comparison
  todayOrders: number;
  pendingOrders: number;
  recentOrders: Array<{
    id: string;
    customerName: string;
    amount: number;
    status: 'pending' | 'processing' | 'shipped' | 'delivered';
    createdAt: string;
  }>;
}

## UI Components
1. Header: today's date with a brief greeting
2. Summary section (three horizontal cards):
   - Today's revenue (with day-over-day arrow indicator)
   - Today's order count
   - Pending orders (red badge)
3. Recent orders list (5 items):
   - Status badge with color coding (pending=yellow, processing=blue, shipped=green, delivered=gray)
   - Amount and customer name
4. "View all orders" button at the bottom

## Quality Requirements
- Full TypeScript, types everywhere
- ActivityIndicator for loading state
- Empty state UI when no orders exist
- StyleSheet only, no inline styles
- accessibilityLabel on primary interactive elements

## Mock Data
Include sample data inside the component so it's immediately runnable.

A prompt at this level produces a first draft that's genuinely close to production-ready.

Writing Effective Iteration Prompts

The first generation is rarely final. How you write follow-up prompts matters too.

Vague iteration (doesn't work well):

Make it look more polished

Specific iteration (works well):

Make these specific changes:
1. Increase card border radius from 8 to 12
2. Replace the up/down arrow with Ionicons (arrow-up/arrow-down) from react-native-vector-icons
3. Increase status badge font size from 10 to 11
4. Replace ActivityIndicator with skeleton placeholders that match each card's height (gray background, same dimensions)

Numbered lists of specific changes get applied cleanly. Subjective feedback like "more polished" leaves Rork Max guessing.

Finding the Right Prompt Length

Longer prompts aren't always better. From experience:

Under 200 characters almost always produces an underbuilt result. The 400–800 character range is the sweet spot — specific enough to guide quality, not so verbose that the output becomes bloated. Over 1,000 characters sometimes makes Rork Max too literal, generating overly rigid code that's harder to extend.

TypeScript interface definitions are an exception to the length concern — they add characters but provide the most information per token.

The Underlying Principle

Think of the prompt as a spec document, not a request. The more clearly you describe the shape of what you want — data, components, constraints — the less time you spend on revisions. Writing a careful prompt takes five extra minutes; recovering from a vague one can take an hour of back-and-forth.

That shift in perspective — treating prompt writing as part of the design process rather than a shortcut around it — is what tends to separate developers who get great results from Rork Max from those who find it frustrating.