How I AI: Data-Driven Prototyping and Structured Midjourney Prompts for Elite Results with Ravi Mehta

Relying on a simple vibe to generate a prototype often produces mediocre results that don't quite fit the product you're trying to build. In this episode of How I AI, Ravi Mehta, former chief product officer at Tinder and a product leader at Facebook and TripAdvisor, demonstrates a more structured approach. He separates the data model from the interface generation, a technique that produces dramatically better, more flexible prototypes.

A broad prompt can produce a prototype quickly, but the speed hides significant flaws. In Ravi's first attempt, a tool generated a trip-planning app for Paris that featured a hotel in French Polynesia, a broken image link for a Seine River cruise, and a poorly cropped photo of the Eiffel Tower.

Ravi's solution is to reduce the number of decisions the model has to make at once. He first defines the data structure and populates it with realistic content and media, then asks the tool to build an interface around that specific input.

While design systems and UX descriptions still matter, Ravi begins with a JSON file that makes the entities, fields, and relationships explicit, mirroring how an engineering team would codify a feature before building it.

He applies the same principle of structured inputs to image generation, using a repeatable framework for subject, setting, and style instead of relying on a few broad aesthetic words.

Prototyping from a data model, not a vibe

Ravi treats the data schema as a critical early product artifact. He notes that when an engineering team receives a spec, one of their first steps is to define the data schema to make ambiguous requirements concrete. Applying this discipline to prototyping forces the team to decide what information the interface must display before the model has to invent both content and layout simultaneously.

Giving the prototyping tool a defined data model separates content decisions from interface exploration. The model can focus on presenting the supplied fields, while the team can change the sample data without redesigning the entire flow.

Why a broad prototype prompt breaks down

A typical "vibe prototyping" workflow often starts with a simple prompt. To explore a multiplayer trip-planning feature reminiscent of his work at TripAdvisor, Ravi used Reforge Build, a prototyping tool for product teams, to generate a website from this:

Make a website for planning a Paris trip with multiple people, include some activities, hotels and restaurants, over three days, add user profiles and let people comment on things. Make it look nice.

If I sent a prompt that broad to a human designer, I wouldn't get a mockup back; I'd get a calendar invitation to discuss the project. The model, however, generated a starting point immediately, but its choices required significant review and correction.

Even though Reforge Build asked clarifying questions, the tool was still being asked to handle the UX design, data structure, content, and code architecture all in one pass. This forced the model to make choices across multiple domains, resulting in a prototype with details Ravi would not have selected.

The first version arrived quickly, but its flaws were obvious: one hotel image showed French Polynesia rather than Paris, and a link to an image of a Seine River cruise was broken.

Step 1: Generate structured JSON with selected media

Instead of starting in the prototyping tool, Ravi first asks Claude to generate a JSON dataset from a detailed, natural-language schema. He prefers Claude for this workflow because he finds it produces data that feels human and authentic, which was especially important for generating realistic conversations between travelers in the sample data.

Here is the prompt Ravi used in Claude to generate and populate the data schema:

Using JSON, generate a sample itinerary that I can use to prototype a shared trip itinerary feature. The destination is Paris. The Itineration include an itinerary name, cover, photo, and date range covering three days. There should be three to four travelers associated with the itinerary. Each traveler should include a first name, last name, avatar, photo, and preferred travel style, like foodie or history buff. For each day include a collection of things to see on that day. There should be 12 to 15 items in total. The items should uh, be a hotel for day one. Popular things to see on each subsequent day. Each item should include a name, a start time, a duration, a star rating, number of reviews. Tags to describe them a photo in a short description. Some items should have notes for one or more travelers. The notes should be in chronological order and respond to each other like a message thread for each itinerary item.

Ravi calls the Unsplash MCP integration a key unlock for this process. It allows Claude to search for relevant photos and place real URLs in the sample data, avoiding the hallucinated links that often break prototypes. External media still requires link checking and compliance with the provider’s current license and usage terms.

This step takes longer than a simple prompt because the model generates a large JSON structure and makes several API calls for images. The result is a rich dataset with concrete itinerary details, traveler profiles, and media fields ready for the prototype to render.

Step 2: Build the prototype around the dataset

Once the JSON data exists, the interface request in Reforge Build can be much shorter:

Generate a trip itinerary feature based on the sample data below

You then paste the full JSON dataset directly into the prompt.

The prompt tells the tool to use the supplied dataset rather than invent new content. The resulting prototype was far richer, with a beautiful, complete photo of the Eiffel Tower, relevant destination images, detailed itineraries, and traveler profiles with avatars. The team should still check that the implementation preserved the data accurately.

Ravi: "The tool has been able to focus on what is the right UX around this dataset rather than simultaneously figuring out the UX and the dataset."

Step 3: Change the data and test the interface

Because the data is separate, Ravi can edit the sample data directly in the project’s `lib/sampleData.ts` file and see how the interface responds.

A small data edit, such as changing a traveler’s name from Marcus to Mark or replacing a cover image URL, updates the scenario instantly without requiring a new interface prompt.

You can also jump back into Claude and ask it to generate an entirely new itinerary using the exact same schema:

Now generate an itinerary for the same travelers going to Thailand.

