Designing the Map: When and How to Show Geography
Maps in a chat-first app should appear as inline cards when location context adds value — hotel proximity, flight routes, POI clusters — and stay hidden when they do not.
Not every travel query needs a map. "Find me flights to Tokyo" does not benefit from a geographic display. The user knows where Tokyo is. What they need is prices, times, and airlines. A map would add visual noise without adding useful information.
But "Find me a hotel near the Eiffel Tower" desperately needs a map. The user is making a location-dependent decision, and text descriptions of proximity ("0.8 km from the Eiffel Tower") are less useful than seeing the hotel pinned on a map relative to the landmark.
The design challenge for maps in a chat-first app is knowing when to show geography and when to stay textual. A map that appears at the right moment adds significant value. A map that appears unnecessarily clutters the conversation and slows the scroll.
When to show a map
Three scenarios consistently benefit from map display.
Hotel location context. When the AI presents hotel options, a map card showing where each hotel is located relative to landmarks, attractions, or addresses the user mentioned helps the user evaluate proximity in a way that text distances cannot. "800 meters from the city center" and "2 kilometers from the beach" are abstract. Pins on a map are concrete.
Route overview for multi-city trips. When the user is planning a trip that spans multiple cities, a route visualization showing the path from city to city provides spatial context for the entire journey. Tokyo to Osaka to Kyoto becomes a visual sequence on a map rather than a list of city names.
Point of interest discovery. When the user asks "What should I do in Barcelona?" and the AI suggests activities, a map showing where those activities are located relative to the user's hotel helps with planning logistics.
When not to show a map
Flight search results do not need maps. The user is comparing prices, times, and airlines. The geographic route is the same for all results on the same route. A map adds nothing.
Booking confirmation does not need a map. The booking is complete. The user needs a reference number and next steps, not a geographic view.
Preference discussions do not need maps. When the AI is asking about travel style or seat preferences, geography is irrelevant.
The rule is straightforward: show a map when the user's decision depends on spatial relationships. Hide the map when the decision depends on non-geographic factors like price, time, or features.
Inline map cards: dark-themed and minimal
Maps in a chat-first app appear as inline cards within the conversation, not as full-screen takeovers. The map card occupies a defined area within the message flow, and the conversation continues below it.
The map card must match the app's dark theme. A standard light-themed map with pastel colors and white backgrounds would visually clash with the black interface. We use a dark-styled map with muted colors, minimal labels, and high-contrast pins for marked locations.
Minimalism is critical. The map card shows essential pins and labels only. No traffic overlay, no public transit lines, no satellite imagery, no street-level detail. Just the geography, the pins, and the labels. The map is a reference tool, not an exploration tool.
Pin design uses the primary green accent color for highlighted locations (hotels the AI recommended, landmarks the user mentioned) and a neutral gray for context pins. This creates a clear visual hierarchy: green pins are what matters, gray pins are context.
Hotel location context
The most common map use case is hotel selection. The AI presents three hotel options as cards, and below them, a map card shows all three hotels as numbered pins corresponding to the card numbers. The user can visually compare locations at a glance.
The map card also shows the landmark or area the user mentioned. If the user said "near the Louvre," the Louvre is pinned on the map as a reference point. The hotels are numbered pins around it. The spatial relationship is immediately clear.
Distance labels connect each hotel pin to the reference landmark with a small text indicator showing walking or transit time. "5 min walk" is more useful than "400 meters" because people think in time, not distance, when evaluating convenience.
Route visualization for multi-city trips
For multi-city trips, the route map shows a different kind of information: the journey path. Cities are connected by arc lines indicating flights, with dates and transport type labeled on each segment.
This visualization helps the user understand the overall shape of their trip. Is it a linear path or a loop? How far apart are the cities? Is there a long flight that might be worth breaking with a stopover?
The route map uses a simplified world or regional view, zoomed to fit all cities in the trip with comfortable margins. No street-level detail. Just city markers, connecting arcs, and labels. The goal is geographic context at the journey level, not navigation-level detail.
Adding contextual maps to your chat interface
If you are building a chat-first product with location-relevant content, the map card should be a first-class component in your design system. Define it as an inline card type with consistent height, dark theming, and minimal detail level.
Build a decision system that determines when to show the map. The AI should evaluate whether the current response involves location-dependent decisions and include the map card when it does. The map should never appear as decoration. It should always appear as a tool that helps the user make a better decision.
The best map in a chat interface is one that the user barely notices but would immediately miss if it were not there.
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.