How to Design AI Experiences Healthcare Users Actually Trust

Map the ecosystem of decisions.

We start by mapping how work actually happens: who decides what, when, and with which information. This reveals where AI can assist, automate or amplify human judgment, and where it shouldn’t interfere.

• Trace decision flows: who needs what information, when, to make which choices? Which moments are repetitive, data-heavy or delay-prone (ideal for AI)? Which require context, empathy or expertise (best left human-led)?
• Define autonomy boundaries: low-risk tasks get high AI autonomy with light oversight. Medium-risk tasks get “AI suggests, human approves.” High-risk tasks get low AI autonomy with high human control.
• Surface data trust gaps: where does data quality, latency or coverage undermine confidence?
• Design interaction logic: through prompt and context engineering, define how AI understands intent, applies knowledge and communicates tone and confidence. Outline when it acts autonomously, when it pauses for input, and how it explains uncertainty.
• Design feedback loops: how the AI learns from users, what signals it collects (edits, confirmations, rejections), how those signals feed the model, and where human review is required.

We also take each pain point from Sense and run it through five evaluation questions:

• User clarity: does the user know what they need?
• AI context completeness: does the AI have enough information to help?
• Urgency: how time-sensitive is the moment?
• Disruption risk: what happens if the AI gets it wrong here?
• Risk radius: how far does a mistake cascade?

This prevents the two most common Shape-phase mistakes: using AI where it doesn’t belong, and over-automating things that should stay under user control.

From here, select the interaction pattern and mode that best fits each pain point. Assistant, guide, collaborator or executor. (The full set of patterns is in the 14 AI patterns guide.)

Map how user and AI interact across the entire journey. Not at a single moment. User actions. AI responses. Decision points. Error recovery scenarios. Where does AI initiate? Where does it respond? Where does control return to the user? When storyboard. Each frame captures four things: user goal, user action, context, design decision. Then wireframe. Low-fidelity. The priority is validating the high-level solution, not polishing pixels.

Validate the experience.

Traditional mockups can’t capture how AI behaves in motion: how it reasons, hesitates or learns from users. They can’t show how AI handles unexpected inputs, whether users understand its reasoning, or how they react when it gets something wrong.

Shape uses five types of validation that don’t exist in conventional UX projects:

• AI workflow prototypes: mimic AI reasoning, tone and confidence before the model is live.
• Wizard-of-Oz testing: a human simulates the AI behind the scenes while real users interact with the interface
• Failure mode testing: deliberately expose low-confidence or incorrect responses to understand how users want to recover
• Trust testing: can users grasp why the AI suggested something and feel confident acting on it?
• Autonomy testing: finding the right balance between AI initiative and human oversight

Each iteration helps refine prompts, context and weighting so that user feedback becomes structured, useful input for the system to improve itself.

By the end of Sense, we’ve connected the dots between what users need and what AI can reliably deliver. We know where AI fits best, what risks it carries, and what kind of experience it should enable.

A note on precision.

Nobody walks out of the design phase declaring that accuracy must be exactly 73.3%.

That precision comes later through measurement and real-world usage. What Steer defines are directional thresholds and boundaries. Is 60% accuracy acceptable? Probably not. Is 95% required? Maybe, if the task is high-risk. Is a 5% high-risk error rate non-negotiable? Possibly.

Without this conversation, teams either over-engineer or ship without clarity.

Measure and iterate.

As AI meets real-world use, the focus shifts from designing behaviour to guiding it.

• Observe real interactions to see where AI helps, hinders or confuses
• Track how new data affects accuracy and model behaviour, because as data changes, so does the experience
• Monitor for bias, drift and adoption patterns to ensure fairness and dependability
• Refine thresholds, tone and messaging as confidence grows or falters
• Keep learning safe and intentional: adjust how often the AI learns from feedback and how much human oversight is built in
• Designers, engineers and data scientists stay in rhythm, tuning prompts, flows and metrics together as patterns emerge

Every insight from Steer feeds the next Sense cycle. That’s what makes it a closed loop: listening better, designing smarter and steering with more confidence each time around.

At the end of a full Sense-Shape-Steer cycle, you don’t have ideas. You have:

• Defined AI experience scope: What the AI will do vs what it won’t, with explicit boundaries between AI responsibility and human judgment
• Validated concepts and user flows: key journeys with AI touchpoints, triggers, responses and fallback behaviours
• Success and quality criteria: agreed definitions of “good enough” for accuracy, fairness, performance and risk, plus clear indicators of failure
• Reference scenarios and edge cases: documented assumptions, risks and the situations most likely to go wrong

