Support Chat
Maven Clinic

Problem
Every support question, regardless of complexity, followed the same path: a user messaged their Care Advocate and waited. Simple questions like appointment booking or provider recommendations went through the same process as complex medical or financial ones.
Behind the scenes, every message became a Zendesk ticket, triaged and answered by whoever on the 24/7 support team picked it up, often not the original Care Advocate. No self-serve, no deflection. Every interaction needed a human, at 300,000+ tickets a year and rising, which drove up cost to serve and slowed responses even for simple questions users just wanted answered fast.
Maven had no existing model for how AI should handle conversations this trust-sensitive at this scale, but it was clearly the highest-impact opportunity to apply the technology.
Designing the vision
I led a cross-functional working group (Support, Engineering, Product, Clinical), where I tested early concepts against real scenarios before committing to a direction.
We presented a 3-year north star vision to leadership. I then translated that into what was buildable now, working within Maven's existing design system.
That meant laying out the full support flow: every realistic question type a user might ask, the logic, and the decision point for AI-resolved versus human-routed. Day-1 edge cases included urgent clinical concerns, users in crisis, ambiguous questions with multiple possible intents, and the very real "unhappy paths" we had to account for.

In parallel, engineering was evaluating the build approach (3rd party vs custom internal build). I designed critical pieces of the flow to visualize the tradeoffs across the different options under consideration, work that fed directly into the vendor decision.
Constraints
This was a 0→1 build inside an already-established product, not a greenfield one. Escalation logic for sensitive financial and medical questions needed to be solid, since getting it wrong had real consequences for users.
Support and human-provider messaging had to be reconciled without confusing the user about who they were actually talking to. And Zendesk didn't disappear: tickets still existed, so I had to design the user-facing experience to account for that underlying system.

This was also a high-visibility project. Executive leadership was following it, operations stakeholders were involved throughout, a large engineering team was building it, it shipped across three platforms at once, and the data running through it was sensitive. That added a level of scrutiny to most decisions.
Beyond the Core Flow
Two additional threads of complexity ran alongside it, each with its own set of challenges.
Mental model and discoverability
The app was full of existing entry points that routed users straight to a Care Advocate, reinforcing a habit the new self-serve path had to compete with. I had to figure out how to surface Support Chat, teach people it existed, and shift behavior, without the change reading as a downgrade in a brand built on human touch.
Inbox mechanics
Support had always lived in a single message thread, styled like a text conversation. Dropping an AI into that same paradigm raised two hard questions: how to make an AI-to-human handoff feel legible inside one thread, and what “resolved” even means when AI, not a person, closes the conversation. I iterated through prototypes across two core flows, AI-solvable questions and questions that need a human, to land on an MVP that held up under user testing.

Look and feel
Most of the interface leaned on Maven's existing design system, extended where needed for new cases like sender distinction and AI-to-human handoff.
Getting there wasn't a single pass. Entry points alone went through several rounds of exploration, from subtle inline prompts to more prominent standalone entry cards, before landing on something that converted without feeling forced on users who didn't need it.
The inbox itself took even more iteration, since every version had to be tested against how it would actually feel once human messages and numerous new threads with Support Chat were sitting in the same inbox.
Landing the right tone mattered as much as the visual work, so I consulted Brand and Copy to sanity-check voice and visual direction along the way. The feature was built simultaneously across mobile and web, so I designed both in parallel from the start.

Development
I brought engineering into the design process early and often. That wasn't just walking them through visual plans, it went both ways: understanding how chat storage, keyword detection, and the AI model itself actually worked shaped decisions I made on the design side, and their callouts on feasibility shaped what I was willing to negotiate on and what I held firm on.

I stayed close to quality after handoff too. I tested the tool myself with my Product Manager, asking it real questions and evaluating whether the answers were actually correct, not just whether the UI rendered right.
I maintained an organized, annotated Figma file throughout as the project's source of truth, which engineering used directly as the build blueprint. Before release, I planned and led a 20-person pre-mortem to surface risks the team hadn't said out loud yet.
Post-MVP
Scaling Support Chat meant that I continued to design more niche handoff flows, handling specific questions like fertility treatment costs without losing conversation context, and refining discoverability through contextual entry points across the app. UI and visual fine-tuning continued alongside all of it.
As the effort evolved into its next phase under the new broader “Maven Intelligence”, with Support Chat rebranded as Assistant, I moved on to a new team but continued to be involved as the PD subject matter expert, supporting the designers who took over that space.
Outcome
The team shipped a limited internal release first to validate AI-handled and human-handoff logic before full rollout. In 2025, Support Chat shipped to all users in production with 91% deflection across 12,000+ questions in the first four months.