Designing an AI-assisted PCP visit, from first text to care plan

01

Set the north star before the first release

A service can’t deliver on a brand promise without a story to measure itself against. I partnered early with our CMO and brought in my former colleagues at the design studio analogous to run an executive workshop on what was unique to 98point6. The result was Continuity Care: the belief that technology could provide consistent, smarter, empathetic, lifelong care on the patient’s terms, by listening to and learning from every encounter.

A few months later we reconvened to define the brand mark, app icon, tone, and visual language. My team used all of it to keep the product consistent with the brand and with communication design as both evolved.

02

Test whether people would trust a bot with their health

The company’s hypothesis was that the more of a text visit we automated, through natural language processing and AI-selected questions and responses, the more patients each clinician could care for. That only worked if patients would talk to the bot at all.

I created a vision framework for the bot’s character, its tone and cadence, and where it would grow over time. It aligned marketing first, and eventually everyone from iOS engineers to product managers to our board of advisors. I wrote the script with conditional logic to move a visit forward or disqualify someone before they became a patient. Once a patient gave their chief complaint, machine learning took over. There was no large language model; the AI was a targeted model that guessed the next question to ask about a patient’s symptoms, drawing on what doctors had asked patients with similar complaints.

I built the first “intro bot” prototype on an open-source SMS platform while my designer and researcher ran formative research. People were comfortable onboarding and answering symptom questions from the bot. We shipped the first patient experience on iOS, Android, and the web in four months.

The model raised a question data science hadn’t answered: how many of its questions would a patient answer before giving up? Data science had set loose thresholds for the quality and number of questions allowed. We tested it, and engagement began to fall off at around seven. That finding changed the model work. To get better signal from fewer questions, data science trained more chief complaints with more people, raising the quality of each question the bot asked.

03

Give the bot an interface of its own

The first release lived in a standard SMS-style thread, and for a while that was the point: texting a doctor felt as familiar as texting anyone else. But a column of speech bubbles offers one gesture, which is to reply, and care asks for more. A doctor needs to see the rash. A patient needs to pick a pharmacy, confirm an allergy, and find tomorrow the care plan they were given today. Every capability we wanted to give the bot had nowhere to live except another line of text, and the standard SMS interface began to limit what we could build.

So we went back to the interaction model itself. Instead of treating the visit as a transcript, we treated it as a conversation that could hand the patient what the moment called for, like a camera or a set of choices. We explored it through three lenses: extensibility, so new clinical services could arrive without a redesign; visual simplicity, so someone who felt unwell on a small screen could still find their way; and accessibility, so the visit worked for people who are deaf or hard of hearing, blind or low vision. The bar was a conversation as natural as talking to your doctor, with affordances a chat window never had.

That work became the Hammond design system: the shared language for every interface that followed, from the patient app to the clinician’s console.

04

Extend the bot beyond the visit

Continuity Care meant moving past the episodic relationship people have with primary care. With Hammond in place, Auto Follow-ups became the initiative that put the north star into practice. The bot reached out after a visit through smart push notifications, asking how the patient was feeling and bringing a doctor back in when they needed one, so care continued after the visit.

On the clinician’s side, the follow-up became part of the care plan. The doctor scheduled the check-in before ending the visit, and the patient’s answers came back to the console as a follow-up visit, with the prior diagnosis and history beside them.

Follow-ups also closed a gap in what the model could learn. Until then it saw what happened during a visit, never what happened after. Each “Better,” “Worse,” or “Hard to tell” was a signal about whether a diagnosis and treatment had worked. That data would only pay off at scale, so we built the flow to capture it from the first visit.

05

Keep the clinician in the loop

In year two we invested deeply in the clinician console. The work ran from integrating with the electronic medical record to automating SOAP notes, presenting an AI-generated differential diagnosis, and adding a seamless prescription service. The aim was clinician efficiency without trading away quality of care: the model narrowed the possibilities, and the doctor made the call.

We met data science at the points where the model met people: which questions the bot asked after a chief complaint, how the patient’s answers were framed for clinicians, and what a follow-up should capture.

The differential depended on how we exposed what the patient had said. Doctors build a differential from pertinent positives and pertinent negatives: the symptoms that support a diagnosis, and the expected ones that are absent. So the console didn’t hand clinicians a transcript. It sorted the bot’s intake by body system into what the patient reported and what they denied, the frame a physician already reasons in, with the patient’s own description and agenda at the top.

Clinicians were given prewritten responses to speed up the chat, and they typed their own anyway. They understood the business model and still chose patient care first, even in nuanced, low-risk moments. Automation had to earn its place in the conversation.

06

Grow the team around shared tenets

I hired in step with the product. For the first release, I brought on two product designers, a UX researcher with a PhD in social psychology, and a contract designer. About a year in, as the console work grew, I hired a director to lead a dedicated Clinic UX team, along with three more senior product designers and a senior UX researcher with a PhD and experience testing design experiments with role-based users. Just before I left, I hired a director to lead the Member UX team and take over my role.

As a Product & Design organization, we valued making the right things for our customers, and then validating that we were making those things right for our users—from patients to buyers to clinicians.

I co-designed our operating tenets with the Member (patient) & Clinic (clinician) UX teams once I had a grasp on the complexity of our ecosystem, the agency we held as a function, the investment the business was willing to make in research, and the role each person could play in delivering value.

07

Test ideas before a line of code

Formative research had shaped the product since the first bot prototype. As the team grew, I formalized it into a framework every team could run on its own: plan, prototype and recruit, test, synthesize, share results, and hold a retro, with clear owners across product, design, research, and UX engineering at each step.

Its premise fit the stakes. When a team had a hypothesis, quick qualitative sessions with a prototype answered it before we committed to an expensive build and deployment cycle. And where we were already confident in our patterns, we tested only the parts we weren’t sure of: a task flow, a line of copy, an affordance.

08

Hold the line where care, compliance, and the business met

In healthcare, design decisions carry obligations beyond usability. I set up a compliance process with product, marketing, and legal: anything that changed what patients could see needed both a marketing and a legal review before it shipped. HIPAA set the stakes. It was explicit in places and open to interpretation in others, so legal always had an opinion, and we showed them the work. Some calls were made once and built in, like having the bot ask what state a patient was physically in, so every visit complied with the law. Once it was running, I took my own work through it and coached my team through theirs.

Some lines were ethical rather than regulatory. I wasn’t comfortable putting the PHQ-9, a standard depression screener, into the conversation for the bot to present unmodified; it went in as is. And when leadership considered removing the doctor’s avatar so the bot would appear to run the whole visit, I argued to keep it, and it stayed. Patients deserved to know when a physician was caring for them.

Intake didn’t always give clinicians enough symptom detail, and going back to the patient slowed the visit. I pushed data science and the executive team for an expert system: rules-based follow-up questions to close that gap now. Leadership chose to have the model learn to handle it instead, a longer-term bet on the company’s value. It was a fair trade-off, and one of many where patient care, efficiency, and valuation crossed in ways design had to hold together.