---
title: "The Art of the Three-Option Card: Designing AI-Curated Results"
description: "Information hierarchy, comparison design, mobile constraints, and the tap-to-expand pattern — how we designed flight and hotel cards that convert."
canonical: https://nowah.xyz/blog/three-option-card-design
lastModified: "2026-08-07T07:57:32.009Z"
---

# The Art of the Three-Option Card: Designing AI-Curated Results

Information hierarchy, comparison design, mobile constraints, and the tap-to-expand pattern — how we designed flight and hotel cards that convert.

When we decided that Nowah would present three curated options instead of hundreds of unsorted results, we thought the hard work was in the AI curation logic. It wasn't. The curation logic took weeks. The card design took months.

Presenting [three options](/blog/why-three-options-not-three-hundred) sounds simple. It is the opposite. When you show someone [three hundred](/blog/three-options-not-three-hundred) results, the design can be lazy. It is a list. Scroll through it. Apply filters. The user does the work of finding what they want. When you show three options, each one has to earn its spot. The design has to communicate why this option is here, how it compares to the other two, and what the user needs to know to make a decision. Every pixel matters because there are only three cards and no filter sidebar to fall back on.

This is our breakdown of how we designed the flight and hotel cards in Nowah, what we got wrong at first, and the principles we landed on.

## Information hierarchy for flight cards

