The hardest thing to build into an AI health platform wasn't the AI.
The pandemic brought Pfizer to global attention and sparked a new ambition: change lives at scale by putting trustworthy health information directly in people's hands. One of their big internal initiatives was to build an AI-powered health platform where consumers could ask questions, get real-time answers, and find clear next steps for their health concerns.
The core problem was familiar, even if the scale wasn't. People's healthcare experiences are fractured. Disconnected providers, unreliable online information, and the emotional weight of navigating a diagnosis or new symptoms make it hard to know what to do next. Pfizer wanted to change that. My team at Work & Company helped them concept, shape, and build it from the ground up, from early incubation through beta launch: Health Answers by Pfizer (Beta)
My Role
Led research strategy and day-to-day execution across the full 0-1 product lifecycle, from early concept through beta launch
Designed and introduced an agile, sprint-based research model new to Work & Company, embedding research directly into design and engineering workflows
Directed mixed methods research across 70+ qualitative interviews and quantitative surveys over 6 months
Acted as a strategic partner to the client, helping leadership navigate ambiguous product decisions grounded in user evidence
Managed and mentored a cross-functional team of researchers, prototypers, and PMs
Key InsightPeople don't want to chat. They want to know what to do next.
Pfizer came in asking for a chatbot. It was a reasonable instinct in 2023. But what users actually needed wasn't a conversation, it was orientation. When someone is managing a new diagnosis or a scary symptom, they don't want to casually chat. They want to understand what this means for them, what to do next, and whether they can trust the source telling them. Chat as a format got in the way of all three. That single insight redirected the entire product direction.
Rethinking the format before building the product
The client arrived with a clear ask: build a chatbot. It was the dominant AI interaction model at the time, and there was real executive pressure to move fast and "make it AI." But research told a more complicated story.
Users didn't struggle to ask questions. They struggled to get answers that felt relevant and trustworthy enough to act on. In a chat format, especially with longer threads, AI-generated responses became harder to verify and more prone to the kind of drift and inaccuracy that erodes trust quickly. Users with health questions in particular needed to feel anchored, not like they were improvising a conversation with an uncertain system.
The research made the case to step back from the chat format entirely and design around what users actually needed: a clear question, a trustworthy answer, and a concrete next step. That pivot shaped the product architecture from the ground up.
Designing for trust in a nascent technology
One of the core challenges of this project was building an AI-powered product at a moment when LLMs were still widely known for hallucinating. In a health context, that wasn't just a UX problem. It was a credibility and safety problem.
Research surfaced specific signals users needed to feel confident: the ability to trace answers back to named, credible sources; transparency about where the system was less certain; and a clear distinction between generated answers and verified editorial content. These weren't nice-to-haves. They were the conditions under which users were willing to engage at all.
Those findings fed directly into design decisions: confidence indicators in the UI, linked source libraries, and a content architecture that balanced real-time generated answers with pre-reviewed articles. The product's trust layer was built from the research up, not retrofitted after the fact.
An agile research model built for real-time decision-making
Most research engagements at Work & Company followed a familiar pattern: a single study, three to four weeks from kickoff to readout, delivered as a standalone artifact. That model works for many projects. It didn't work here.
Health Answers was being built fast, with design and engineering moving in parallel and product questions evolving week to week. A traditional research cadence would have produced insights that were already out of date by the time they landed.
I introduced a sprint-based research model instead. Small, focused pods. A live product or design question on Monday. A research plan written, five to ten users recruited and interviewed, and a directional synthesis delivered by the following week. Questions ranged from broad format decisions (chatbot or not) to specific UI details (how to show source confidence) to content balance (information vs. actionable next steps). Layered on top of that were periodic quantitative surveys every few months to pressure-test qualitative signals at scale.
The model gave the product team what they actually needed: not comprehensive research reports, but timely, specific, directional answers they could build from immediately.
See next project
Google’s investment in the health of the web and web creators →