Interaction designer · Google Ads · Customer engagement
That covers the moment someone describes what went wrong in their own words, everything the system does to turn that into a record, and the moment a specialist opens it and has to decide what to do first. Most of this work is internal and unreleased, so this page is the honest version: the system, the thinking, and the two features you can actually see.
Advertisers don’t arrive with tidy categories. They arrive with money not moving and a guess about why. These are the kinds of things sitting behind a support case.
Policy enforcement
“my campaign just stopped and it says something about policy? i didn’t change anything”
A campaign disapproved against a policy the advertiser can’t self-diagnose. Only someone inside can confirm what actually tripped, and whether it tripped correctly.
Advertiser verification
“it keeps asking me to verify the business but i’ve uploaded the documents three times now”
Identity or business verification stuck on a sub-profile. Nothing visible in the account tells them which record is failing, or why.
Product & feed
“everything else in the feed is fine, this one product just won’t list”
A single item rejected out of an otherwise working feed. The reason is real, and it is not visible from the advertiser’s side.
Performance
“my cost per acquisition tripled overnight and i have no idea what changed”
Spend intact, returns gone. This is the one that makes an advertiser question the whole channel — and the hardest to prove from the outside.
Some of these an advertiser can resolve alone. The rest need a person inside Google to confirm the problem is real and change something the advertiser cannot reach themselves. That is what a case is for — and intake is how it gets there.
Whatever they arrived with — a policy block, a stalled verification, a cost spike, a screenshot of the error — has to become a record before anyone can act on it. Today that conversion is a form, and the form was written before the problem was.
Illustrative. Not product UI.
The category list was fixed in advance, so the closest option is often the wrong one. The two fields that would tell a specialist where to start — which entity, and what changed — aren’t asked at all. And the evidence the advertiser actually has arrives as an unlabelled file.
Getting an advertiser to a specialist is only part of what intake does. Three different people write to or read from the same case record, for three different reasons — and a design that works well for one of them can quietly cost the other two.
Most of what I design is advertiser-facing, and that is deliberate. A specialist’s throughput is decided upstream: what an advertiser is helped to describe well is what nobody has to go back and ask for. Designing the customer’s experience carefully isn’t a separate goal from making the internal tooling work — it is the main way the internal tooling gets better.
High-volume, multi-surface tooling. Customer-facing and specialist-facing, writing to one shared record.
A form asks a person to translate their problem into our categories, and then throws the translation away. The specialist who picks up the case reconstructs it from scratch — often by asking the advertiser things the system already had, or could have had. Every feature I’ve worked on attacks that gap from one side or the other: capture more of what actually happened, lose less of it in transit, and hand the specialist something they can act on without re-asking.
A case’s context accumulates as it moves through intake, and a badly designed system drops it at every handoff. The track below is the pipeline; the ledger under it is the context — carried forward, or lost.
An abstraction of the intake pipeline, not a product diagram. My work sits across the whole track — not just at the point of capture, and not just at the point of handoff. The interesting design problems are in the seams.
Which is why both of the things I have shipped attack the same number, from opposite ends: how many times anyone has to go back and ask.
A question asked later is not just an extra field. It is an advertiser sitting with a live problem — a stalled campaign, a spend curve going the wrong way — waiting on a reply to something they already answered once.
One missing field, in time
Scroll to follow the case
The case opens
The advertiser submits whatever the form let them say.
A specialist reads it
Category reads “Other”. Two of the fields they need to start were never asked.
They ask for what’s missing
Which campaign? What changed? Can you resend that screenshot, but of the right screen?
The advertiser waits
Waiting, not workingThe problem is still live the whole time — spend still not working — while they wait to be asked something they would have answered at the start.
The advertiser replies
The same detail, supplied a second time.
The case goes back in the queue
Waiting, not workingNot necessarily to the same specialist, and not necessarily next.
Work resumes
The actual fix finally begins.
Two of those seven steps are waiting, and neither of them is work. Every field the form failed to ask for adds another pair.
Shipped · Live
Need
Specialists needed to see what the advertiser was actually looking at.
Problem
Attachments arrived unusable. Wrong screen, cropped past the useful part, or a photo of a monitor. The specialist’s first move was often to ask for a better one.
What I did
Researched where in the flow the mismatch happened, then designed in-product capture at the moment of description, so the evidence is taken rather than remembered and re-supplied. I validated feasibility with engineering before the design was final, which kept the build from being rewritten.
What changed
Usable attachments went up and the “can you send me a screenshot” round trip went down. The internal estimate of specialist time returned is meaningful; I can share it in a conversation.
Shipped · Live
Need
Cases were arriving without the one field that determined how fast they could be resolved.
Problem
A static form has to ask everyone everything, which makes it long, and still misses the case-specific detail. Adding fields made completion worse without making cases better.
What I did
Designed a post-submission step where a model reads the case and asks only for what that specific case is still missing — a short, targeted follow-up instead of a longer form for everyone. I designed the waiting state too, since the model isn’t instant and an unexplained pause reads as a failure.
What changed
Fewer specialist-initiated round trips, without lengthening the form for people whose cases were already complete.
Direction · Not shipped
Everything above is a fix applied to a form. The form still assumes what it has always assumed — that a person arrives with nothing behind them and types their problem into fields we chose in advance. That assumption is the thing that is changing.
Increasingly the first thing an advertiser or a seller meets is not a form but an agent: one that reads the account, tries the fix, and either resolves it or walks them to it. Most low-complexity problems end there. Support is what happens when that fails — which means, by the time anyone asks for a person, a great deal has already happened.
Upstream
By the time someone asks for a human, the system has already watched them try. It holds the account, the campaign, the error, every step attempted, and the exact point the agent ran out of room. That is more context than any form has ever collected.
At the handoff
The person escalating has already explained themselves once. If the first thing they see is an empty form, we have told them none of it counted. The design problem is making escalation read as continuation, not as starting over.
On the receiving end
More context is only better if it arrives in an order. Dumping everything the agent gathered onto a specialist makes their job worse, not better. They need each piece at the moment it is useful, and the rest retrievable rather than resident.
My part has been the journeys, the specification, and the shared case schema underneath all of it — three surfaces, three sets of platform constraints, writing to one record. It is a roadmap item, not a shipped product, and I have kept the detail off this page for that reason.
One row lifted out of the ledger above — the piece of context the current design throws away, and what closing it would mean.
Most of what I do lives inside Google’s internal systems and isn’t public. I’ve kept this page to what’s shipped and externally visible and abstracted the rest — no internal screens, no codenames, no roadmap detail. What’s missing is the interesting part: the research behind these decisions, the flows in full.
I’d rather walk you through that properly than post a redacted version of it. If the ETS Insight team wants to go deeper, I’m glad to.