Running This as a Sprint

One practical way to apply Sense-Shape-Steer is as a time-boxed AI Design Sprint.

Five days. 90-120 minutes per session.

Core team: UX researcher, UX designer, product manager, AI/ML engineer. Additional stakeholders from business, engineering, compliance and subject matter expertise join as needed.

The format is flexible. Three days for simpler opportunities. Seven for complex ones.

The video walkthrough and FigJam workbook guide your team through every step: the specific questions, frameworks and scoring templates for each phase.

In the next chapter, we’ll cover the four most common mistakes teams make when designing AI experiences, and how to avoid them.

It’s tempting to ship the most impressive version of your AI feature. The one that does everything automatically. The one that wows in a demo.

In practice, users don’t trust a system that takes over on day one.

The teams that get adoption right start with the AI in a supporting role and let it earn more autonomy over time. Users grant trust incrementally, based on experience. The AI that starts by saying “here’s what I’d recommend” earns the right to eventually say “I’ve gone ahead and done this for you.”

The one that starts with “I’ve gone ahead and done this for you” never earns anything.

Most teams assume that if the AI gives the right answer, users will trust it. But research tells a different story. A 2023 PLOS Digital Health study found that poorly designed explainability can actually decrease error detection. Users see an explanation, assume the AI must be right, and stop thinking critically.

The fix is designing them properly.

Explainability done well gives users enough information to form their own judgment, not just a label that says “here’s why.” There’s a big difference between “recommended based on patient history” (vague, encourages blind trust) and “flagged because creatinine has risen 40% over 3 months, consistent with early CKD progression” (specific, invites clinical evaluation).

Most AI features give users two options: accept the recommendation or reject it.

That’s not how humans make decisions. Especially in healthcare, where the answer is rarely a clean yes or no.

A clinician might agree with 80% of an AI-generated care plan but want to adjust one medication. A nurse might trust the AI’s triage recommendation but want to bump the priority level based on something they noticed that isn’t in the data.

If the only options are “accept” and “reject,” you’re losing all of that nuance. And you’re training users to either rubber-stamp everything or dismiss everything.

Give users the ability to shape the AI’s output rather than just thumbs-up or thumbs-down it.

Every AI feature will fail. The question is whether you’ve designed for that moment or not.

Most teams don’t. They focus on the happy path and treat failure as an edge case.

In healthcare AI, failure isn’t an edge case. It’s a certainty. The model will encounter inputs it hasn’t seen before. Confidence will drop below useful thresholds. Data will be missing. The user will ask something outside the system’s scope.

The teams that design for failure build more trust than the ones that pretend it won’t happen. An AI that says “I don’t have enough information to make this assessment, here’s what I’d need” is more trustworthy than one that gives a confident answer based on incomplete data.

We typically design somewhere between 15 and 30 distinct failure states for a single AI feature. Each one gets its own explanation and recovery path.

Every one of these mistakes comes from the same mindset: designing for the AI’s capabilities instead of the user’s experience.

The AI can act autonomously. But should it, on day one? The AI can give an answer without explaining. But will users trust it? The AI can present a binary choice. But does that match how decisions actually work? The AI can ignore failure scenarios. But what happens when it fails?

Trust builds the same way it always has: gradually, through transparency, with the ability to push back, and with honest acknowledgment when things go wrong.

In the next chapter, we’ll look at why conventional UX agencies struggle with these challenges, and what to look for in an AI UX capability.

Traditional UX skills are foundational. They’re just not sufficient for AI products.

A traditional agency can design a beautiful interface for an AI feature. Clean layout, clear typography, intuitive navigation.

But when the product team asks “what should happen when the model’s confidence drops below 70%?” the agency doesn’t have a framework for answering that question.

When someone asks “how should the AI explain its reasoning to a clinician vs a nurse vs a patient?” the agency defaults to what it knows: different screen layouts. The real answer is different information architecture, different confidence displays and different levels of detail — all from the same underlying recommendation.

When the AI starts drifting after three months in production and user trust begins eroding, the agency’s contract ended at launch. There’s nobody designing the response.

Whether you’re evaluating Koru or anyone else, these are the capabilities that matter for AI UX work:

A partner who can’t speak to most of these is bringing a traditional UX toolkit to an AI UX problem. It might produce a nice-looking interface. It won’t produce a trusted AI experience.

In the next chapter, we’ll go deeper on evaluation: what to ask, what to look for, and what should make you walk away.