Shaping Patient Conversations

Intro

I already told the design side of this story in another case study — read it here if you haven’t yet.

This one is the strategy side: how I took Patient Conversations from an idea to MVP, and where I think it should go from here.

Finding the Real Value

Context

athenaOne already had a patient portal with secure messaging, and a working one-way reminder-text system. Two questions stopped me before I designed anything:

• Why build another channel when secure messaging already does something similar? Are we replacing it, or coexisting with it?
• Demand for two-way texting had been loud for years. What made now the moment to finally build it?

I needed to find the actual differentiator, not just secure messaging with texting bolted on.

What I did

• Reviewed vision work other teams had already done in this space
• Re-read notes from client conversations I’d had face to face at company events
• Tested the existing secure-messaging workflow end to end myself
• Sat down with the designers who built it to learn what worked and what didn’t

What I found

• Secure messaging required a portal login. Texting didn’t. Everyone already has it, and already knows how to use it.
• Secure messaging landed in the wrong place, for both sides. Patients hit a login wall, then filled out a structured form to reply. Staff found messages buried in a patient case’s description field, built to log requests, not hold a conversation.
• Replies took 24 to 48 hours. It functioned like email with extra steps.
• Younger patients don’t pick up calls. They’re at work, in a meeting, with their kids.

“People don’t answer phone calls, but they reply to text.”

A text waits. A phone call doesn’t.

• Two-way texting is a much harder problem than one-way. Every inbound message raises questions a reminder never had to answer: is this a known patient, is the number shared across a family, is it spam. SMS isn’t encrypted, so there are real limits on what’s safe to exchange over text.
• Adding a channel isn’t free. It’s one more inbox to manage. Staff already juggle secure chat, email, and internal tools. Clients didn’t hate the current setup. They hated the idea of one more thing to check.
• Clients were already patching this gap, and it wasn’t working. Third-party tools didn’t talk to athenaOne, so staff had to leave their workflow to check them. Patients often had to download a separate app just to reply: the same failure mode as the patient portal.

Opportunity

Every failure mode above breaks for the same reason: it asks one side of the conversation, patient or staff, to leave the environment they’re already in. Nobody had fixed that for both sides at once.

That’s the opening. Not a better version of texting: a single, native conversation surface that starts as texting, zero friction, no login, no app, and can escalate to secure chat in the same thread when the conversation needs it. Neither side ever has to leave where they already work.

The AI Question

Patient Conversations also sits inside athena’s broader AI initiatives this year because two-way messaging is a natural place to introduce AI, and getting it right here opens the door to other AI-driven improvements in patient experience. So I also studied AI-driven texting in healthcare, and did a sentiment check on how clients think about AI.

Two things stood out.

Bot fatigue is real, and trust breaks fast

• The real design question isn’t whether AI can handle a conversation. It’s how much of that conversation AI should own before handing off to a human.
• Patients extend trust to an agent based on how human and empathetic it feels. That trust is fragile. It breaks the moment the agent starts asking too many clarifying questions and turns into a phone tree.

Clients want AI that does real work, not AI for its own sake

• Most clients were open to it, some genuinely excited, especially for scheduling and triaging requests they wanted off staff’s plates.
• But the excitement had a limit. No message goes out without a person signing off, and bot conversations need to stay visible so staff can check in on them.

What that means for UX

• If the AI already asked something and the patient answered, it remembers. Asking again is exactly what turns a bot into a phone tree.
• Give staff full visibility into what the bot is saying, even when the conversation resolves without a human. They should be able to see it, steer it, and jump in if it goes bad.
• No message sends without a human checkpoint, by default. The default state is review, not autonomy. Autonomy is something a practice opts into once trust is earned, not the starting point.
• Design the “I don’t know” moment on purpose. A bot that guesses is worse than a bot that says “let me get someone for you.”

Define V1

Time constraint

We had under six months to turn the vision into v1.

Bottom line

The version needed to deliver real value while giving staff confidence they wouldn’t make a costly mistake, like violating HIPAA over text. Without that trust, no practice adopts the product.

What we decided

• Two capabilities were non-negotiable: two-way texting (no product without it) and secure chat (the compliance floor for anything that drifted into PHI).
• For who starts the conversation, I recommended practice-initiated first — it covered the highest-value moments immediately (rescheduling, pre-visit reminders), while patient-initiated brought harder problems (shared family numbers, patients not yet in the system) we didn’t have time to solve well, and AI wasn’t ready to safely absorb that volume.
• Everything else went on a “delighters” list — built only if time allowed after the core was solid.

This became our walking skeleton — practice-initiated texting with patient reply, and a path to secure chat, and it shipped as our alpha.

What I pushed out of scope: the settings page

Practices needed a way to configure things like after-hours messages and the practice info patients see in texts. Product wanted this in v1, since every practice would need to customize it.

My points:

• athenaOne’s configuration space is enormous. Before adding new fields, we’d have needed to confirm whether that data already existed elsewhere, and whether updates would need to sync back.
• There was a workaround: our alpha clients were all single-practice, single-phone-number, simple enough for our team to configure directly in the meantime.