With the schema already established in the conversation context, Claude can generate another dataset for a different destination, like Thailand, again using the Unsplash integration for images. Ravi then swaps the new JSON into the prototype to test the interface with a completely different scenario.

This flexibility makes it much easier to:

• Stress-test the layout: Try long profile text, vertical images in horizontal containers, missing fields, or unusual characters. These cases give the design team concrete states to review.
• Test localization layouts: Generate representative strings in other languages to expose text expansion and wrapping problems, then have a fluent speaker review the language itself.
• Augment data: If you already have some JSON, you can ask Claude to "augment this JSON with information about the travelers and their conversations," adding new parts without starting over.
• Add a feature state: Ravi prompted the tool to add blank itinerary cards for open time between activities, and the new component worked correctly across both the Paris and Thailand datasets.

Structured sample data makes the prototype easier to inspect and vary. The data-driven prototyping workflow keeps the schema, realistic media, interface prompt, and verification pass in one sequence without asking the model to invent every layer at once.

A subject, setting, and style framework for Midjourney

Ravi applies a similar principle of separating concerns to image prompting. Instead of one broad visual direction, he specifies the subject, setting, and photographic style as distinct components.

This structure gives him three independent levers to adjust when an image misses the intended composition or mood.

The subject, setting, and style framework

His framework breaks every Midjourney prompt into three parts:

• Subject: What exactly do you want to show?
• Setting: Where is the subject? Ravi emphasizes that this includes lighting and time of day, which photographers consider essential.
• Style: How should it look? This is where references to photography and culture are useful.

Here is what the difference looks like between a basic prompt and a structured one:

• Basic Prompt: office chair

Result: A generic set of chair images. Ravi notes that while they are nice, they are not quite usable for something like a product catalog.

• Structured Prompt: an empty stylish office chair, overlooking Milan during an autumn raining morning, Fuji Color C200

Breakdown:

• Subject: an empty stylish office chair
• Setting: overlooking Milan during an autumn raining morning (This defines the location and lighting)
• Style: Fuji Color C200 (A warm film stock known for producing golden-hour tones)

Result: A set of beautiful, usable photos with clear cultural cues from the Milan setting, specific lighting, and a distinct photographic treatment. Ravi considered these catalog-ready.

Using film and camera vocabulary

Ravi adds film stocks, camera brands, focal lengths, and aperture language to the style portion of a prompt. The working theory is that these models were trained on image datasets that included this metadata, so using these terms steers the model toward the higher-quality images in its training data.

Film Stock Example: Kodak Trix

Instead of just asking for a grainy, high-contrast image, which can lead to an over-processed look, Ravi specifies Kodak Tri-X. This is a black-and-white film known for its visible grain and contrast, producing a more subtle and authentic result.

Camera Metadata Example: Leica + Lens Details

For a portrait of a young man, Ravi used this prompt:

A young man with brown hair and eyes at golden hour, Leica 50mm F1.2, Fujifilm Provia

Breakdown:

• Leica: A reference to a high-end camera brand. Ravi notes that mentioning an expensive camera seems to put the model in a space associated with more aesthetic, professional photography.
• 50mm lens: A standard focal length for portraits.
• F1.2: An aperture reference that suggests an incredibly blurry background for an ethereal look.
• Fujifilm Provia: A film-stock reference known for being well-suited to portraits.

Result: The portraits generated with specific camera and film vocabulary have a distinct aesthetic quality and successfully avoid the uncanny valley often seen in AI-generated images of people.

When the camera metadata was removed, the results shifted toward generic sketches or photos that looked too perfect and fell into the uncanny valley.

Ravi: "As you develop that understanding of art literacy, you’ll also develop a vocabulary around it, which I think is incredibly powerful for prompting."

Ravi's method depends on having the visual vocabulary to name what he wants. The subject-setting-style workflow turns that vocabulary into three independent levers for composition, setting, and photographic treatment.

If you have an image you like but lack the words to describe it, you can upload it to a multimodal model and ask it to identify the lighting, composition, and photographic characteristics. This can be a great way to build your vocabulary, but you should only use images you have permission to upload and treat the analysis as a learning tool, not a license to copy another creator’s work.

Separate the decisions you want to control

Ravi’s prototype workflow separates the dataset from the interface. His Midjourney workflow separates the subject, setting, and style. In both cases, this structure makes it easier to identify which part of an output needs to change and iterate more effectively.

The model still makes mistakes, and the team still owns the final product and visual decisions. The benefit of this structured approach is a clearer iteration loop: you can change the sample data, a layout instruction, or a style term without rebuilding every other part of the prompt.

For consumer product teams, these data-driven prototypes can help test richer content and personalization ideas before committing engineering resources. They remain prototypes, however; teams still need to conduct user research, accessibility reviews, and technical validation for production.

Ravi also experiments with aspirational role language, such as "elite photographer." He treats it as a heuristic to steer the model toward the part of its training data associated with higher-quality output, not as a guarantee of expert-level work.

Ravi's methods are worth copying because they replace ambiguous, all-in-one prompts with a more disciplined, layered approach. Defining the data first is especially useful for teams building on existing products with established data models. The structured image prompting requires more up-front knowledge of visual terms, but it provides far more control over the final output. A useful first experiment is to define one JSON schema, populate two different datasets, and compare how the same interface handles both.