What Is AI Native Design About? Five Shifts Founders Should Pay Attention To

Most of what gets written about “AI UX” is about designing with AI. I’m talking things like faster prototypes, smarter handoffs, Figma plugins that do the boring parts. Useful things, yes, but not what this article is about.

This is about designing for AI. What it takes to build a product whose experience is the AI, and not a product that uses AI as a feature.

Most founding teams we at Habitat talk to are confused about this, and for good reason. The design playbook for AI products is still being written: there are no established patterns, nor sets of best practices to borrow from. And the challenges are genuinely different from anything standard UX thinking was built for.

‍TL;DR‍

Standard UX patterns don't apply to products that generate, act, and fail unpredictably. 

Five shifts that show what AI-native design is about: 

• Agentic UX. When the AI acts for the user, the interface has to show its work: what it did, what it decided, and how to override it when it's wrong.

• Trust-first interfaces. First impressions are sticky. Trust has to be built into the product's defaults.

• AI failure states. You must design for failure: make AI failure state visible, explainable, and recoverable.

• Personalization vs. predictability. The design job is knowing what to personalise and what to keep consistent.

Miss any one of these and users won't trust the product enough to use it, regardless of how good the model is.

Standard UX vs AI UX: Noun vs verb design 

Standard UX patterns most teams learned don't apply to dynamic AI software, one that anticipates, generates, acts, and fails unpredictably. 

Take two Adobe products. Photoshop gives you a canvas and a toolbar — buttons for every operation, each one doing exactly what it says. You click Crop, it crops. You click Filter, it filters. The interface is a grid of nouns: objects you pick up and use. Firefly gives you a prompt box. You describe what you want, and the system generates something you've never seen before. The interface is a single verb, which is generate.

Designing AI products is less about “the nouns” — the buttons, text fields, sidebars — and more about “the verbs” — autocomplete, auto-suggest, summarize, send an agent to do something. The AI thinks, responds, hesitates, corrects itself, and that sequence can't be captured in a static screen. As Raphael Schaad, Notion’s former Head of Design and Visiting Partner at YC, puts it, those verbs “are hard to express just by drawing a rectangle within a rectangle.” Instead, design has to account for what the AI does across time, not just what it shows when everything works. A static mockup won’t help here.

Standard UX design is about nouns: screens, flows, components. AI product design is about verbs: what happens when the AI acts, suggests, fails, or learns.  

#1. Agentic UX: When the AI acts for the user, the interface has to show its work

The further AI moves from assisting the user to acting for them, the more the interface has to carry.