![Illustration for this section](https://pics.nowah.xyz/website-media/product-022-img-1.webp)

A flight has a lot of attributes. Departure time, arrival time, duration, number of stops, layover duration, layover airport, airline, flight number, aircraft type, cabin class, baggage allowance, seat pitch, cancellation policy, price, taxes, fare class. Put all of this on a card and you get a spreadsheet, not a booking interface.

We organize flight card information into three tiers.

Primary information is what you need to compare options at a glance. For flights, this is price and schedule. Price tells you how much. Schedule (departure time, arrival time, total duration) tells you how your day is affected. These two dimensions account for probably 80% of how travelers choose between flights. They get the largest type size and the most prominent position on the card.

Secondary information is what provides context for the comparison. Airline name and number of stops. These modify the primary decision. A nonstop flight at $650 feels different from a one-stop flight at $650. United feels different from a budget carrier you have never heard of. Secondary information is visible on the card but does not compete with price and schedule for attention.

Tertiary information is what you need for the final decision but not for comparison. Baggage allowance, cancellation policy, aircraft type, fare class. This lives behind a tap. Showing it on the summary card would slow down the comparison without improving it. Users tap to expand only when they have narrowed to one or two options and want the details before committing.

We reached this hierarchy through testing. Early card designs showed too much. Users took noticeably longer to compare three cards when each card displayed ten data points versus five. The additional information did not lead to different choices. Users were just slower.

Our rule of thumb: if a piece of information would not change most people's choice between option A and option B, it does not belong on the summary view.

## Comparison at a glance

Three cards sitting next to each other (or stacked vertically on mobile) need to be instantly comparable. The user's eyes should be able to scan a single data point across all three cards without hunting.

This requires rigid layout consistency. Price occupies the same position on every card. Departure time occupies the same position. Arrival time. Duration. Stops. The grid is identical. Only the values change.

We use a fixed-width layout for each card rather than letting content dictate the layout. This means a card for a short domestic flight and a card for a long-haul international flight look structurally the same, even though the data is different. Duration "2h 15m" and duration "14h 30m" occupy the same space. This consistency is what makes scanning work.

Color and visual weight support the comparison without adding clutter. Price gets the heaviest visual weight (bold, larger size, accent color). The cheapest option has a subtle visual indicator. The "best overall" option gets a small label. These are not flashy badges. They are quiet signals that help the user see the agent's recommendation while making their own choice.

One thing we explicitly do not do: we do not sort the three options by price. Sorting implies that the first option is "best," which reduces the three-option model to a ranked list. Instead, each option represents a different value dimension. One might be the best price. One might be the best schedule. One might be the best overall balance. This encourages the user to consider all three rather than defaulting to the cheapest.

## The "why this option" label

![Supporting diagram](https://pics.nowah.xyz/website-media/product-022-img-2.webp)

This is the feature that makes AI curation visible. Each of the three cards carries a small label explaining why the agent selected it.

"Best price." "Shortest travel time." "Nonstop, your preferred airline." "Best balance of price and schedule." "Morning departure, arrives with time for dinner."

These labels do two things. They make the comparison framework explicit. Instead of figuring out why these three options look different, the user sees immediately what dimension each one optimizes. And they demonstrate that the AI is doing real work. It did not just grab three random options from the search results. It thought about the tradeoffs and made deliberate selections.

We spent a lot of time on the phrasing of these labels. Early versions were generic: "Option 1," "Option 2," "Option 3." Users found them useless. The next iteration tried detailed explanations: "Selected because it offers the lowest price while maintaining a single stop and a reasonable connection time of 2 hours in Denver." Too long. The card felt cluttered. Nobody read the whole label.

We landed on labels that are five to eight words. Specific enough to be useful. Short enough to scan. Written in natural language, not marketing copy. "Nonstop, gets you there by noon" works. "Premium selection for the discerning traveler" does not.

The labels also serve a trust-building function. When the AI tells you why it chose something, you can evaluate its reasoning. If the label says "best price" and the price is clearly the lowest of the three, the agent's judgment is validated. If a label says "your preferred airline" and it is indeed the airline you always fly, the memory system is validated. Each accurate label builds confidence in the agent's decision-making.

## Mobile constraints and solutions

Here is the physical reality: most Nowah users are on phones. The screen is 375 pixels wide. The chat has padding on both sides. The usable width for a card is roughly 320 pixels. Three flight cards need to stack vertically. Each card must contain enough information to compare options without scrolling inside the card.

This constraint forced some hard design choices.

We abandoned horizontal card layouts early. Three cards side by side on a phone screen means each card is about 100 pixels wide. That is enough for one piece of information, not a flight comparison. Vertical stacking works better, but it introduces scrolling. The user needs to scroll to see all three cards, which means they cannot see all options simultaneously.

Our solution is compact cards with minimal vertical height. Each summary card is roughly 80 pixels tall. Three cards plus the AI's introductory text fit on a single screen for most phones. The user can see all three options at once without scrolling, which is the thing that makes comparison possible.

To fit five data points into 320 by 80 pixels, we use a two-row layout within each card. Row one: departure time, arrival time, and route (with a flight path graphic between the airport codes). Row two: duration, stops, airline on the left; price (large, bold) on the right. The "why this option" label sits above the card as a small colored tag.

Users decide about 40% faster when they can see all three options on screen simultaneously compared to needing to scroll between them. That stat drove our obsession with compact card height. Every pixel of vertical space we cut from each card makes comparison easier on small screens.

We tested this on the smallest common phone size (iPhone SE at 375 points wide, roughly 5.5 inches diagonal) to make sure the design works at the minimum. Cards designed for larger phones tend to fall apart on small screens. Cards designed for small screens work fine on larger ones.

## The tap-to-expand pattern

Summary cards are for comparison. Detail views are for decision-making. The transition between them needs to be seamless.

When a user taps a flight card, it expands in place. The card grows vertically within the conversation to reveal additional information: full baggage allowance, fare class, cancellation policy, seat configuration, and a "Book this flight" button.

This expansion happens inline. The card does not open in a modal. It does not navigate to a new screen. The conversation above the card is still visible. The user can scroll up to review what they asked for or check the AI's recommendation text. Context is preserved.

The animation is intentional. The card smoothly expands over about 250 milliseconds. Content fades in with a slight stagger: details first, then the booking button. This choreography signals that new information is appearing, gives the user's eyes time to adjust, and avoids the jarring snap of instant content appearance.

Tapping an expanded card collapses it back to summary view. Tapping a different card collapses the first and expands the second. Only one card is expanded at a time. This prevents the conversation from becoming a wall of detail views and maintains the compact comparison layout for the cards the user is not currently examining.

The expanded view is the decision point. It is where the user goes from "this looks interesting" to "I want to book this." So it needs to answer the questions that prevent commitment. "[What happens](/blog/what-happens-after-you-book) if I need to cancel?" Cancellation policy is right there. "How much luggage can I bring?" Baggage allowance is visible. "What kind of seat will I get?" Seat configuration is shown. These are the objections that kill bookings on traditional platforms when they are hidden behind multiple clicks.

## Hotel cards: the harder design problem

Flights are relatively objective. A flight is a commodity defined by numbers. The schedule either works for you or it doesn't. The price is the price. Two different airlines flying the same route at the same time are essentially interchangeable.

Hotels are subjective. Two hotels at the same price in the same city can feel completely different. Location, style, room quality, noise level, neighborhood vibe, proximity to what you want to do. These are qualities that numbers struggle to capture.

This makes hotel card design fundamentally harder than flight card design. You cannot just show price and check-in time and call it sufficient. The user needs to feel the hotel, not just read its specs.

Photos are non-negotiable for hotel cards. We lead with a single hero photo that shows the best representation of the property. The photo is wider and taller than any text on the card because for hotels, the visual impression often matters more than the data.

Below the photo: hotel name, price per night, total price, star rating, and a one-line AI summary. That summary is the hotel equivalent of the "why this option" label on flight cards, but it carries more weight. "Boutique hotel in Shibuya, 5 min walk to metro, quiet street" tells you more about the hotel experience than any numerical rating could.

We do not show lengthy review excerpts on the summary card. The AI synthesizes reviews into its recommendation and summary line. "Guests love the breakfast and rooftop bar. Some mention street noise on lower floors." This synthesis is more useful than showing a 4.3-star rating, which tells you almost nothing about what staying there would actually feel like.

Hotel comparison is harder because the dimensions are less standardized. For flights, everyone compares price and schedule. For hotels, some people prioritize location, others prioritize comfort, others prioritize price. Our three-option labels for hotels tend to reflect this: "Best location for your plans," "Best value, great reviews," "Closest to your preferred style." The agent tries to present options that differ on meaningful dimensions rather than just offering three similar properties at different price points.

## How Kayak and Google Flights display results differently

It is worth looking at how the incumbents display flight results, because their [design decisions](/blog/year-in-review-design-decisions-shipped) reflect a different product philosophy.

[Google Flights](/blog/best-flight-booking-2026-ai-vs-google) shows a list. Dozens or hundreds of results, sorted by "best" (a proprietary algorithm) with options to sort by price, duration, departure time, or arrival time. Each result row is compact. It shows times, duration, stops, and price. The list is scannable, and the filter sidebar lets you narrow down by airline, stops, bags, and more.

This is a good design for a search engine. Show everything. Let the user narrow. Trust them to find what they want. It works because Google's value proposition is comprehensiveness: we show you every option so you can find the best one.

Kayak takes a similar approach but adds "hacker fares" (combinations of one-way flights from different airlines) and a price graph showing how prices vary by date. The results page has more visual complexity but the same underlying philosophy: show many options, provide tools to explore them.

Both designs are optimized for the browse-and-filter paradigm. They assume the user will do the work of narrowing hundreds of results to one purchase. The interface provides tools for that work. It is the user's job to use them.

Our card design is optimized for the curation paradigm. The AI already did the narrowing. It searched the same inventory that Google and Kayak searched and applied the user's preferences, constraints, and past behavior to select three options. The card design does not need to support browsing hundreds of results. It needs to support comparing three curated selections and making a confident decision.

This changes the design requirements in concrete ways. Google Flights needs compact result rows because it shows dozens of them. We can afford richer, more detailed cards because we show three. Google Flights needs powerful filter controls because the user is doing the work. We do not need filters because the AI is doing the work. Google Flights needs sort options because the ranking preference varies by user. We need "why this option" labels because the ranking is already done.

Different product philosophy, different design. Neither is wrong in context. But we believe the curation-first approach is where the industry is heading, and the card design needs to match.

## Principles for anyone designing AI-curated option cards

If you are building an AI product that presents curated options, here is what we have learned distilled into principles.

Limit to three options unless there is a strong reason for more. Two feels insufficient (the user wants choices). Four or more starts to re-introduce the paradox of choice that curation is supposed to solve. Three is a cognitive sweet spot.

Design for comparison, not individual evaluation. Each card exists in the context of the other two. Layout consistency across cards matters more than optimizing each card individually.

Explain the curation. Users need to understand why these three were selected. Without "why this option" labels, the curation feels arbitrary. With them, it feels intelligent.

[Mobile first](/blog/why-we-chose-mobile-first), then scale up. Design cards for 375-pixel-wide screens. They will work fine on tablets and desktops. Cards designed for desktops will break on phones.

Summary for scanning, detail for deciding. The tap-to-expand pattern separates two cognitive modes: "which of these am I interested in?" and "should I commit to this one?" Mixing these modes on a single card slows both down.

The booking action belongs in the expanded view, not the summary. Putting a "Book" button on every summary card pressures the user before they have enough information. Putting it in the expanded detail view means the user has reviewed the details and is making an informed decision.

These principles work across domains. We designed them for travel, but the same patterns apply to any AI product presenting curated options: real estate, insurance, financial products. Anywhere an AI narrows many options to a few recommended ones, the card design determines whether users trust the curation and act on it.

---

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](https://app.nowah.xyz).