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.
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.
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:
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.
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.
Source: International Business Times UK