Result: We pushed it out of alpha, with a basic settings page planned for GA. The dev team and I started researching the space in parallel, so we wouldn’t be starting from zero when it did come time to build.

What got forced in for beta: patient-initiated texting

We could push patient-initiated texting out of alpha, but not further.

• The company was already marketing an AI agent that absorbs staff workload, no version of that story works without patients texting in first.
• Leadership believed even basic Q&A (insurance, hours, parking) would meaningfully cut phone volume and add value for practices.

My point: text is lower-friction than a phone call. Once patients know they can text the practice, more volume would come in overall, even if only some of it is answerable by the agent. I expected this would add staff workload, not reduce it.

Result: My manager agreed, but neither of us could change the call at the VP level. We shipped it to ~20 beta clients. A month later, usage was nearly zero.

My read (unconfirmed by client conversations yet): enabling patient-initiated texting is a one-way door. Practices are wary of marketing it to patients at all, since revoking it later, if volume becomes unmanageable, is a worse experience than never offering it.

My reflection

I understand leadership’s logic — they want to deliver incremental value rather than wait for a “perfect” release.

But clients also weigh risk against value, and in this scenario, the risk clearly outweighed what we’d shipped.

The only way to shift that balance is a value item big enough to justify the risk. Something that turns into revenue for the practice. If the agent could hand patients a self-scheduling link, for example, that directly helps practices land more appointments — a concrete enough upside that the risk might finally feel worth taking on.

Leveraging User Feedback to Evolve the Product

Building the feedback loop

After alpha launch, the team set up multiple channels to collect feedback and measure the product from different perspectives.

What I did:

• Ran two live feedback channels directly: 1:1 sessions (30-minute calls with alpha and beta clients) for depth, and a monthly user group (a larger client cohort) for broader alignment — sharing new designs, testing ideas, and leading discussion that shaped the roadmap.
• Built a post-enablement survey as the quantifiable counterpart — data the product team could bring into leadership conversations.

I leveraged all the raw data and turned it into two readouts:

• One for sales, coaching, and training teams, giving them context on client sentiment: what clients liked, and where the known gaps were. This helped them engage prospects more effectively and provide targeted coaching to onboarded clients.
• The other focused on gaps and opportunities for our own team. It became a key reference for prioritizing V2, and our group product manager called it one of the most useful artifacts to come out of the process.

Major impact: minimizing HIPAA risk

Clients wanted a way to rule out HIPAA risk entirely, so staff could use the tool with full confidence.

Why it needed addressing now:

• Existing clients: usage was capped. Practices already enrolled were self-limiting, restricting text outreach to one or two “safe” use cases despite otherwise liking the product.
• Prospective clients: adoption was blocked entirely. Some clients told us directly they’d only adopt Patient Conversations if this option existed. Left unaddressed, this wasn’t a missed enhancement, it was lost pipeline, and it would only grow as more prospects hit the same wall.

Result: For V2, we’re building a config option letting practice admins set their own default channel, so each practice can align the tool with how they already manage compliance internally.

Major impact: usage visibility

Clients wanted a way to see usage data to inform their own actions. Historically, this wasn’t a roadmap priority — clients always ask for a dashboard, usually just to build reports for their own leadership. Heading into V2, a usage dashboard was already on the roadmap, just far down the list.

This time was different. As a paid service, clients needed usage data to justify the cost internally, coach staff on adoption, and catch engagement issues before they became retention risks. On athena’s side, that same data protects retention and gives sales a concrete proof point at renewal. So this dashboard sat at the intersection of user need and business risk, not just “another dashboard ask.”

Result: I kept it visible whenever there was a roadmap sync, until leadership saw the same risk I did. The dashboard became a top V2 priority, and our analytics team is building it now.

Major impact: pricing

Pricing concerns were showing up across every feedback channel. Alpha and beta clients had been using Patient Conversations for free. Once real pricing came into view, it was clear that clients already enrolled in alpha and beta would drop the tool over how it was priced, and prospects who saw the pricing simply walked away.

“It’s a real bummer, because I really like using it, but there’s no way we can pay this price for the size of our practice.”

Pricing wasn’t something the product team owned, but if we didn’t get that signal in front of the people who could act on it, we weren’t going to sell this product.

What we did: my PM and I teamed up to funnel that signal directly to leadership. Every time I walked out of a session with a quote like the one above, I documented it and sent it to my PM immediately.

Result: The concern was loud enough that it pushed our GA date back, giving leadership room to adjust pricing before general availability.

Closing words

Looking back, these two-plus years were chaotic and full of swings, and still the most rewarding work I’ve done. As a designer and builder, there is nothing more fulfilling than watching something go from an idea to a product people actually use, and even better, maybe making someone’s day a little easier along the way.

With this chapter closed, I’m onward to the next idea to build, the next problem to solve. Every now and then, I know I’ll think about this project, maybe new ideas will pop up on how to make it better. Maybe I’ll even write some of them down here.

That said, it’s hard to fit two-plus years of work into one case study. If you’re reading this and want to go deeper on any part of it, I’d be happy to zoom in and tell you more of the story. This case study covered the strategy side — the design side covers how the interface itself came together.