“Designing for AI” banner with five AI-themed tool icons

Designing for AI-Powered Products: The New Rules Nobody is Talking About

Every designer right now is being asked to work on something with AI in it. Myself included.

A chatbot. A smart suggestion. An auto-generated summary. A feature that does something the user used to do manually. The brief lands on your desk and it looks like a normal design brief except nothing about it is normal and nobody has told you.

The patterns you learned do not fully apply. The mental models your users bring do not fully apply either. And the design community is so busy arguing about whether AI will replace designers that it has largely skipped the more urgent conversation about how to actually design these things well.

This is that conversation.

The interface is no longer in full control

For most of design history, an interface did what you told it to do. You pressed a button. Something happened. The outcome was predictable, repeatable, testable.

AI breaks that contract.

The same input can produce a different output. The system makes inferences. It fills gaps. It makes decisions the user did not explicitly make. And the user has no idea how any of it works.

That is a fundamentally different design problem. You are no longer designing a deterministic system. You are designing an experience around a probabilistic one. The rules of cause and effect that every piece of UX wisdom is built on do not hold the same way anymore.

Most designers have not fully reckoned with this yet. They are applying old patterns to new behaviour and wondering why things feel off.

Users do not understand what the AI can do

This is the most underestimated problem in AI product design right now.

Users approach AI features with one of two assumptions. Either they think the AI can do everything, in which case they are going to be disappointed when it cannot. Or they think the AI is going to do something weird and wrong, in which case they are going to be too cautious to use it properly.

Both assumptions are wrong. Both are your problem to fix as a designer.

The design work here is not interface design in the traditional sense. It is expectation design. Your job is to build an accurate mental model of the system in the user’s head before they use it, so that when they do use it, their expectations roughly match reality.

That means being specific about what the AI does. Not “AI-powered insights” but “we analyse your last 90 days of data and surface the three patterns most likely to affect next month.” Not “smart suggestions” but “we suggest based on what similar users chose in the same situation.”

Vague capability claims feel impressive in marketing. They destroy trust in a product.

The loading state is now a design problem

When a deterministic system is loading, you are waiting for data to travel. It takes milliseconds or seconds. You show a little spinner and move on.

When an AI is generating a response, something different is happening. The system is constructing an answer in real time. It might take three seconds or thirty. The output is not sitting somewhere waiting to be fetched. It is being made.

Users feel this difference even when they cannot articulate it. A spinner on an AI response feels wrong because it implies the answer already exists and is just being retrieved. The experience of watching a response generate character by character is more honest. It communicates that something is actually happening.

How you handle the wait, what you show, what you say, how long you let it go before intervening, is a design decision that shapes how much users trust the output they receive.

Errors are completely different now

In a traditional interface, an error is a binary thing. The action worked or it did not. The form submitted or it did not. The file uploaded or it did not.

AI errors do not work that way.

The AI might give you an answer that is confident and wrong. It might give you an answer that is technically correct but completely useless for what you needed. It might misunderstand the intent behind a request and solve the wrong problem entirely. It might work perfectly ninety percent of the time and fail in ways you cannot predict the other ten.

None of these are errors in the traditional sense. There is no error state to design. The system did not break. It just did not do what you needed.

This is one of the hardest UX problems in AI products and most teams are not taking it seriously enough. You need ways for users to signal that the output missed the mark without making them feel like the product failed them. You need recovery flows that feel like a conversation, not a dead end. You need to set expectations upfront that the AI will sometimes get it wrong, and that this is normal, and that there is something they can do about it.

Trust is the actual product

With most digital products, trust is a factor. With AI products, trust is the product.

If users do not trust the output, they will not use the feature. If they use it and get burned once, they will not come back to it. If they cannot tell when to trust it and when not to, they will default to ignoring it entirely to feel safe.

Everything you design needs to be in service of calibrated trust. Not blind trust, where users accept everything the AI produces without thinking. Not zero trust, where users dismiss everything and the feature is pointless. Calibrated trust, where users have a clear enough understanding of what the AI is good at and where it falls short that they can use it confidently and appropriately.

This means being transparent about confidence. If the AI is less certain about something, say so. It means showing your working where you can. If a recommendation is based on specific data, show which data. It means giving users agency. Let them edit, override, regenerate, reject. A user who can push back on the AI is a user who trusts it more, not less.

You are designing for a moving target

Traditional software does not change its behaviour unless you ship a new version. AI models get updated. Their behaviour shifts. Something that worked a certain way last month might work differently now.

This is a design and communication problem that nobody has fully solved yet.

Your interface makes implicit promises about how the system behaves. When the behaviour changes, those promises are broken, even if the change is an improvement. Users who have built habits around the old behaviour will feel disoriented. They will not know if something is broken or different or both.

You need to think about how you communicate change in AI features. Not just release notes. Not just tooltips. Actual design patterns that help users recalibrate their mental model when the system underneath has shifted.

The temptation to hide the AI

Some product teams make the opposite mistake. They hide the AI entirely. They surface the output as if it came from nowhere. No explanation, no attribution, no indication that a model was involved.

This feels cleaner. It also backfires.

When something goes wrong, and it will, users have no framework for why. They do not know if it is a bug, a bad data source, or a fundamental limitation of the technology. They just know the product let them down, and they have no information to help them decide whether to try again.

Transparency about the AI is not a legal requirement or an ethical nicety. It is a practical design decision that protects the user relationship when things inevitably do not go as expected.

What this actually means for your work

Design the expectations before you design the interface. Before you think about layout or components or flows, think about what the user believes the AI can do. Then design to make that belief accurate.

Treat the output as a first draft. Give users the tools to shape it, correct it, regenerate it. The best AI experiences feel like a collaboration, not a vending machine.

Be honest about uncertainty. A system that says “I am not sure about this” is more trustworthy than one that is always confident. Design for that honesty.

Design the failure modes. What happens when the AI misses? What does the user see, what can they do, how do they recover? These are not edge cases. They are core flows.

And resist the pressure to make it feel like magic. Magic is impressive once. A tool you understand and trust is something you use every day.

I’m Carlos, a product designer running from Porto. I work with startups and founders on products that are worth using. If something here resonated, feel free to connect.