Interaction design matters more than ever with AI products in production

The demo went well. The AI drafted the summary, the suggestions looked smart, and the team nodded. Then you shipped it. Real users, real data, half-finished inputs, model updates you did not plan for, and a lot of sessions nobody watched. The feature that looked clean in the demo now looks rough in production. The model did not get worse. The interaction design was not built for what production actually is.

Most teams design the happy path once and then patch. They add a spinner for loading, a toast for errors, and a disclaimer at the bottom. It works well enough in testing. Production is less forgiving.

This is a deeper piece in our Designing for AI series. We have already covered AI failures, building trust, co-pilot control, conversational interfaces, and testing. I will not repeat those. I want to go deeper on what changes once an AI feature is running at scale, with real users and real stakes.

Design the States, Not the Screen

Every AI feature has more states than most screens do. Idle. Thinking. Streaming a partial result. Confident output. Uncertain output. Refused. Failed. Handed off to a human. Each one is a moment where the user needs something from you: reassurance, information, or a path forward.

Most teams design the confident result and leave everything else to a spinner and a toast. That is not a design. A spinner says "something is happening." A toast says "something happened." Neither tells the user what the system is doing, how long it might take, or what they should do next.

If your AI is streaming a response, show the response as it arrives. Let users read while it writes. If the output is uncertain, say so in the interface itself, not just in fine print. If it refused a request, say why in plain language and offer something adjacent. If it failed, keep the user's input on screen and give them a next step. Each state deserves a designed UI, not an afterthought.

I find it useful to map every state before any screen gets designed. You get a clearer picture of where the real design work lives, and it is rarely the confident result state.

Treat System Instructions as Product Design

The system prompt controls more of the user experience than most people realize. It decides what tone the AI uses, what it will and will not help with, when it asks a clarifying question instead of guessing, and what it says when the user asks something out of scope.

That is product design, not engineering. Designers should own the behavior spec alongside the engineers who implement it. If the instructions say "always be concise" and the UI is built around long-form output, you have a conflict nobody will notice until real users hit it.

Test your instructions the same way you test a UI. Write a set of real scenarios: messy inputs, off-topic asks, edge cases, and genuinely hostile asks. Run the instructions against them. Have a person review the outputs. Record what breaks. A model update is effectively a release. The instructions that worked last month may behave differently after the update. Re-run the scenarios, review what changed, decide if it ships. The same mindset shows up in testing and iterating AI features, but here the artifact under test is the behavior spec, not only the screen.

This is less work than it sounds, and it catches more issues than you would expect.

Confirmation Scales with Consequence

Reading and drafting need no gate. If a user asks for a summary and the AI summarizes, they can just read it. No confirmation required. But if the AI is about to send an email, delete a record, charge a card, or touch another person's data, the user needs to see exactly what will happen before it does.

Not a generic "are you sure" modal. A preview: the recipients, the message text, the amount, the record that will change. Something they can scan, edit, and then approve or cancel. A single clear action to commit. That preview-and-approve pattern is the same work we map in AI agent and AI-feature UX.

Do not confirm everything. If you put a confirmation screen in front of every AI action, users stop reading them. Confirmation fatigue is real, and it is worse than no confirmation at all. Save the gate for moments where the consequence is hard to reverse.

Where you can offer undo, prefer it to confirmation. Undo lets the user move faster and recover from mistakes without the cognitive overhead of a decision gate. Confirmation is a brake. Undo is a seatbelt. Both matter, but they are for different situations.

Error Recovery Is a Flow, Not a Message

When an AI feature fails, the worst thing you can do is show a generic error and leave the user stranded. They had a task. They still have that task. The error did not change what they need.

Good error recovery does three things. It says what happened, in plain language (not "an unexpected error occurred"). It keeps the user's original input on screen so they do not have to retype it. And it offers a concrete next step: retry, rephrase the request, try a narrower version, do it manually, or talk to a person who can help.

Never dead-end. Every error state needs a way forward. We go deeper on failure patterns in our AI failures article if you want more detail there.

The broader principle is that recovery is a flow, not a message. It has steps. Those steps need to be designed.

Consistency at Scale

One AI feature is a design problem. Several AI features built by several different teams is a consistency problem. Each team invents its own pattern for the loading state, the citation style, the feedback controls, the confirmation modal. Users encounter several different conventions and trust none of them.

The fix is to put your AI interaction patterns into the design system. Not as an afterthought or a section at the back of the Figma file, but as first-class components with clear usage rules. Loading states. Confidence indicators. Feedback controls. Confirmation flows. Each one defined, named, and documented.

Write a short product contract alongside it (DESIGN.md and Taste Profile is the howto we use) that describes what the AI does, what it does not do, how it handles edge cases, and what the designed states look like. For behavior and accessibility boundaries above that layer, designgov.md can hold the rules contract. Engineers use it. Coding agents use it. New designers use it. Everyone builds the same pattern the same way.

There is a brand dimension here too. AI-generated content, whether that is suggested copy, auto-populated fields, or generated layouts, should be visually distinguishable from human-authored content until the user approves it. Otherwise users cannot tell what they wrote from what the system wrote. That distinction matters more as AI touches more surfaces. AI UI brand governance is the process page for keeping that distinction at the root, not in one-off fixes.

Watch Real Usage

Shipping the feature is not the end of the design work. It is the start of the feedback loop.

Build feedback controls people actually use. A thumbs down next to a response is better than nothing, but it tells you almost nothing. A quick "why wasn't this helpful?" with two or three options tells you much more. Review real sessions (with appropriate privacy protections in place) and look for patterns: where users rephrase the same request, where they abandon mid-flow, where they override the AI's suggestion and go manual. Those moments are design failures. They mean the feature did not do what the user needed.

Feed what you find back into the system instructions and the UI. Maybe the AI is answering a slightly different question than users are asking. Maybe the loading state causes people to click away before the result arrives. Maybe the confirmation modal is confusing and users are canceling by mistake. You will not know until you look.

The best AI features I have seen get meaningfully better in the months after launch, not because the model changed, but because the team was watching and adjusting.

How We Usually Approach It at Clearly

When a team comes to us with an AI feature that is in production (or close to it), the first thing we do is map it as a set of product states against the actual permission model. What can the AI do, for whom, under what conditions, and what happens in every state? That map usually surfaces more open questions than teams expect.

From there, we prototype the risky moments. Confirmation flows. Error recovery. Handoff to a human. We put those prototypes in front of real users and engineers before anyone builds them, because changing a confirmation flow in a prototype is cheap. Changing it after it has been coded and shipped is not.

For a focused engagement like this, we often start with a two-week Sprint at $3,750. That is enough to map the feature properly and prototype the moments that matter most. Teams that want ongoing design coverage through the full build move to Standard at $4,995/mo or Advanced at $7,495/mo. Published prices are on pricing: a Sprint is $3,750 for two weeks, Standard is $4,995 a month, and Advanced is $7,495 a month.

If you are building an AI feature and you are not sure whether the interaction design will hold up in production, book a discovery call from this page and we can talk through where the risks are.