2025
2025
03
03
Behavior
Behavior
Trust
Trust
The UX of uncertainty.
The UX of uncertainty.
The UX of uncertainty.
Every AI product ships with a problem built into its foundation. Not a bug. Not a missing feature. A condition that is structural, permanent, and almost universally mishandled.
Every AI product ships with a problem built into its foundation. Not a bug. Not a missing feature. A condition that is structural, permanent, and almost universally mishandled.
Every AI product ships with a problem built into its foundation. Not a bug. Not a missing feature. A condition that is structural, permanent, and almost universally mishandled.
The system doesn't always know. And most of the time, the interface pretends it does.
The system doesn't always know. And most of the time, the interface pretends it does.
The system doesn't always know. And most of the time, the interface pretends it does.
What uncertainty actually means in an AI product
What uncertainty actually means in an AI product
What uncertainty actually means in an AI product
Uncertainty in an AI system is not an edge case. It's not the thing that happens when something goes wrong. It's the baseline condition of every output the system produces.
Uncertainty in an AI system is not an edge case. It's not the thing that happens when something goes wrong. It's the baseline condition of every output the system produces.
Uncertainty in an AI system is not an edge case. It's not the thing that happens when something goes wrong. It's the baseline condition of every output the system produces.
When a model generates a response, it isn't retrieving a fact from a database. It's producing the most statistically probable continuation of a pattern, given everything it was trained on and everything in the current context. That process is inherently probabilistic. The system is always, to some degree, guessing.
When a model generates a response, it isn't retrieving a fact from a database. It's producing the most statistically probable continuation of a pattern, given everything it was trained on and everything in the current context. That process is inherently probabilistic. The system is always, to some degree, guessing.
When a model generates a response, it isn't retrieving a fact from a database. It's producing the most statistically probable continuation of a pattern, given everything it was trained on and everything in the current context. That process is inherently probabilistic. The system is always, to some degree, guessing.
This doesn't mean AI products are unreliable. It means their reliability exists on a spectrum, and that spectrum shifts depending on the input, the context, and the distance between the question being asked and the territory the model knows well.
This doesn't mean AI products are unreliable. It means their reliability exists on a spectrum, and that spectrum shifts depending on the input, the context, and the distance between the question being asked and the territory the model knows well.
This doesn't mean AI products are unreliable. It means their reliability exists on a spectrum, and that spectrum shifts depending on the input, the context, and the distance between the question being asked and the territory the model knows well.
Most users don't know this. Most interfaces don't tell them.
Most users don't know this. Most interfaces don't tell them.
Most users don't know this. Most interfaces don't tell them.
Uncertainty is not a failure state in an AI product. It's the default state. The question is never whether it exists. It's whether the design acknowledges it.
Uncertainty is not a failure state in an AI product. It's the default state. The question is never whether it exists. It's whether the design acknowledges it.
Uncertainty is not a failure state in an AI product. It's the default state. The question is never whether it exists. It's whether the design acknowledges it.
Why hiding uncertainty is a design mistake
Why hiding uncertainty is a design mistake
Why hiding uncertainty is a design mistake
The instinct to hide uncertainty is understandable. Products are supposed to feel confident. Users are supposed to trust the system. Showing doubt feels like undermining the value proposition before the user has had a chance to experience it.
The instinct to hide uncertainty is understandable. Products are supposed to feel confident. Users are supposed to trust the system. Showing doubt feels like undermining the value proposition before the user has had a chance to experience it.
The instinct to hide uncertainty is understandable. Products are supposed to feel confident. Users are supposed to trust the system. Showing doubt feels like undermining the value proposition before the user has had a chance to experience it.
But hiding uncertainty doesn't make it disappear. It transfers it.
But hiding uncertainty doesn't make it disappear. It transfers it.
But hiding uncertainty doesn't make it disappear. It transfers it.
When an interface presents an uncertain output with the same visual weight and confidence as a reliable one, the user has no way to calibrate their trust. They either trust everything equally, which leads to over-reliance and eventual disappointment, or they trust nothing, which leads to abandonment.
When an interface presents an uncertain output with the same visual weight and confidence as a reliable one, the user has no way to calibrate their trust. They either trust everything equally, which leads to over-reliance and eventual disappointment, or they trust nothing, which leads to abandonment.
When an interface presents an uncertain output with the same visual weight and confidence as a reliable one, the user has no way to calibrate their trust. They either trust everything equally, which leads to over-reliance and eventual disappointment, or they trust nothing, which leads to abandonment.
The interface has effectively outsourced its uncertainty to the user, without giving them the tools to handle it.
The interface has effectively outsourced its uncertainty to the user, without giving them the tools to handle it.
The interface has effectively outsourced its uncertainty to the user, without giving them the tools to handle it.
There is a more honest approach. And counterintuitively, it builds more trust, not less.
There is a more honest approach. And counterintuitively, it builds more trust, not less.
There is a more honest approach. And counterintuitively, it builds more trust, not less.
When a system communicates its own uncertainty clearly, users don't lose confidence in it. They gain a more accurate model of what it can do. That accuracy is the foundation of durable trust.
When a system communicates its own uncertainty clearly, users don't lose confidence in it. They gain a more accurate model of what it can do. That accuracy is the foundation of durable trust.
When a system communicates its own uncertainty clearly, users don't lose confidence in it. They gain a more accurate model of what it can do. That accuracy is the foundation of durable trust.
The difference between anxious uncertainty and calibrated uncertainty
The difference between anxious uncertainty and calibrated uncertainty
The difference between anxious uncertainty and calibrated uncertainty
Not all uncertainty communication is equal. There's a version that makes users anxious, and a version that makes them informed. The difference is in how it's framed.
Not all uncertainty communication is equal. There's a version that makes users anxious, and a version that makes them informed. The difference is in how it's framed.
Not all uncertainty communication is equal. There's a version that makes users anxious, and a version that makes them informed. The difference is in how it's framed.
Anxious uncertainty says: something might be wrong, but we're not telling you what or why. It shows up as vague disclaimers at the bottom of outputs. As generic "results may vary" language that covers everything and explains nothing. As loading states that drag on without any signal of what's happening or how long it will take.
Anxious uncertainty says: something might be wrong, but we're not telling you what or why. It shows up as vague disclaimers at the bottom of outputs. As generic "results may vary" language that covers everything and explains nothing. As loading states that drag on without any signal of what's happening or how long it will take.
Anxious uncertainty says: something might be wrong, but we're not telling you what or why. It shows up as vague disclaimers at the bottom of outputs. As generic "results may vary" language that covers everything and explains nothing. As loading states that drag on without any signal of what's happening or how long it will take.
Calibrated uncertainty says: here's what the system is confident about, here's where it's less certain, and here's what that means for how you should use this output. It gives the user actionable information, not just a disclaimer.
Calibrated uncertainty says: here's what the system is confident about, here's where it's less certain, and here's what that means for how you should use this output. It gives the user actionable information, not just a disclaimer.
Calibrated uncertainty says: here's what the system is confident about, here's where it's less certain, and here's what that means for how you should use this output. It gives the user actionable information, not just a disclaimer.
The distinction matters because users can work with calibrated uncertainty. They can decide to verify, to ask a follow-up question, to treat the output as a starting point rather than a conclusion. Anxious uncertainty doesn't give them anything to work with. It just makes them uncomfortable.
The distinction matters because users can work with calibrated uncertainty. They can decide to verify, to ask a follow-up question, to treat the output as a starting point rather than a conclusion. Anxious uncertainty doesn't give them anything to work with. It just makes them uncomfortable.
The distinction matters because users can work with calibrated uncertainty. They can decide to verify, to ask a follow-up question, to treat the output as a starting point rather than a conclusion. Anxious uncertainty doesn't give them anything to work with. It just makes them uncomfortable.
The goal is not to make users comfortable with uncertainty. It's to make them competent at navigating it. Those are different design objectives, and they lead to very different interfaces.
The goal is not to make users comfortable with uncertainty. It's to make them competent at navigating it. Those are different design objectives, and they lead to very different interfaces.
The goal is not to make users comfortable with uncertainty. It's to make them competent at navigating it. Those are different design objectives, and they lead to very different interfaces.
Designing states that hold trust without lying
Designing states that hold trust without lying
Designing states that hold trust without lying
Designing for uncertainty requires building a vocabulary of states that the interface doesn't currently have in most design systems.
Designing for uncertainty requires building a vocabulary of states that the interface doesn't currently have in most design systems.
Designing for uncertainty requires building a vocabulary of states that the interface doesn't currently have in most design systems.
It requires states that communicate degrees of confidence, not just success or failure. A binary system works for a form submission. It doesn't work for a system that can be right, mostly right, partially right, or confidently wrong.
It requires states that communicate degrees of confidence, not just success or failure. A binary system works for a form submission. It doesn't work for a system that can be right, mostly right, partially right, or confidently wrong.
It requires states that communicate degrees of confidence, not just success or failure. A binary system works for a form submission. It doesn't work for a system that can be right, mostly right, partially right, or confidently wrong.
It requires states that make the system's reasoning legible without overwhelming the user with technical detail. The user doesn't need to understand how the model works. They need to understand enough to decide how much weight to give this particular output in this particular context.
It requires states that make the system's reasoning legible without overwhelming the user with technical detail. The user doesn't need to understand how the model works. They need to understand enough to decide how much weight to give this particular output in this particular context.
It requires states that make the system's reasoning legible without overwhelming the user with technical detail. The user doesn't need to understand how the model works. They need to understand enough to decide how much weight to give this particular output in this particular context.
It requires states that invite verification without implying failure. "You might want to check this" is a very different signal from "something went wrong." The first treats the user as a competent participant in a collaborative process. The second triggers alarm.
It requires states that invite verification without implying failure. "You might want to check this" is a very different signal from "something went wrong." The first treats the user as a competent participant in a collaborative process. The second triggers alarm.
It requires states that invite verification without implying failure. "You might want to check this" is a very different signal from "something went wrong." The first treats the user as a competent participant in a collaborative process. The second triggers alarm.
It requires loading and processing states that communicate progress honestly. Not just a spinner that could mean anything, but a signal that tells the user something real is happening, that the system is working, and approximately how long that will take.
It requires loading and processing states that communicate progress honestly. Not just a spinner that could mean anything, but a signal that tells the user something real is happening, that the system is working, and approximately how long that will take.
It requires loading and processing states that communicate progress honestly. Not just a spinner that could mean anything, but a signal that tells the user something real is happening, that the system is working, and approximately how long that will take.
These states don't exist in most design systems because they weren't needed before. Building them is not a UI task. It's a product philosophy decision about how honest the interface is willing to be.
These states don't exist in most design systems because they weren't needed before. Building them is not a UI task. It's a product philosophy decision about how honest the interface is willing to be.
These states don't exist in most design systems because they weren't needed before. Building them is not a UI task. It's a product philosophy decision about how honest the interface is willing to be.
What products that handle this well have in common
What products that handle this well have in common
What products that handle this well have in common
The AI products that handle uncertainty well share a few consistent properties.
The AI products that handle uncertainty well share a few consistent properties.
The AI products that handle uncertainty well share a few consistent properties.
They treat the output as the beginning of a conversation, not the end of one. They make it easy to refine, correct, or redirect without making the user feel like they did something wrong. The uncertainty is built into the interaction model, not appended to it as a disclaimer.
They treat the output as the beginning of a conversation, not the end of one. They make it easy to refine, correct, or redirect without making the user feel like they did something wrong. The uncertainty is built into the interaction model, not appended to it as a disclaimer.
They treat the output as the beginning of a conversation, not the end of one. They make it easy to refine, correct, or redirect without making the user feel like they did something wrong. The uncertainty is built into the interaction model, not appended to it as a disclaimer.
They distinguish between what the system knows and what the user needs to know. Not every output requires a confidence score. Not every response needs a caveat. The design judgment is in knowing which outputs carry enough uncertainty to warrant explicit communication, and which can be presented cleanly because the system is reliably right in that context.
They distinguish between what the system knows and what the user needs to know. Not every output requires a confidence score. Not every response needs a caveat. The design judgment is in knowing which outputs carry enough uncertainty to warrant explicit communication, and which can be presented cleanly because the system is reliably right in that context.
They distinguish between what the system knows and what the user needs to know. Not every output requires a confidence score. Not every response needs a caveat. The design judgment is in knowing which outputs carry enough uncertainty to warrant explicit communication, and which can be presented cleanly because the system is reliably right in that context.
They use the user's own behavior as a calibration signal. If a user consistently refines or rejects certain types of outputs, the interface adapts to flag similar outputs more explicitly in the future. The uncertainty communication becomes more accurate over time because it's informed by real usage.
They use the user's own behavior as a calibration signal. If a user consistently refines or rejects certain types of outputs, the interface adapts to flag similar outputs more explicitly in the future. The uncertainty communication becomes more accurate over time because it's informed by real usage.
They use the user's own behavior as a calibration signal. If a user consistently refines or rejects certain types of outputs, the interface adapts to flag similar outputs more explicitly in the future. The uncertainty communication becomes more accurate over time because it's informed by real usage.
The common thread is that uncertainty is treated as a design material, something to be shaped and communicated deliberately, not a problem to be hidden or a disclaimer to be appended.
The common thread is that uncertainty is treated as a design material, something to be shaped and communicated deliberately, not a problem to be hidden or a disclaimer to be appended.
The common thread is that uncertainty is treated as a design material, something to be shaped and communicated deliberately, not a problem to be hidden or a disclaimer to be appended.
Uncertainty as a design signal, not a problem to solve
Uncertainty as a design signal, not a problem to solve
Uncertainty as a design signal, not a problem to solve
There's a reframe that changes how you approach this entire problem.
There's a reframe that changes how you approach this entire problem.
There's a reframe that changes how you approach this entire problem.
Uncertainty is information. It tells the user something true and useful about the output they're looking at. Treating it as a design problem to be minimized means throwing away information that the user needs to make good decisions.
Uncertainty is information. It tells the user something true and useful about the output they're looking at. Treating it as a design problem to be minimized means throwing away information that the user needs to make good decisions.
Uncertainty is information. It tells the user something true and useful about the output they're looking at. Treating it as a design problem to be minimized means throwing away information that the user needs to make good decisions.
The designer's job is not to eliminate the feeling of uncertainty. It's to make uncertainty legible: to translate a probabilistic system's internal state into something a human being can understand and act on.
The designer's job is not to eliminate the feeling of uncertainty. It's to make uncertainty legible: to translate a probabilistic system's internal state into something a human being can understand and act on.
The designer's job is not to eliminate the feeling of uncertainty. It's to make uncertainty legible: to translate a probabilistic system's internal state into something a human being can understand and act on.
That translation is hard. It requires understanding the system well enough to know when its uncertainty is meaningful and when it isn't. It requires understanding the user well enough to know how much information they can process without becoming paralyzed. It requires building interfaces that are honest without being alarming, transparent without being overwhelming.
That translation is hard. It requires understanding the system well enough to know when its uncertainty is meaningful and when it isn't. It requires understanding the user well enough to know how much information they can process without becoming paralyzed. It requires building interfaces that are honest without being alarming, transparent without being overwhelming.
That translation is hard. It requires understanding the system well enough to know when its uncertainty is meaningful and when it isn't. It requires understanding the user well enough to know how much information they can process without becoming paralyzed. It requires building interfaces that are honest without being alarming, transparent without being overwhelming.
But when it works, it produces something rare in AI products: a user who understands what they're working with, trusts it appropriately, and knows exactly what to do when it surprises them.
But when it works, it produces something rare in AI products: a user who understands what they're working with, trusts it appropriately, and knows exactly what to do when it surprises them.
But when it works, it produces something rare in AI products: a user who understands what they're working with, trusts it appropriately, and knows exactly what to do when it surprises them.
Uncertainty is not the enemy of trust. Unacknowledged uncertainty is. Design that names it, frames it, and gives users the tools to navigate it is design that earns trust in the only way that lasts.
Uncertainty is not the enemy of trust. Unacknowledged uncertainty is. Design that names it, frames it, and gives users the tools to navigate it is design that earns trust in the only way that lasts.
Uncertainty is not the enemy of trust. Unacknowledged uncertainty is. Design that names it, frames it, and gives users the tools to navigate it is design that earns trust in the only way that lasts.
Raphaël D. - Head of Product Design, designing at the intersection of AI infrastructure and human experience.
Raphaël D. - Head of Product Design, designing at the intersection of AI infrastructure and human experience.
Raphaël D. - Head of Product Design, designing at the intersection of AI infrastructure and human experience.
Design for AI
Thinking through the design problems that AI products create.
Not how to use AI as a designer. How to design for it.
© 2026 Design for AI. All rights reserved.
Design for AI
Thinking through the design problems that AI products create. Not how to use AI as a designer. How to design for it.
© 2026 Design for AI. All rights reserved.
Design for AI
Thinking through the design problems that AI products create. Not how to use AI as a designer. How to design for it.
© 2026 Design for AI. All rights reserved.