travel

The brief sounded simple enough: embed our travel booking service inside a super app that already lived on millions of phones. Use the webview we already had, keep engineering costs low, and ship fast.

I'm a product designer, so I spent about five minutes feeling good about that plan before the problems started arriving.

Why bother integrating at all

People book flights or hotels maybe once or twice a year. Asking them to download a dedicated app for that is a hard sell. The friction of installation rarely feels worth it for something you'll use twice annually. The super app, though, had been on their phones for years. It was the dominant ride-hailing platform in the market; the app people opened every time they needed a taxi, which in practice meant several times a week. That kind of daily utility earns a permanence that no travel product, used twice a year at most, could compete with. An entry point there meant reaching users who would never have found us organically. The business case was clear. The design work was not.

Where it got complicated

Three concrete obstacles showed up almost immediately.

Navigation. The host app had its own header bar and a firm rule: every screen must carry a readable title. Our travel service had its own internal navigation, with breadcrumbs, section transitions, and back-and-forth flows between search, results, and booking confirmation. Two navigation systems, one screen. We looked at three options:

  • Let the backend pass data directly into the header. It could, but the data it passed was raw and unformatted: think half a screen of cluttered text, or a string of coordinates showing up where a location name should be, none of it making any sense to an actual user.
  • Remove the title entirely. This violated the host app's own guidelines. Beyond that, it would have left users without a basic orientation cue, with no way to understand where they were in the booking flow at any given moment, so it wasn't really an option.
  • Go through the travel product screen by screen and manually write a title for each, so those titles populate the header correctly.

We chose the third. The work fell on me as a designer: I went through and labeled what amounted to the entire product, working alongside QA testers who helped surface corner cases and edge states on test devices that I wouldn't have been able to provoke on my own. It required almost nothing from engineering and produced something that actually worked. Sometimes the manual solution is the practical one.

External links.The host app had a strict policy: no links that open a browser outside the app, because redirecting users away from the environment they're in disrupts the experience and undermines trust in the service. Our travel product, built over the years, had accumulated legal pages, partner links, and various other outbound references scattered throughout the interface. Finding and removing every single one required a full audit of the product. Unglamorous work, and exactly the kind of thing that doesn't make it into design portfolios.

The active booking widget. Our travel service had a 'My Trip' feature that showed users their upcoming reservations, whether a flight, train, or bus, with departure and arrival details, check-in dates, and hotel name. We wanted that touchpoint to survive the integration, because without it, users would have no sense of continuity between booking something and actually going somewhere. Webview doesn't give access to the full data the feature normally relies on, and the widget itself had to be built natively by the host app's team, rather than served through our webview. That meant coordinating between two separate engineering teams, agreeing on what data our backend would prepare and how their native layer would render it. We landed on a compact version: city, hotel, dates, and for transport bookings, departure and arrival details. Enough to be useful.

The first impression we gave up

Resolving those three things took time and coordination across two products, two codebases, and two sets of stakeholders. We launched by region, watched the metrics, and expanded when the numbers held. They exceeded our targets from day one, resulting in a full rollout.

The native app was significantly better. We had worked on it long enough to know exactly where every rough edge was, and the mobile web version had plenty of them. The screen users saw when they first opened our section of the super app was not something I was proud of. The next steps weren't obvious. The visual hierarchy was weak. The team's designers knew this before we launched. Mobile web had never been the product's strong suit, and we weren't pretending otherwise.

Users didn't get lost, though, because we had accounted for every state: active reservations, edge cases, and every point where the two products touched. The core booking scenario worked, and we had simply handed people a front door that didn't reflect what was behind it.

The right call was to ship a functional solution, start earning from it, and improve from there. I believe that. What I'd push back on is the habit of reading strong post-launch metrics as confirmation that the design was good. Growing numbers told us something real and important about user needs: people wanted this, they were going to push through friction to get it. They told us less about the quality of what we'd built. Conflating the two is how teams stop improving things that still need work, and how designers end up proud of outcomes they didn't really earn.

There's a version of this story where we wait, build something better, and launch later. We didn't take that path, and the business results suggest we were right not to. But I'd rather be clear about what we traded away than let the numbers rewrite what we saw on the screen.

About the Author:
Renata Zaripzianova is a product designer at one of the largest technology companies in Russia, where she works on consumer-facing mobile and web products. Her focus is on product design across platforms from booking flows to marketplace listings, and the trade-offs teams make when shipping inside complex product ecosystems.