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.
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.
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.
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.
Most of my work that tackles the problems outlined above is on internal tools under NDA. There are, however, a few advertiser-facing features I worked on that are currently live, and I would like to give you a sneak peek.
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.
In addition to sharing any tab or window from our form, we wanted users to be able to point at the issue itself. If we took the route of letting them share a screen and point at their problem, they would also need a way to scroll and navigate around that screen.
Allowing users to safely mask any information they did not want to reveal to us was a big part of our solution, so we built in a highlight and redaction tool to facilitate this.
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.
To set expectations that we would be scanning their submission, we changed the CTA from “Submit” to “Next”. That meant we also had to manage the moment after they clicked: keeping them updated on what was happening, and telling them if the case needed anything more. If it didn’t, we wanted that to land as a moment of delight — the case created there and then.
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 AI agent: one that reads the account, tries the fix, and either resolves it or walks them through the fix. 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.
One row lifted out of the ledger above — the piece of context the current design throws away, and what closing it would mean.
My part is the journeys, the specification, and the shared case schema underneath them — three surfaces, three sets of platform constraints, writing to one record. Some of it has shipped; the rest is a roadmap item. Building it this way meant reaching for protocols and patterns the old form-based world had no need for.
A case is only worth creating if it arrives complete. So the flow collects what is missing inside the conversation itself — dropdowns, date pickers, file uploads rendered live in the thread instead of parked in a form the person has to go back and finish.
That turned a set of implementation details into design decisions. What does the system ask for, and in what words? How many questions can it ask at once before the exchange starts to feel like an interrogation? And when the gap is wide enough that one question at a time stops making sense, at what point do we stop asking and render a canvas of fields the person can complete in a single pass? I defined the answers to these as the interaction model, not as edge cases.
The larger half of this work sits after the case is filed.
A specialist opens a queue, picks up a case, and has to reconstruct what already happened before they can do anything useful. Everything the system watched upstream is available to them — but availability is not the same as legibility. The first question was how to use generative UI and conversational intelligence to turn that history into something shaped for reading, rather than a transcript to be worked through.
From there, the harder problem. Given everything that happened before the case arrived, what should this specialist do first — and how do we show them why it follows, so they aren’t re-deriving a troubleshooting path someone else already walked? That is where agentic plans came in: a ranked set of steps with the reasoning attached, not just a tidier version of the history.
Most of what I have designed here isn’t about making a case easier to file. It’s about what a specialist sees in the first thirty seconds of picking one up, and whether that view makes their next decision obvious.
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.
