--- title: "Mobile-First, Web-Companion: Our Cross-Platform Strategy" description: "72% of travel research starts on mobile. We design for the phone first, then extend to web for desk-based planning sessions — same tokens, different layouts, shared components." canonical: https://nowah.xyz/blog/mobile-first-web-companion-strategy lastModified: "2026-08-07T08:02:11.265Z" --- # Mobile-First, Web-Companion: Our Cross-Platform Strategy 72% of travel research starts on mobile. We design for the phone first, then extend to web for desk-based planning sessions — same tokens, different layouts, shared components. Seventy-two percent of travel research starts on a phone. Not at a desk. Not on a laptop. On a phone, in bed, on the couch, on the train, during lunch. The initial spark of "I want to go somewhere" happens on mobile, and the product needs to be ready for that moment. But not all travel planning stays on mobile. At some point, many users switch to a larger screen. They want to compare options side by side, read through booking details without squinting, or plan a complex [multi-city](/blog/multi-city-flight-booking-ai-agents) trip where screen real estate helps manage complexity. The web is not the primary platform, but it is a valuable companion. This is why we design mobile-first and web-companion. The phone gets the full, optimized, primary experience. The web gets an experience that extends and enhances the mobile one for larger screens. Same data, same AI, same design language. Different layout, different interaction patterns, different strengths. ## Same tokens, different layouts ![Illustration for this section](https://pics.nowah.xyz/website-media/design-044-img-1.webp) The foundation of cross-platform consistency is shared design tokens. Colors, spacing values, typography scales, border radii, and shadow depths are defined once and implemented on both platforms. Pure black background. Green primary accent. White text on dark surfaces. Gray secondary text. These are not separate decisions made on each platform. They are tokens defined in a shared system and applied consistently. A flight card on mobile and a flight card on web use the same green for the price, the same border radius for the card container, the same font weight for the departure time. What changes between platforms is layout. On mobile, the chat occupies the full screen. Messages stack vertically. Cards fit the screen width with minimal horizontal padding. Everything is optimized for single-column, thumb-driven interaction. On web, the chat has a constrained width, roughly 680 pixels. The remaining screen space can hold side panels, wider card layouts, or contextual information that would not fit on a phone. The content is the same. The arrangement is different because the canvas is different. ## Where travelers are when they plan Understanding when and where people plan travel explains why mobile-first is the right default. The initial inspiration tends to happen during downtime: scrolling in bed, commuting, waiting in line. These are phone moments. The user has a few minutes and an idea. They open the app, tell the AI where they want to go, and start a conversation. The planning phase often continues on mobile but sometimes migrates to desktop. A user who started chatting about a trip to Barcelona on their phone might switch to their laptop when they want to review the three hotel options in more detail. The web companion is designed for this handoff. The conversation syncs. The options are still there. But now they are displayed in wider cards with more visible data. Booking tends to happen wherever the user feels most comfortable with payment. For some that is mobile, with a familiar [payment sheet](/blog/payment-sheet-native-vs-custom) and biometric authentication. For others it is desktop, where they feel more secure entering payment details. Both platforms support the full booking flow because we cannot predict which context will feel right to each user. ## The web advantage ![Supporting diagram](https://pics.nowah.xyz/website-media/design-044-img-2.webp) Larger screens are not just bigger phones. They offer capabilities that mobile cannot match, and the web companion takes advantage of them. Wider cards show more information without scrolling. A flight card on mobile might abbreviate the airline name or truncate the airport codes. On web, the full airline name, full airport names, terminal information, and baggage allowance can all appear in a single card view. Side panels allow contextual information alongside the conversation. The user is chatting about hotels in Barcelona, and a panel on the right shows a map with the three hotel options pinned. No need to switch between chat and map. Both are visible simultaneously. Keyboard input changes the interaction dynamic. On mobile, voice input is a primary mode because typing on a phone keyboard is slow and error-prone. On web, the physical keyboard is fast and precise, so text becomes the primary input. Keyboard shortcuts add efficiency: Enter to send, common commands for quick actions. Split views enable comparison workflows. Two hotel options side by side, or a flight itinerary next to a map showing the route. These comparison patterns are impractical on a phone screen but natural on a laptop. ## Shared component primitives The flight card is the same component on both platforms, built from the same primitive elements: airline indicator, time display, duration badge, stop count, price label, select button. On mobile, these elements stack vertically in a compact card. On web, some elements shift to horizontal arrangement to take advantage of wider space. This is the critical difference between shared tokens and duplicated components. We do not build two separate flight cards. We build one flight card that responds to its container width. When the container is narrow (mobile), the card uses its compact layout. When the container is wide (web), the card uses its expanded layout. Same data, same visual language, different spatial arrangement. This approach means design changes propagate to both platforms simultaneously. Update the green accent color in the token file and it changes everywhere. Adjust the card border radius and both platforms reflect it. The design system is the [single source](/blog/every-trip-single-source-of-truth) of truth, and both platforms are consumers of that system. ## Building a cross-platform token system If you are designing for mobile and web, start with tokens. Define your color palette, spacing scale, typography scale, border radii, and elevation levels as named values. Then implement those tokens on each platform using the platform's native styling system. On mobile, that might be a styling configuration that maps token names to values. On web, it might be CSS custom properties or a configuration file. The implementation differs. The values are identical. Then build components that consume tokens rather than hardcoding values. A button does not have a green background. It has a primary-action background, which resolves to green through the token system. This indirection is what makes cross-platform consistency maintainable as the system grows. The goal is a single design language spoken with two accents. Mobile speaks it in a compact, touch-optimized dialect. Web speaks it in an expansive, keyboard-friendly dialect. But it is recognizably the same language, and a user switching between platforms never feels like they have opened a different product. --- 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).