How We Design at Nowah: Process for AI Products

Our design process does not start with screens. This is probably the most counterintuitive thing about designing an AI-first product. You cannot start by drawing the screen because you do not know what the screen will look like. The content is generated by an AI that can produce wildly different outputs depending on what the user says.

A user might ask "find me flights to Tokyo" and get three flight cards with prices and times. Another user might ask "where should I go in April for under a thousand dollars" and get a paragraph of destination suggestions with no cards at all. A third might ask "book my usual" and get a single confirmation message. Same screen, same chat interface, three completely different visual compositions.

Traditional design process: research, wireframe, prototype, test, build. AI product design process: define components, script conversations, stress-test with real data, compose dynamically, test compositions.

Step 1: component design

We design components as independent units before we think about how they will be arranged. A flight card is designed to work at any position in a chat conversation. A message bubble is designed to hold any length of text. A booking confirmation is designed to appear after any sequence of preceding messages.

Each component is designed in isolation with its own states: default, loading, error, success, disabled, and any content-variant states. A flight card with one stop looks different from a flight card with three stops. A hotel card with a hero image looks different from one where the image failed to load. Every variant gets designed explicitly because the AI will eventually trigger every one of them.

The component library is organized by function: chat components, card components, booking components, navigation components, form components, and feedback components. This taxonomy matters because it determines how designers think about the building blocks. You are not designing screens. You are designing a vocabulary that the AI composes into screens.

Step 2: conversation scripting

Before any visual design begins, we write AI dialogues. These are conversation scripts that map out how the AI and user might interact through a complete booking flow, a trip modification, an exploratory planning session, and a half-dozen other scenarios.

The scripts are annotated with component requirements. "AI responds with three flight options" means the conversation will include three flight card components. "AI asks for clarification" means the conversation will include a text message with suggested response chips. "User selects a flight" means the conversation will transition to a review modal.

Writing the conversation first exposes design needs that screen-first thinking misses. You discover that the AI sometimes needs to show a flight card and a hotel card in the same message. You find that error messages need to offer recovery actions, not just state what went wrong. You realize that the AI might need to show partial results while still searching for more.

These discoveries drive component design back in step one, creating an iterative loop between scripting and component creation. The scripts are the use cases. The components are the building blocks. The design process bounces between them until both are comprehensive.

Step 3: edge-case stress testing

Traditional UI testing checks the happy path: the screen with sample data that fits perfectly. AI product testing must check every edge case because the AI will produce all of them.

What happens when the airline name is 40 characters long? The flight card needs to truncate gracefully. What happens when there are zero results? The AI needs an empty-state response that suggests alternatives. What happens when the price is missing from the API response? The card needs to handle the absence without breaking.

We maintain an edge-case gallery: the same component rendered in every problematic state. A flight card with a truncated airline name. A flight card with no stops. A flight card with three stops and a 22-hour layover. A flight card where the price failed to load. A flight card with an overnight arrival that crosses a date boundary.

The AI agent has over seventy tools it can call, which means edge cases multiply combinatorially. A flight search can fail. A hotel search can return partial results. A booking can succeed for the flight but fail for the hotel. Each combination needs a designed response, and the edge-case stress test is where we find the gaps.

Step 4: real-data prototyping

We never design with placeholder data. Every prototype uses actual responses from real APIs. When we are designing a flight card, we use actual flight data with real airlines, real prices, real durations, and real stop counts.

This matters because real data behaves differently from invented data. Real airline names vary in length. Real prices have different digit counts. Real flight durations range from 45 minutes to 18 hours. Real hotel names include characters from multiple languages. Designing with lorem ipsum and "Flight $XXX" hides all of these realities.

Real-data prototyping is slower than mock-data prototyping. You have to set up API connections, handle authentication, and deal with rate limits. But the designs that come out of it are production-ready in a way that mock-data designs never are. There are no surprises when the component meets real data for the first time because it already has.

Step 5: composition testing

The final step is testing how components work together in live conversation context. A flight card designed in isolation might look perfect. Three flight cards in a horizontal carousel within a chat bubble that follows a paragraph of AI text and precedes a set of suggested prompt chips might have spacing issues, scrolling conflicts, or visual hierarchy problems.

Composition testing puts components into real conversation flows and evaluates the whole. Does the carousel scroll smoothly within the message bubble? Is there enough visual separation between the AI's text and the card carousel? Can the user distinguish where the AI's message ends and the cards begin?

This is where conversation scripting from step two meets component design from step one in the actual product. The scripts predicted what compositions would exist. The stress tests verified that individual components handled edge cases. Composition testing verifies that the assembled result works as a coherent experience.

Adopting this process

If you are building an AI product, the core shift is from screen-first to component-first thinking. Stop asking "what does this screen look like?" and start asking "what components will the AI need, what states will they have, and how will they compose together?"

The screens emerge from the components. They are not designed. They are assembled. Your job as a designer is to create components robust enough to handle any assembly the AI produces, and to establish composition rules that keep the result coherent regardless of the specific combination.

Nowah is an AI travel agent that searches and books real flights and hotels through conversation — no filters, no thirty open tabs. Plan your next trip.