In scope
- Add & manage Google Pay
- Payment methods list & defaults
- Wireframes through prototype
- Design system fit
Case study
Adding Google Pay without breaking trust
Google Pay had to join live payment methods with the same clarity as cards and other trusted options, not as a novelty screen. I led design from flows through hi-fi inside the design system at BORN and Tech Mahindra, working with Telefónica engineering and stakeholders.
Figma
Jira
Design system
383M+
Every pattern had to hold at real telecom scale.
Payment methods
Add flow, outcomes, and how it reads in saved methods and defaults.
Build-ready
Flows, wireframes, hi-fi, and motion treated as specs engineering could implement.
My role
I owned Google Pay across entry, add and verify, list, default, and edge cases, from wireframe to hi-fi with engineering and stakeholders.
Context
- Client Telefónica
- Company BORN · Tech Mahindra
- Teams Creative · Tech · Business
Problem
Make Google Pay feel native, not bolted on
People reach for payment methods they already trust when a moment has to feel fast and sure. On a telecom-scale stack, adding Google Pay was integration work, not a new line item: fit it beside existing methods without friction, confusion, or drop-off.
They expect the add flow to stay fast, legible, and safe; ambiguity costs completion. Google Pay spans handoff and return the core product does not fully own, so those beats had to read like the rest of the app or trust breaks early. Drop-off follows unclear labels, unexplained steps, and outcomes that do not feel final. Cards and other methods already set the pattern; Google Pay had to inherit that pattern, not run a parallel experience.
Focus
What I held in scope: Google Pay
Goals
- Add Google Pay as a trusted option without destabilizing existing payment methods.
- Keep the add flow quick, predictable, and understandable for a broad audience.
- Ship UI that fits Telefónica’s design system and scales with the rest of payments.
My lane
- Google Pay UX: add flow, verification, list, default.
- States and edge cases across mobile and desktop.
- Hi-fi prototypes for review and handoff.
- Regular sync with developers and stakeholders.
Out of scope
- Other wallets
- Backend / APIs
- Full payments redesign
Approach
Design direction
I treated this as system integration for adoption, not only shipping another option. People rarely compare payment methods in depth; they pick what feels familiar, clear, and reliable, so a new method has to read as understandable and trustworthy almost immediately.
Three principles steered the work:
- Reduce cognitive load. Keep the path simple and predictable so people can finish without extra mental models or pattern-breaking layout.
- Leverage familiarity. Match hierarchy, cues, and tone with cards and other methods so Google Pay feels like a natural extension of what is already there.
- Trust and feedback. Make every step legible, especially success and error, so users always know where they are and what to do next.
I mapped add and manage end to end, flagged where hesitation or failure tends to surface, and kept the experience consistent with the rest of payments so engineering is not stuck maintaining a one-off.
System thinking
The full add-and-manage story
A payment method isn’t done at “linked.” It has to read correctly in the list, survive failure, and support choices like default without fighting the rest of the system.
I mapped mobile and desktop in one narrative so patterns stayed aligned. The Figma board below traces adding Google Pay: entry into payment methods, selection and handoff to Google’s flow, return paths, and success vs. failure. It also covers how the method appears in the saved list and flows around making it default, moments that decide whether people actually use what they added.
Decision points and annotations spell out verification errors, retry vs. choose another method, and confirmation so the logic was shareable with engineering and stakeholders, not just a wall of frames.
Annotated user flow (Figma)
Embedded on this single frame (not the whole file). Pan and zoom inside the board as needed. If it doesn’t load, open the link below.
Solution
How it shows up in the product
The experience is shaped across three key moments: entry, integration, and feedback.
Entry: Add payment method
Entry is the payment methods hub. Google Pay appears as one more option in the same list, so it reads as part of the system users already trust.
The Google Pay integration path
From selection, the flow covers linking and verification with clear handoffs to Google where needed. Structure and copy follow other methods so the wallet still feels in-product.
Confirmation and feedback
Success updates the list: the method is visible, labeled, and ready to use. Failures spell out what happened and the next step (retry, verify details, or choose another method).
Desktop walkthrough
Add payment method flow in motion. Google Pay hi-fi was not fully live at capture, so this clip uses PayPal with the same structure as the Google Pay design.
Outcome
What this unlocked
This work enabled a Google Pay integration that could ship within an existing system, consistent with established patterns, explicit in handling edge cases, and clear to users who never see the underlying complexity.
Within the product, Google Pay became a first-class payment method: aligned with existing behaviors, fully integrated into success and failure states, and clearly positioned within the payment methods hierarchy.
Success would be reflected in:
- High completion rates when adding the method
- Fewer drop-offs during the flow
- Increased adoption as a preferred payment option
More broadly, this project reinforced that in mature systems, integration is the design. The goal isn’t to create something new, it’s to introduce new capability in a way that feels inevitable.
