You built the AI. Did you design the experience?
by Graphite Digital 22 June 26An HCP between consultations has perhaps ninety seconds to interact with a digital tool before their next patient. If your AI product cannot earn its place in that window - not just functionally, but intuitively - it will not survive contact with their working day. No amount of model sophistication changes that constraint.
This is the sentence that tends to be missing from pharma AI product conversations. There is significant energy going into what these tools can do: personalised dosing support, treatment pathway guidance, real-world evidence summaries, adherence tools for patients. The clinical logic is sound. The underlying technology has matured considerably.
But the question of whether an HCP can actually pick it up and use it in context — without training, without patience, without a help document — is treated as a finishing problem rather than a foundational one.
The part of the product that determines whether it gets used
Many pharma AI products are designed from the inside out. The team starts with what the AI can do, builds a product architecture around those capabilities, and then creates an interface to surface them. The interface, in this sequence, is the last thing designed and the first thing the user encounters.
That inversion matters even more with AI than it does with conventional digital products. A standard form or content page either works or it does not. An AI product introduces a different category of challenge: the user must form a mental model of what the system knows, what it is doing, and how much to trust its output. If the interface does not actively support that through clear framing, appropriate confidence signalling, and honest handling of uncertainty, users will disengage. Not because the AI is wrong, but because they cannot tell when it might be.
Explainability is the design problem that pharma AI products most consistently underestimate. It is not enough to surface a recommendation. The interface must make it legible: where did this come from, what is it based on, and why is it relevant to this patient or situation. HCPs are trained to interrogate clinical information. An AI product that does not anticipate that need will be abandoned, not trusted.
The regulatory design trap
There is a structural pressure specific to pharma that compounds this challenge. MLR and compliance review processes are designed to manage risk in the content layer. The claims, the references, the balance of information. They were not designed with AI product interfaces in mind.
The practical consequence is that interfaces get flattened. Disclaimers multiply. Confidence signals are removed because they imply a level of clinical authority legal teams are not comfortable with. Interactive elements are stripped back. What enters the review process as a designed experience often exits it as a document.
This is not an argument against regulatory rigour. It is an argument for engaging design and legal earlier, together, and with a shared understanding of what the interface needs to do. The constraints are real. But they are also, in many cases, negotiable. If the design rationale is made explicit and the risk is properly understood rather than reflexively avoided.
Cognitive load is not a UX detail
Beyond explainability, the interface challenge in pharma AI is largely a cognitive load problem. These products are used by people who are already operating at capacity. Every additional decision, every piece of unexplained information, every ambiguous interaction point has a cost that is higher in this context than in almost any other.
Good interface design for AI in this environment means reducing the number of decisions the user has to make, not increasing them. It means progressive disclosure — showing what is relevant now, making more available on demand. It means designing for interruption: the HCP who puts the product down mid-interaction and returns to it three days later should not have to reconstruct where they were or what they were trying to do.
It also means designing error states and edge cases with the same care as the primary flow. An AI product that handles uncertainty badly, for example, overclaiming or going silent when it does not have a confident answer, destroys trust quickly. The interface needs to model intellectual honesty, because that is what HCP users expect from clinical tools.
What a different starting point looks like
None of this requires new technology. It requires a different sequencing of decisions in the product development process.
The interface design work should begin with the user context, not the AI capability.
What is the HCP or patient trying to accomplish?
In what conditions?
With how much time and attention available?
What do they need to trust the output enough to act on it?
Those questions should shape the product architecture, not inherit it.
That means design and clinical working together from the start, rather than design being handed a specification to skin. It means testing with real users in real conditions before the interface is treated as finished. And it means someone in the room asking, consistently, whether the product is earning the user's attention or assuming it.
The question worth taking back
Most pharma AI product post-mortems, when engagement falls short of projections, focus on awareness, adoption incentives, or content quality. Those are real factors.
But the more uncomfortable question is whether the product was actually usable by the people it was designed for. Not in a test environment, but in the ninety seconds between consultations.
If the answer is uncertain, the interface is probably where the work needs to happen.
