Select, fix, or create new. It’s up to you.
Case Study
As a Googler, if it wasn’t on the roadmap, all I had to do was prove it was worth it.
The payments profile selector is a cross-product surface used to select or switch payment profiles across Google Ads, Google Play, Chrome Web Store, Google Workspace, Cloud, Analytics, and partner integrations like Reserve with Google. Any company that sells or buys items or services on those platforms uses a payments profile to manage those transactions. The number of payments profiles is in the billions. Changing how users interact with them carried significant risk. Keeping the experience the same was was more risky. I set out to prove that improving it was worth a try.
The problem
Why the flow needed to change
Users sometimes had viewer access to a payments profile, not the edit/admin access they needed — and it wasn't clear why.
Profiles with unresolved issues were disabled in the UI, mixed in with usable ones, in no clear order
The reason a profile couldn't be used — and how to fix it — was nested as fine print inside a disabled radio button, invisible to screen readers
No design existed for every issue type, so engineering wrote its own copy
Website design
Hub screen (straddling the website and application design)
Website design
Research
Mapping every disabled-profile reason
Working with Ginevra, Mohsin, and Abhinav, I helped map the full logic behind why a profile is unselectable — action needed vs. under manual review vs. permanently restricted.
We catalogued every disabled-reason case (e.g. pending reverification, country mismatch, role/permission restrictions, duplicate identity links) and the CTA each one needed, then jammed on copy for the status badges so users get a hint at what's wrong before they have to act.
Hypothesis
Categorize by selectability, not status
Dividing profiles into three groups — Available, Action needed, and Info needed — would let users scan the list and find a usable profile faster, without hunting through disabled items for an explanation.
Critically: every item stays clickable. Nothing is disabled outright, so the reason and the fix are always reachable, including for screen-reader users.
Exploration
Finding the right component
Tried a Box Tab component first — felt visually disconnected from the rest of the dialog
Moved to a List Item pattern instead of a tab bar, so selection felt distinct from navigation
Ported GM3 List/List Item components into the Platinum GM2 design system, since they didn't exist there yet
Added a new surface-container color token and hover state so list items would contrast properly
Landed back on radio-button-style selection behavior to keep the interaction pattern familiar
Engineering scoped the build at ~2 weeks
Testing
Unmoderated usability testing
Kostas Kazakos ran an unmoderated test of the Figma prototype I had created.
High clarity: testers called it "very clear," "easy to understand," "straightforward" — the available, under review, and info needed grouping helped them scan
Navigation gap: several testers expected a "Next" button or clearer next-step CTA
During design team discussions, it was revealed that previous testing on the same dynamic CTA text was easier for users to understand than static CTA text
Wanted more feedback: testers wanted to see a profile visibly move from "under review" to "approved"
Minor confusion: one tester wasn't sure why they had to re-provide an address they felt they'd already given
Design
The redesigned flow
Every profile stays selectable — no disabled radio buttons, no hidden fine print
Each profile's CTA is dynamic based on its real status: "Provide D-U-N-S," "Verify again," "Manage payment method," "Request admin access"
Resolving an issue animates the profile into the Available group with a confirming snackbar
"Create a new payments profile" moved out of the radio list and into the dialog's action bar as its own secondary button, next to Cancel and the dynamic primary CTA
In Practice
Where this shows up
Google Ads, Google Play, Chrome Web Store, Google Workspace, Cloud, Analytics, and partner integrations like Reserve with Google's Compliance Requirements flow is one real entry point: partners link a payments profile to satisfy Digital Services Act requirements alongside phone and email verification.
It's the same CUJ that shaped this work: an existing partner switching payment profiles realizes the one they want needs attention before they can use it — and now sees exactly why, and what to do next.
Outcome
Aligned across Product, Design & Engineering
The redesign reached a version that Product, Design, and Engineering all signed off on.
The PM added it to the roadmap, and Engineering began design and implementation the following quarter.
Measuring Success
How we'd know it worked
Resolution pass rate — % of users who successfully resolve a profile issue from the selector
Reverification failure rate — % who abandon and create a new profile instead
Profile admin-access pass rate — % who successfully obtain admin access via the selector
Stuck rate — % who start but don't reach "Available" within a set window (e.g. 3 days)
Selection cancel rate — % who open the dialog and back out
Verification review handle time & reassignment rate across review teams