Designing for AI Is Nothing Like Designing for SaaS

I've watched good product designers struggle with AI products in a way that surprised me.

These weren't junior designers. They had shipped real products, run real user research, and built things people used every day. But when the underlying technology shifted from deterministic software to AI, something kept going wrong. Users would trust the product in one session and quietly abandon it two weeks later. Error states no one planned for would appear in production. Features that looked great in demos would fall apart with real users.

It took a while to figure out what was happening. The design process wasn't broken. The instincts were wrong.

Traditional software does exactly what it's told. The output is predictable. Design for those products is fundamentally about clarity: make the interface obvious, reduce friction, match the user's mental model. If something breaks, there's a bug. Fix the bug.

AI products don't work that way. The system interprets inputs and generates its own response. The output is probabilistic. That single change cascades through every design decision in ways most teams don't see until they're already stuck.

I've been designing agentic AI products for a few years now. Here are the three things that changed how I think about the work.

Trust Is Not a Feature You Design In

In SaaS, trust is assumed. The calculator gives the right answer. The export button exports. You earn trust once by not breaking things, and then it just exists.

In AI products, trust has to be rebuilt every interaction. Because the system can be wrong in ways that aren't obvious. Not a crash or a 404 error. A confident-sounding answer that's slightly off. Users feel this before they can name it. They start verifying outputs in a second tab. They stop relying on the product. Then they stop using it.

The design work here is invisible but constant. It's showing confidence levels instead of presenting everything with equal certainty. It's making the AI's reasoning visible alongside the conclusion. It's giving users a moment to intervene before an action happens. A pause. An override. A way to redirect.

One pattern that works consistently: surface the "why" alongside the "what." When an AI recommendation includes a brief explanation of how it got there, users push back productively instead of either accepting the output blindly or rejecting it entirely. The explanation doesn't need to be technical. It just needs to be honest about its own limits.

What doesn't work: a feedback button. Users rarely click it. What they need is feedback woven into the normal flow. A one-tap way to say "this was wrong" at the moment it matters, not buried three levels deep in a settings panel.

Error States Are Not Binary

In traditional software, error handling is contained. Something failed, show a message, offer a recovery path. The failure modes are known in advance. You can design for all of them.

AI error states don't work this way. They sit on a spectrum, and most of them don't look like errors at all.

The most dangerous AI failure mode isn't a crash. It's a plausible-sounding answer that's quietly wrong, delivered with full confidence, that nobody catches until real damage is done. No red banner. No toast notification. The system just gave bad output and moved on.

Designing for this requires rethinking what an error state even is. There are at least four distinct failure modes that each need their own interface response:

Confidence thresholds. When the AI isn't sure, say so. A legal research tool that says "I found relevant cases but I'm not confident these are the most recent precedents, verify before using" is more useful than one that presents uncertain results as settled fact. Acknowledging uncertainty isn't weakness. It's accuracy.

Fallback logic. When the AI can't do what was asked, what happens next? Most products leave the user in a dead end. Better design routes them somewhere: a different capability, a human, a template they can fill in manually.

Human escalation paths. Some problems shouldn't be solved by AI at all. The design has to make it easy to reach a human, not as an admission of failure, but as a normal expected path. Enterprise users in particular need this. They're accountable for decisions in ways individual users often aren't.

Recovery from confident mistakes. When the AI was wrong and the user caught it, what happens? This is where trust either recovers or collapses. The design at that moment matters more than anything that came before it.

Most teams design the happy path carefully and treat error states as an afterthought. In AI products, that trade-off is backward.

The Learning Curve Is the Product's Biggest Enemy

Here's a test I use when evaluating an AI product's UX: can a new enterprise user accomplish their core task on day one, with no documentation, no demo, no walkthrough?

Just: show up, understand what the product does, and do it.

Most AI products fail this test by a wide margin. They ask users to understand the underlying model before getting any value out. They expose configuration options that require understanding intents, entities, and dialog flows. They present a blank canvas and expect the user to know what to put there.

Enterprise users are not early adopters. They didn't sign up because they're excited about AI. Someone in their organization made a purchase decision and now they're supposed to use this tool. They're busy, often skeptical, and their tolerance for confusion is low. The moment they feel lost, they stop trying.

The best AI products I've seen make one deliberate choice: hide the AI from the user. Not deceptively. The user knows there's AI behind it. But the interface is organized around their work, not around the AI's capabilities. You don't ask them to write prompts. You ask what they're trying to get done. The system figures out how to use the AI to get there.

This sounds obvious. It almost never happens in practice. Teams built by engineers who find AI technically interesting tend to build interfaces that reflect the system architecture rather than the user's task. The product impresses in a demo and confuses in daily use.

One practical change that cuts the learning curve significantly: start with templates. Not tutorials. Not onboarding tours. Templates. Pre-built workflows that do something useful out of the box, which users can then modify. It gives them something working to change, not an empty canvas to figure out from scratch.

The Common Thread

These three problems share a root cause. They all come from designing AI products as if they're just smarter SaaS.

They're not. The underlying technology is different enough that the design principles need to be rebuilt, not ported over. Trust works differently when the system can be wrong. Errors work differently when failure is probabilistic. Onboarding works differently when the core capability is open-ended.

The teams getting this right share one instinct: they design for doubt. They assume users will be uncertain. They assume the AI will sometimes be wrong. They build every interface around those assumptions instead of the optimistic case.

Harder to build. But it's the only way to ship something users actually come back to.