Y Combinator estimates that the market size for AI agents will be ten times that of SaaS. The reason is scope. These tools do the job, rather than make someone faster at it. And while the AI takes over a human role, the interface inherits everything that human used to handle, including the situations where the data is incomplete or the answer is wrong. A human would pause, ask a question, and flag the problem. The interface now has to do that instead. Trust signals and control loops become critical (these are also the failure modes most AI products hit first; we broke them down in our AI product design article.

When the AI takes over a human role, the AI UX has to handle the situation where the data is incomplete, the request is ambiguous, or the answer is wrong. Trust signals and control loops become critical.  

Most agentic interfaces skip it. They show the output and hide the work. And that’s not a minor UX gap. If the operator can't see what the agent did or correct it when it's wrong, they won't trust it with anything that matters. 

The more AI takes on, the more ways users need to direct, correct, and communicate with it. That's where the next problem starts.

#2. Multimodal interaction: More input modes means more ways to lose the user

With AI, one interface can now handle different input modes: text, voice, image (sometimes all three). In practice, though, that creates a design problem. When an interface accepts any input in any mode, the user faces a blank canvas with no signal of where to start or what the product expects from them.

The partial solution most products reach for is static prompt suggestions, a few examples to give the user a starting point in other words. That helps, but only so far. Static suggestions show what the product can do but don't account for what you're actually trying to do right now.

The stronger response is making them dynamic. In an AI design tool, for example, that could look like this: you've just described a dashboard, and the suggestions shift to specifics: things like “Add a data table”, “Design the empty state”, “Show me a mobile version.” 

The user must always have a clear next step. When they do, a deeper question remains. Should they trust what they’re getting? That's our shift 3.

#3. Trust-first interfaces: Users won't use what they can't understand

If I were to highlight one feeling that's universal for first-time users of AI products, it'd be uncertainty. In regular software, the user knows what will happen when they click the button. With AI, they don't. The output is probabilistic. It might be right, it might be close, it might be confidently wrong. 

What makes this particularly costly is how sticky first impressions are — once a user has a bad first experience, they stop giving the product the benefit of the doubt.

Most try to solve this with onboarding screens and explanations. Those help, but trust is built through what the product does by default: how it introduces itself, what it shows first, what it assumes about the user. 

The Run app from Google's PAIR research shows what this looks like in practice. When the app asks for location permission during setup, it tells the user why their location is needed (to suggest running routes nearby) and where to go if they want to change it later. The user knows what they're agreeing to and what they get in return. 

At the same time, another thing worth designing for is over-trust. Users who trust an AI product too quickly stop verifying its outputs. GitHub Copilot handles this well. It suggests code but doesn't execute it. The user has to accept it first. That pause before the user commits is good AI product design doing its job, keeping them in the loop before something consequential happens.

This is what we map in the Trust signals and Explainability dimensions of our AI Feature Design Fit framework. Before designing screens, we figure out where the product needs to earn trust and how the interface does that.

For example, when designing Lucend, an AI tool for data center optimization that had no analogues at the time, we mapped exactly where operators needed to trust the system enough to act on it, without ever seeing the underlying data themselves.

Getting trust right is hard enough when the AI is working well, and…even harder when AI’s wrong. That's our shift 4.

‍

#4. AI failure states: Your AI will be wrong. Did you design for it?

When an app crashes, the user knows something went wrong. But when an AI gives a wrong answer, it usually doesn't look that way. Heck, it looks confident, well-structured, and completely plausible. 

What I find particularly sobering is that some of these errors are invisible to everyone: the user doesn't register the output as wrong, and neither does the product team. There's no crash log. A user can make a decision based on bad information with no way of knowing it.

Because AI will get something wrong at some point, founding teams have to design for failure — moments when the AI is uncertain or returns something the user shouldn't act on without checking.

What does designing for failure mean? 

For the “invisible” errors that may happen, the design job is to build in verification habits before the user acts. For errors the interface can catch, it comes down to three things:

1. Making failure visible. The interface has to acknowledge when something went wrong.
2. Explaining what happened. Users can tolerate errors when they understand why. 
3. Giving the user a clear next step. The part most products skip entirely.

The last part is also about giving users control when the AI can't continue and explaining what the user can do next. This is the same principle as shift 1: when the AI acts on behalf of the user, the interface has to show its work. When it fails, the interface has to hand the work back.

Of course, not every failure carries the same stakes, and the design response should reflect that. A wrong playlist recommendation is recoverable.The higher the stakes, the more explicitly the interface has to handle uncertainty, signal low confidence, and make it easy for the user to verify before acting.

Failure design is the fourth dimension in our AI Feature Design Fit framework. Before any engineering starts, we map where the AI is most likely to be wrong and what the interface has to do if it happens.

Even when failure is handled well, one tension remains: the AI adapts to the user over time, but users still need to know what to expect. That's shift 5.\

#5. Personalization vs. predictability: Adaptive interfaces work only when users know what won't change

AI products learn your preferences, retain context, and remember what worked last time. That adaptiveness is a core reason they get adopted. A 2025 MIT study backs this up. 66% of executives said they want AI that learns from feedback, and 63% demand context retention. The study focused on what makes AI startups win enterprise deals, but the principle applies more broadly: adaptiveness is something every AI product has to design for.

It's also not as straightforward as it sounds. The more a product changes based on what it learns about you, the harder it becomes to know what it will do next. And a product that keeps surprising you — even with improvements — starts to feel unreliable.

The lawyer quote from the same report captures the user side of this well. She'd switched back to ChatGPT for mission-critical work because her company’s AI tool kept repeating the same mistakes: “It doesn't retain knowledge of client preferences or learn from previous edits. It requires extensive context input for each session.” 

Know what to personalise, and what to keep consistent. 

I think about this as drawing a boundary: what does the AI adapt, and what stays fixed?
That boundary has to be a deliberate design decision.

‍
In a product like Lucend, where the AI is constantly learning and updating its recommendations, what did you keep fixed in the interface so operators could rely on it? Stuff like: How do you introduce new types of recommendations without disrupting the user's existing mental model of the product?

Recap: What AI-native design requires

Our team and I worked on AI products where no existing UI patterns existed. Lucend is one of them — data center optimization had no design precedent. Every decision about what to show the user, how to signal uncertainty, and what to do when the AI was wrong had to be made from scratch.

That's what AI-native design is about: when no established UX patterns exist, every decision about trust, failure, and adaptation has to be worked out from the ground up.

So we always start with the Blueprint. It’s a two-week sprint of mapping where the product needs to earn trust, how it handles the moments when the AI gets it wrong, and what adapts versus what stays consistent.

If you're building an AI product and recognise any of these shifts in your own product (or suspect you've skipped one), our free 48-hour Product Audit will show you where your product is exposed.

‍

‍