Meta Support Assistant V1
Staff Product Designer · Meta · 2024–2025
Meta Support Assistant V1 — 350,000 users, 95.95% deflection
Role: Sole Product Designer
Surface: meta.com/help
Period: 2024 design → October 2025 (1% rollout) → December 2025 (100% en-US)
Audience: Meta Quest and Ray-Ban Meta device owners
Search was the wrong answer to the wrong question.
Meta Support Assistant is Meta's AI-powered customer support experience for Meta Quest VR headsets and Ray-Ban Meta smart glasses — the first AI in the RL support funnel. Before it existed, a device owner with a broken headstrap, a billing question, or a return request had one path: a static help center, a contact form, and a wait for a human agent.
A user on a help center article with a broken device isn't looking for more content. They have an action-oriented question and they need it resolved. Replacing search with a conversational entry point was a bet on a different navigational paradigm entirely. One where the AI meets users where they already are, in the article, at the moment of intent.
The experiment data at 25% rollout made it feel real. Digital Refund completions were running at high rates with near-perfect no-escalation quality. Users were finding the automation panel inside the chat, completing a self-serve refund, and when they needed a human, transferring to a live agent in the same session, same window, same conversation thread. No re-explaining. No context loss. Before December, before 100% rollout, the architecture had already proved itself.
This is how it got built.
The problem
Reality Labs had no AI-powered self-service support. A device owner with a cracked Quest headstrap, a billing question, or a return request had one path: navigate a static help center, fill out a contact form, and wait for a human agent.
Support cost scaled linearly with user growth. Agents spent disproportionate time on common, repeatable issues. Search was failing quietly. High abandonment, low NPS, no resolution. The funnel was linear and the user experience was indifferent to intent.
┌─────────────────────────────────────────────────────────────────┐
│ [SCREEN — META VISUAL SYSTEM] │
│ Before: old SIF taxonomy form │
│ Long category list, generic help topics, no device awareness │
│ Caption: "The experience before. No AI, no context, no path." │
└─────────────────────────────────────────────────────────────────┘
The system
Meta Support Assistant isn't a standalone product. It lives at meta.com/help/support/assistant — inside the RL Help Center, which itself is a section within meta.com, Meta's primary marketing and commerce website for purchasing Quest headsets, AI glasses, and other hardware.
That three-level context shaped every visual decision. meta.com is the outer shell — a 1440px centered layout with Meta's persistent site navigation. The Help Center (meta.com/help) is a distinct section within it, with its own information architecture, article library, and support flows. The AI assistant lives within the Help Center. All three layers share the same site nav, the same centered page width, the same visual system.
The AI appears in two places: on the Help Center landing pages as the primary entry point replacing search, and embedded directly on article pages where users most commonly arrive from Google. Both entry points feed the same full-page AI conversation experience at the assistant URL.
┌─────────────────────────────────────────────────────────────────┐
│ [DIAGRAM] │
│ System overview — 3-level URL hierarchy │
│ meta.com (outer shell, 1440px) → │
│ meta.com/help (Help Center) → │
│ meta.com/help/support/assistant (AI surface) │
│ Site nav visible at all levels │
│ Callout: "Most full-page AIs go full-viewport. │
│ This one couldn't." │
└─────────────────────────────────────────────────────────────────┘
Build or buy
Before a single screen was designed, the team evaluated a third-party AI support vendor that had caught attention at the leadership level. I led the UX evaluation.
The vendor had two genuinely impressive things: a clean authoring admin that let non-engineers spec automations in plain document syntax, and a content gap detection pattern that fed a self-perpetuating knowledge flywheel. Both were real. But the user-facing experience was a lightly-skinned chat, on-rails and low customization, and when a flow needed user input, it removed the composer entirely. That killed control, blocked clarifying questions, and ruled out the precise interaction patterns we needed for accuracy-sensitive inputs like shipping addresses and account verification.
The more decisive argument was economic. The vendor's main defensible asset was its authoring admin, and AI-driven coding meant we could replicate it in a few months and surpass it after that. Once that landed, the case was over.
I walked the rationale through multiple levels from PM to director, aligned with our business stakeholder who had already seen what we were building and wanted the first-party direction, and the decision held. We built.
"With how cheap engineering would be for building out that system with AI, it ultimately made this decision easy."
The architecture: AI as router, fly-out as resolver
The first design problem was categorical: what is this surface?
The answer was a full-page takeover. Not a side panel, not a floating overlay. When a user triggers the AI from an article, the AI is the primary surface. The article isn't.
The component library was built from scratch alongside the interaction model: chat surface, message bubbles, automation cards, escalation UI, feedback affordances, inline citations. Every AI response cited the source article — trust baked in, not added after. Every failure mode had a designed surface: AI confidence too low, content gap, action blocked, downstream system error. When users reached the limit of what the AI could handle, the live-chat handoff preserved the full conversation context. The agent inherited everything. No "tell me your problem again."
The V1 interaction model:
- AI detects user intent from conversation context
- For conversational questions: responds inline with citations grounding the answer in the source article
- For actionable requests: detects intent → surfaces a button → opens a fly-out card with the self-serve flow
The fly-out wasn't the ideal long-term architecture. It was two interaction models in one product, conversation in the chat and a form-based flow in the panel. I knew it. The fly-out was the right call for V1: deterministic, buildable in the window, and something the team could build confidence in before shipping fully conversational automation at scale.
┌─────────────────────────────────────────────────────────────────┐
│ [FLOW MODULE — META VISUAL SYSTEM] │
│ Scripted cursor plays path through article → AI opens → │
│ intent detected → fly-out opens │
│ Phase 1: autoplay on scroll entry, plays once │
│ Phase 2: "Try it yourself" — user drives │
│ Replay button after completion │
└─────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────┐
│ [VIDEO CLIP — AUTO-PLAY ON SCROLL ENTRY] │
│ Intent detection → "Start refund" button appears → │
│ fly-out opens — 4 seconds │
│ Pauses on exit, replay button after completion │
└─────────────────────────────────────────────────────────────────┘
Why the handoff had to stay in one window
The engineering leader overseeing a parallel AI effort had already made his call: when a user needed a live agent, the conversation handed off to a new window, a new session, a new chat instance. Clean separation between AI and human. Defensible for his product.
For RL Help Center it was the wrong call. I built the comparison to show why.
Three differences that changed everything:
The device. Over 60% of RL Help Center users are on mobile. A new window on mobile isn't friction, it's a broken experience. An employee filing an IT ticket is at a desk. A consumer trying to return a Quest headstrap is on their phone, probably frustrated, and definitely not expecting to manage multiple browser tabs.
The followup model. Internal IT generates tickets in a case management portal. Employees are expected to return, track status, and manage the thread. RL Help Center followup happens via email. Users aren't consistently logged in, there's no portal for them to return to, and there's no expectation that they'll manage an ongoing case thread. Continuity has to live in the conversation, not in a system the user will never re-enter.
The contract with the user. An internal employee filing an IT ticket expects process. A consumer trying to resolve a device issue expects resolution. Those are different relationships and different obligations.
The engineering leader agreed. The in-session transfer shipped. Same conversation, same window, same thread, from AI answer to automation to live agent without the user re-explaining a single thing.
Google's customer service AI still doesn't handle the handoff this way. And they still don't touch automations.
┌─────────────────────────────────────────────────────────────────┐
│ [DIAGRAM] │
│ Side-by-side comparison │
│ Left: Internal IT — desktop, portal, case management, process │
│ Right: RL Help Center — mobile, email, consumer, resolution │
│ Three labeled differences: device, followup model, contract │
└─────────────────────────────────────────────────────────────────┘
Digital Refund — the full arc
The V1 automation scope was three self-serve flows: Digital Refund, Order Status, and Return/RMA, all on the fly-out paradigm. Each handled a different backend: refund processing, order lookup, return logistics. All three shared the same user-visible interaction model — pattern reuse across backends equals lower cognitive load for users and faster engineering velocity. The V1 fly-out language became the substrate V2 redesigns from.
The Digital Refund flow started as a transparency problem. The original self-service experience didn't show you which games you owned but weren't eligible for a refund. You'd enter the flow and hit a wall with no explanation.
The redesign showed everything: eligible games clearly surfaced, ineligible games labeled with context, and your full purchase history when nothing was eligible. Most designers would have hidden the ineligible games. We showed them. If the answer is no, the user deserves to know why.
No-escalation rates were high. But Digital Refund was still the single largest driver of live agent contacts in absolute volume. High deflection on a high-volume flow still means a lot of cases. The business saw low-hanging fruit.
The ask: drive escalation down further and close the gap between what self-service offered and what agents could do. Agents had discretion to offer exceptional refunds on games past the return window. The self-service flow didn't.
The solution wasn't a new category. It was a label. Games past the return window that qualified for a one-time courtesy refund appeared in the eligible section with a distinct label: courtesy refund. Same placement, same flow, same paradigm. Just a signal that this refund was different in nature from a standard one.
The label did two things at once: it gave something away, and it communicated that this wasn't the default. The word courtesy carries the right weight. It mirrors agent language, implies goodwill, and signals that this isn't a guarantee available next time.
┌─────────────────────────────────────────────────────────────────┐
│ [SCREEN — META VISUAL SYSTEM] │
│ Game library — three states side by side │
│ 1. Eligible (standard) │
│ 2. Eligible with courtesy refund label (CS1 blue pill badge) │
│ 3. Ineligible (grayed, "Not eligible" label with context) │
│ Zoom callout on courtesy refund label at 2x │
│ Rejected alternative annotation: "What a new category │
│ would have looked like — and why we didn't." │
└─────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────┐
│ [VIDEO CLIP — AUTO-PLAY ON SCROLL ENTRY] │
│ Full Digital Refund flow │
│ AI conversation → intent → button → fly-out → │
│ game selection → courtesy refund label → confirm → │
│ conversation resumes — 5 seconds │
└─────────────────────────────────────────────────────────────────┘
The entry point evolution
Before the AI existed, the article page had one path to support: a button in the right rail on desktop, tucked below the article on mobile, that linked to the Support Intake Flow.
Phase 1 — Launcher: Replaced the button with an AI launcher in the same location. Desktop kept the right rail position. Mobile got a sticky footer, visible on load, hiding on scroll down, reappearing on scroll up.
Phase 2 — Composer experiment: Replaced the launcher with an embedded composer. Initial data was counterintuitive. The original button outperformed the composer. But the comparison wasn't fair. The button was a visually dominant signal. The composer was intentionally quiet. I wasn't seeing a paradigm preference. I was seeing an attention problem.
The fix: An entry glow, a radial rotating gradient in Meta brand colors that appeared on load. Not aggressive. Not persistent beyond its moment. A signal that said this is here in brand language rather than copy or chrome. Adoption improved. Then I added article-aware seed prompts — pre-loaded questions derived from the article content, shaped by what users in that context were most commonly pivoting toward.
┌─────────────────────────────────────────────────────────────────┐
│ [BEFORE/AFTER SLIDER] │
│ Left (Before): Get Support CTA button in right rail │
│ Right (After): Embedded composer with entry glow + seed pills │
│ Same article page, same scroll position │
│ Desktop and mobile both shown │
└─────────────────────────────────────────────────────────────────┘
What user testing actually changed
┌─────────────────────────────────────────────────────────────────┐
│ [3 EXPANDABLE CARDS] │
│ │
│ Card 1 — Finding 01 · Entry point │
│ "Search vs AI — three paradigms tested" │
│ Visual: Blended · CTA · Full AI ✓ comparison │
│ Expand: blended had perception baggage, full AI removed it │
│ │
│ Card 2 — Finding 02 · Citations │
│ "How to show your sources" │
│ Visual: Link row · Snippet · Full article fly-out ✓ │
│ Expand: snippet felt disjointed, full article won │
│ │
│ Card 3 — Finding 03 · Flow │
│ "Article to automation had too many steps" │
│ Visual: 5 steps crossed out → seed prompt pill → fly-out ✓ │
│ Expand: surgical fix on Digital Refund article only │
└─────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────┐
│ [SCREEN — META VISUAL SYSTEM] │
│ Digital Refund article — seed prompt pill │
│ Before: generic composer │
│ After: "Request a refund" pill above composer │
│ Annotation: 5 steps → 2 steps │
│ Mobile only — that's where the problem was felt │
└─────────────────────────────────────────────────────────────────┘
The rollout: 1% to 100%
The Meta Support Assistant launched at 1% in October 2025. By December 2025, it was 100% en-US.
During the rollout window, a weekly QA cadence surfaced and resolved 38+ critical UI/UX issues before they compounded. That cadence wasn't review theater. It was a discipline that let us iterate on real production data in near-real-time while the system was live.
In the first two weeks of December, three targeted changes to the Support Intake Flow handoff card moved the referral-to-completion rate by 35% relative, from launch week through peak performance two weeks later. At the peak, hundreds of additional users in a single week reached a human agent who otherwise would have dropped off. The launch-week rate never returned in the following 12 weeks.
┌─────────────────────────────────────────────────────────────────┐
│ [SCREEN — META VISUAL SYSTEM] │
│ SIF handoff card before/after │
│ Before: long confusing taxonomy form │
│ After: collapsed to current step, remaining fields │
│ highlighted, contextual copy visible │
│ Three specific changes annotated by name │
│ Caption: "+35% referral-to-completion rate" │
└─────────────────────────────────────────────────────────────────┘
The component system traveled beyond Meta Support Assistant. Two teams adopted it: a recruiting AI product and an alumni portal's AI integration. One team used the Figma file as a design reference and rebuilt from scratch. The other took the core components directly and reworked them as a head start.
"Enabled the Alumni and Careers Portal teams to build their own AI assistants for external users." — Product Manager, 2025 YE peer review
What shipped
350,000 users. 500,000+ conversations. 95.95% non-escalation rate. 17% global case volume reduction. Multimillion-dollar annual savings projection.
┌─────────────────────────────────────────────────────────────────┐
│ [STAT MODULE] │
│ Three animated count-up numbers on scroll entry │
│ 350K+ users · 500K+ conversations · 95.95% non-escalation │
│ CS1 blue accent fires on 95.95% only │
│ Staggered: 0ms / 200ms / 400ms delay │
│ easeOutExpo · 1.8–2s duration · replay button after │
│ │
│ Below (static, smaller): │
│ 17% global case volume reduction │
│ Multimillion-dollar annual savings projection │
└─────────────────────────────────────────────────────────────────┘
Digital Refund alone ran tens of thousands of silent self-serve refunds in the first 90 days at 96.9% no-escalation quality — including users who hit the eligibility wall, understood the answer, and didn't escalate. That 96.9% includes the disappointment state. It held.
The seam
V1 worked. But the production data revealed something.
Users who engaged with the AI and then needed to complete an action crossed a seam: they finished the conversation, then entered the fly-out card, then encountered a different interaction model. Two mental models in one product. Some users completed the automation. Some dropped off at the transition.
The fly-out abstraction layer that made V1 shippable was now the friction point.
The design question wasn't how do I fix the fly-out. It was what would this look like if the action happened inside the conversation?
That question is what V2 is built to answer.
┌─────────────────────────────────────────────────────────────────┐
│ [DIAGRAM — intentionally sparse] │
│ Conversation surface │ crack/gap │ Fly-out panel │
│ ─────────────────────┤ ├───────────────────────── │
│ Chat thread │ │ Form fields │
│ AI message │ ↕ │ Input steps │
│ User message │ │ Submit button │
│ │
│ Annotation: "drop-off zone" at the crack │
│ Keep this light — it's the cliffhanger, not a full diagram │
└─────────────────────────────────────────────────────────────────┘
What this demonstrates
This was a ground-up bet on a navigational paradigm that didn't exist yet in consumer support. No template, no inherited system, no prior surface on meta.com to build from. The work that mattered most wasn't any single screen — it was the argument that the right answer to "how do I help a user who's frustrated on a help center article" isn't a better article. It's an AI that meets them there, resolves their problem, and hands them to a human if it can't — without ever making them start over.
The design decisions that proved hardest were the ones that required holding a position. The in-session agent handoff, contested and ultimately right. The fly-out as V1 architecture, deliberately not the final answer but the right call for the window. The entry glow, a counterintuitive fix to a counterintuitive data result. The courtesy refund label, a word that does more work than any new feature could have.
Seven signals across two years of work — from the paradigm shift to trust as substrate — are explored in the cards below.
┌─────────────────────────────────────────────────────────────────┐
│ [7 ICON CARDS — signals grid] │
│ │
│ ① Zero to production ② Navigational paradigm shift │
│ ③ Design judgment ④ Principled rationale │
│ ⑤ Business partnership ⑥ Experimentation as method │
│ ⑦ Trust as foundation │
│ │
│ Each card: icon + title + 1-line summary visible │
│ Click → expand to full dialog with detail + "The rule" │
└─────────────────────────────────────────────────────────────────┘
Component explorer
┌─────────────────────────────────────────────────────────────────┐
│ [COMPONENT EXPLORER — META VISUAL SYSTEM] │
│ Scrollable shelf of shipped components │
│ │
│ Five categories (tab or filter pill navigation): │
│ │
│ Conversation surface │
│ AI message bubble · User message bubble │
│ Thinking state (shimmer) · Citation badge (5 states) │
│ │
│ Automation layer │
│ Fly-out card — open state │
│ Game tile — eligible · courtesy refund · ineligible │
│ │
│ Escalation + handoff │
│ Live agent handoff card · Context summary passed to agent │
│ │
│ Trust layer │
│ Failure state — AI confidence too low │
│ Content gap · Action blocked · Citation fly-out │
│ │
│ Entry points │
│ Right rail launcher (desktop) │
│ Sticky footer composer (mobile) │
│ Seed prompt pills · Entry glow moment │
│ │
│ Each component: name, state variants, governing rule │
│ Built in Optimistic font + Meta color system │
└─────────────────────────────────────────────────────────────────┘
The extended walkthrough covers the VP review, the entry point experiments in full, and the V2 vision that V1 production data made inevitable.
Visuals checklist
- [ ] Before: old SIF taxonomy form — Meta visual system
- [ ] System overview diagram — 3-level URL hierarchy, 1440px constraint
- [ ] Internal IT vs RL HC comparison diagram
- [ ] Game library — 3 states with courtesy refund label + rejected alternative
- [ ] Flow module — article → AI → fly-out (scripted cursor + try yourself)
- [ ] Video clips (×3) — fly-out open, full refund flow, handoff
- [ ] Before/after slider — Phase 1 CTA vs Phase 2 composer + entry glow
- [ ] Digital Refund article — seed prompt pill, 5→2 steps annotated
- [ ] SIF handoff card before/after — 3 changes annotated
- [ ] Stat module — 350K / 500K+ / 95.95% count-up
- [ ] Seam diagram — conversation / gap / fly-out, sparse
- [ ] 7 icon cards — signals grid with expand dialogs
- [ ] Component explorer — 5 categories, Meta visual system