Meta support assistant
From AI feature to full AI support system
I led two generations of AI support at Meta as the sole designer. Gen-1 had to prove the value of AI without changing the Help Center, while in Gen-2 I was able to redesign the entire Help Center and everything the assistant could do as an AI-native UX.
Gen-1 was minimal by design
Gen-1 : Start chat from home page composer
Gen-1 : New chat start screen & menu
This first iteration had two rules:
Don't redesign the Help Center to add the AI
Don't scale past three automated self service flows
This was an intentional choice.
We needed to ship something that would easy enough to prove its value before we could completely transform support with AI.
To start, the support assistant was separate from the Help Center. You would read an article, then decide to ask a question, navigating away to try your luck with AI.
This caused a UX problem: you may totally lose context and patience along the way.
The assistant didn't feel truly integrated at first
Gen-1: Start AI chat from sticky CTA on articles
Perform a game refund
Check order status
Initiate a device return
The assistant matched what you said against those three, answered with a button, and the button opened a flyout containing the same linear self-service flow that already existed. The AI was essentially pointing you to a form.
This design achieved making these actions discoverable, which solved a major pain point, and the flyout experience helped prevent losing context by keeping you on the same page, but this design was not perfect.
If you had a question mid-flow, you'd lose your place, and this design would not scale to complex support cases that required real investigation, something front-line support agents typical perform.
Gen-1 : Game refund (desktop)
Gen-1 : Order status (mobile)
Gen-1 : Device return (mobile)
The original entry point design on article, a big blue sticky button, costs you time to intent. You may notice it, decide, and then start over on the newly loaded AI page.
So, I put a chat composer right on the article, but to my surprise it tested worse than an unavoidable and visually noisy button. My team felt this was proof enough to abandon the embedded composer concept. Instead of conceding defeat, I push for an entry animation.
Before
One is a saturated button you can't miss. The other is a pill sitting in a column of body text. The test compared salience, it never reached the concept.
After
I kept the composer and solved the real problem: a radial glow entrance built from the assistant's own palette, resolving on arrival and settling out of the way. Engagement came back level or better.
Starting an AI convo was now possible from an article page, but you still needed to navigate away to actually chat. Next I would make it so that the page you land on would, in fact, be the assistant.
These decisions laid the groundwork that enabled all stakeholders to agree to a radically new approach.
Traditional UIs are naturally good at the null state. They arrange information and actions in a hierarchy that intuitively helps people understand what's most important to engage with. Most AI-first experiences throw that away and start with a blank composer with maybe some basic categorical seed prompts.
An AI job hub is different.
The page is the assistant, the composer is present and ready to stream results, but instead of an empty starting state, what you see first is ordinary UI. Once you interact with any of it the page scrolls down into the flow.
No navigation required, no context lost, no new surface to learn.
Instead of articles users land on action-oriented pages
Gen-2 : Article job hub
The article becomes a summary card near the top, with seed prompts and a route to support option beneath it.
Selecting any of them opens the flow on the same page, below the content. The article is context now, not a destination.
Your hardware gets its own job hub, with everything that could be wrong, everything you might need; opening the support flow inline.
When the system can't finish, the handoff to a person happens on the same page, carrying the session with it.
No portal, no ticket number, nobody re-explaining themselves.
Device support became
a troubleshooting center
Gen-2 : Device support page
Not every page should be the assistant. Landing pages act like doorways to get you to the right place, so beneath the composer sit curated prompt cards written against the actual reasons people come to the help center.
When we learned that the org was adopting a new automation platform, suddenly the work frontline agents did by hand could be defined once and automated, giving users, for the first time, real self service power for the majority of reasons they come to the help center.
Engineering had an idea for the UX already. I collaborated and drove the UX we ended up going with.
Before
Text responses, then widgets arriving one at a time. Even when a task needed six answers, you gave them one by one, in sequence.
After
I designed the pattern system the automations are built from. Inputs that belong together arrive together, as a form, while handling complex actions like mid-flow interruptions, and follow-up action handling.
Building trust in AI workflows
Gen-2 : AI always asks for consent with a CTA
Gen-2 : AI will never capture personal info in chat
The assistant asks the user to confirm each consequential action, made easier to engage with by displaying a CTA. It never assumes the last yes also covers the next step in the flow.
It never takes sensitive data into the conversation, like credit card numbers. I designed it to open a traditional flyout form instead; building trust and removing risk from the system.
Scaling AI automations meant automating my own design workflow
Applying the patterns to nearly every automation meant a lot of branching logic, and a team spread across global time zones. So I prototyped the UX in Cursor; building out each automation UX as an interactive prototype. Then I created a tool the team could use that would generate the draft UX of new automations without my direct involvement.
When the org was working on a system to automate the creation of these workflows more broadly, I created a Claude Code skill of my 60+ sub-patterns and UX guardrails to give them a head start, contributing to ~1 million employee hours saved.
Results and impact
95.95%
Resolution across the automated support surface
Measured on the cases the assistant could take end to end, after the second generation shipped.
3 → 21
Automations, from gen-1 to gen-2
Every action the platform supported became reachable conversationally, rather than three hand-built flows in a flyout.
↓ 17%
Global case volume
The AI prevented a significant amount of support cases, with every new supported workflow offseting support costs.
$6.5+ Million
Annual projected savings
Cost savings will continue to scale as more support worflows are added.