Why I’d rather design AI features that hand clinicians finished work to accept than a conversation to have, and 2 calls we made about our AI patterns while the use cases are still forming.
Most conversations about AI in our product still start with chat: a text box and a clinician typing back and forth with an assistant. In a 1:1 this week, one of my design leaders and I got into what our first AI features should feel like, and I said something I want on the record. I don’t see a future where clinicians spend much of their day going back and forth with an agent. I see one where the agent has already done the work in the interface, and the clinician’s part is a simple tap or click to accept it.
That’s why I’ve started to wonder whether chat is the wrong word for what we’re building. The word sets expectations for the team as much as for the clinician. If we call it chat, we’ll design a conversation, and conversations take time that clinicians don’t have between sessions. I’d rather think of it as a springboard: something mostly passive that has the next step ready when the clinician gets there.
If we call it chat, we’ll design a conversation, and clinicians don’t have time for one between sessions.
This is a step back from a debate I wrote about in Issue 23, where I changed my mind twice about how many chats a product should show. That debate took chat as the container. I’m less sure of the container now.
There are still places where a back-and-forth is the right shape, and we’ll learn the most by trying them in beta. The same design leader also gave me a floor I agree with. For a first assistant, the core question is whether you can ask it something and get a good answer, and the rest is extra. A good answer earns the trust that a one-tap accept depends on later.
Two calls came out of the week.
The first AI feature to ship sets the standard. Whichever feature reaches beta first becomes the pattern everyone else copies, whether we bless it or not, so we’re treating it that way. The team building it will feed what they learn into our AI UX playbook. A small, focused team won’t have thought through how its pattern interacts with every other surface in the product, and that isn’t their job, but the foundation they lay is reusable, and the rest of us can build the connections.
Don’t codify the playbook yet. The design leader who keeps that playbook described the hard part to me. It’s a mix of examples we’ve shipped and the weekly sessions where we give AI-specific feedback, and the use cases that keep coming up are one-off features, which makes a system hard to build. My call was to hold off on evolving it until the roadmaps are clearer. Before we codify a pattern, we need to be able to answer what it looks like, how it functions, and what goes in and what comes out. The current version is good enough for now.
One more piece of evidence that the word matters came from a research plan this week. The guardrail for a clinician survey was to never describe the assistant as a general chatbot dropped into the product, because it’s built around their practice, and the word in the question shapes the answers you get back.
I don’t have the better word yet, and I’d love suggestions. The measure I’m holding us to is how little of a clinician’s time it takes to get the work done.