There are two ways designers engage with AI right now. The first is using AI as a tool to do design work -- the territory I cover in most of what I write. The second is designing AI as a product: building experiences where the AI itself is what users interact with, where its outputs are what users act on, and where the design decisions determine whether those interactions are trustworthy, comprehensible, and honest. The second territory is more complex, and the design community has been slower to develop clear frameworks for navigating it.

The trust problem is a design problem

AI systems make mistakes. They make them in ways that are often opaque -- not the clean, visible errors of a form validation failure, but the subtler failures of confident-sounding output that is wrong, or recommendations that are subtly biased, or outputs that reflect the limits of training data in ways users cannot see. The design challenge is to build experiences where users can develop calibrated trust -- trusting the system appropriately, neither over-relying on it nor dismissing it -- without requiring them to become experts in how AI works.

This is genuinely hard. The instinct in product design is to communicate confidence and smooth over uncertainty. A product that frequently says 'I am not sure about this' feels broken, even when that uncertainty is honest and appropriate. The design work is finding ways to communicate confidence levels that are calibrated, contextually appropriate, and do not undermine the user's ability to engage with the product usefully.

Designing for error states that are not binary

Traditional UI error states are binary: something worked or it did not. AI errors are not like that. An AI-generated recommendation might be fifty percent right, or right in aggregate but wrong for this specific user, or technically accurate but missing the context that would make it useful. Designing for this requires a different approach to error communication -- one that distinguishes between 'the system failed' and 'the system produced output that requires judgement to apply'.

I have seen this handled well and badly. Handled well, it looks like: surfacing the basis for a recommendation alongside the recommendation, so users can assess whether that basis applies to them. Handled badly, it looks like removing that context entirely in the name of simplicity, producing a recommendation that appears authoritative but is not.

Empty states in AI products are also different. When an AI has no good answer, what it says and how it says it matters. Admitting the limits of what the system can do is not a failure -- it is an honesty design decision. The temptation to generate a plausible-sounding response rather than acknowledge uncertainty is one that product teams need to resist explicitly and designers need to build against.

Explainability as a design requirement

For consequential decisions -- medical, financial, legal, employment -- users have a right to understand why an AI system produced the output it did. This is increasingly a regulatory requirement in many markets, but it should be a design requirement regardless of regulation. Explainability is not just about compliance. It is about the user's ability to exercise informed judgement, to override the system when they have information it does not, and to identify when the output is inappropriate for their situation.

Designing explanations that are useful without being overwhelming is real work. A technical explanation of why a model produced a particular output is not useful to most users. A plain-language summary of the key factors that drove the recommendation, with an indication of how confident the system is in each, is. The design challenge is making that distinction correctly and expressing it in a way that works for the specific user and context.

What responsible AI design looks like in practice

The practical checklist I work through when designing AI-facing features includes: Have we communicated what the AI can and cannot do before the user relies on it? Have we designed for the cases where the AI is wrong? Have we given users a meaningful way to correct or override AI outputs? Have we been honest about uncertainty in a way that is calibrated rather than either hidden or exaggerated? Have we considered which user groups might be systematically disadvantaged by how this AI works?

That last question is one designers often avoid because it is uncomfortable and because the answers require engaging with technical decisions that feel outside design's remit. But if the product produces worse outcomes for particular user groups, the UI that presents those outcomes is part of the problem. Responsibility does not stop at the interface.

Designing AI products responsibly is not a constraint on good design -- it is a part of it. The same principles that make any product trustworthy apply here: honesty, clarity, user control, and appropriate transparency about what the system is and is not. The AI context adds complexity and raises the stakes. It does not change the underlying design obligation.