A web experience inside a native app

Google Pay’s Credit experience was delivered as a web application running inside native mobile apps. That arrangement is common and its consequences are routinely underestimated: the surface has to satisfy two sets of expectations at once, and only one of them is written down.

The user holds the first set, and holds it unconsciously. They do not know where the native app stops and the web begins, and they are not interested — so every gesture, transition and piece of chrome is judged against the app around it rather than against the web. Anything that behaves like a web page is experienced as a defect, even by someone who could not say why.

The shell holds the second set, and the web surface does not control it. It inherits whatever the host gives it and has to be correct inside constraints it cannot change or negotiate.

Modernizing an interface in that position is a different problem from redesigning a website. The target is not a visual specification; it is being indistinguishable from a host you do not own, while changing.

Hands-on engineering on the Credit team, contributing directly to the user-facing experience and to the interface modernization work. Implementation, not oversight.

Most of the revamp work on this experience was mine. Worth stating just as plainly what that does not mean: I did not own the Google Pay redesign, and I did not own the Credit product. One product area, with most of its interface work on me — a smaller claim than it might read as, and the accurate one. The exact scope of the Material 3 migration, which screens it covered, and its measured outcomes are things I would want to confirm before claiming any of them here.

The engineering detail and any measured results are internal to Google and are not published here.

Two jobs ran at once on this product: an interface revamp that reached end to end, and a move of the codebase onto a new design language. Either alone is a large piece of work. Together, on a product that was live the whole time, they rule out the obvious way of doing either.

You cannot take a payments product down to retheme it. Nobody will accept a window in which money does not move, and no amount of planning earns one — which means there is no moment where the old interface ends and the new one begins. Every intermediate state has to be a shippable product, so the old and new design languages have to coexist and look deliberate while they do. A migration like this is not a cutover; it is a long sequence of states each of which has to be defensible on its own.

That constraint decides most of what follows, and it is the part worth understanding about this kind of work. The visual target — a documented, public design language — was never the difficult half. Arriving there without a discontinuity, on a surface people rely on to move their money, was.