UI patterns for AI: how to design AI features people trust

TL;DR: UI patterns for AI are reusable answers to four questions. How users ask, how answers show up, how users fix them, and why they should trust them. Pick how much AI the user sees first. Then kill the blank prompt box, pick an output people can act on, and make fixing cheap.

An AI feature lives or dies on its interface. The model can be spot on and the feature still flops. Nobody knows what to type. Or nobody knows what to do with what comes back.

UI patterns for AI fix that. They're reusable answers to four questions. How does the user ask? How does the answer show up? How do they fix it? Why should they trust it?

Here's the short version:

1. Pick how much AI the user sees. Hidden, a button, or an open text box.
2. Kill the blank prompt box. Give people presets and a place to start.
3. Pick an output people can act on. A table often beats a wall of text.
4. Make fixing cheap. Regenerate, edit in place, undo.

Start with how much AI the user sees

Google's web.dev course on UX patterns for AI sorts AI features by exposure. That's how much of the AI the user sees and controls. More exposure gives the user more freedom. It also brings more risk. There are three types.

Background AI

It runs quietly inside something that already exists. Spam filters. Show recommendations. Review summaries. Users don't need to know how it works, or even that it's there.

web.dev says it fits best when the task is low risk and user control wouldn't make the result better. The product also has to keep working if the AI fails.

Raw.Studio has a good picture for this. Their iceberg model of UX says the screen is just the tip. Most of the experience sits under the water, in calls the AI makes that the user never sees. Their example is Netflix picking what to show you next.

Constrained AI

The user starts it, often with one button. You set the task, the limits and the output format in the system prompt. The user clicks and gets a result. That's it.

web.dev's example is a blog editor with a Show Titles button. Click it and you get a few title drafts to pick from.

Open-ended AI

A free text box. The user can type anything.

It's the most flexible type. web.dev also calls it the highest risk to the user experience. Input is vague. Output is hard to predict. Wrong answers are more likely. So is trusting the tool too much.

So which one do you pick? Ask five things first:

• Can the user undo it if the AI gets it wrong?
• Can you predict what the output will look like?
• Does the product still work if the AI is down?
• How many AI features sit on this screen now?
• Does the user need to feel in charge here?

web.dev's own tip is blunt. Many teams start with open-ended. If you're new to AI, start with background or constrained. Open it up later, as users ask for more.

Input patterns: kill the blank prompt box

A blank text box is hard work. The user has to know what to ask. Then they have to know how to ask it.

Smashing Magazine's review of AI interface patterns says the same thing. Chat puts the job of explaining intent on the user. It reports that in usability tests people get lost typing and re-typing, and that input often takes 30 to 60 seconds.

So give people a head start:

1. Presets and templates. Show the shape of a good request.
2. Prompt suggestions. web.dev's support agent example offers ready-made asks like a return request.
3. Structured controls. Tone tags, length pickers, sliders. Small dials beat long prompts.
4. Voice. Some things are faster to say than to type.

Show new users the simple path first. Let power users jump straight to raw text.

One more thing on input. It has to work for everyone. The W3C's note on natural language interface accessibility says one input channel isn't enough. Some users need speech. Others need a keyboard, a switch or eye tracking.

Thinking about voice? Digiocial has a plain rundown of what Gemini Flash Live does and where voice models are at.

Output patterns: pick a format people can act on

A chat bubble is the default. It's often the wrong pick.

Smashing Magazine notes a slow move away from chat-style screens. Chat isn't going away. But it's being joined by task-first screens with buttons, sliders and canvases. And the output doesn't have to be plain text or a list of dot points.

Match the format to the job:

• Comparing options? Use a table the user can sort.
• Tracking a trend? Use a dashboard.
• Anything with a place in it? Use a map.
• Writing a document? Put the text in the workspace where it can be edited. Not in a chat about it.
• Too many options? Rank them. Smashing calls this forced ranking, and it stops choice paralysis.

Then show where the answer came from. Name the data it used. One line of source does more for trust than a paragraph of fine print.

Is your feature a chat window? Our post on conversational UI design covers the six parts it needs. Not sure you need chat at all? AI-Led explains AI agents vs chatbots in plain words.

Refinement patterns: make fixing cheap

The first answer is rarely the last one. So the fix has to be easy.

web.dev says it straight. Regenerating should be easy, cheap and reversible. Users should be able to undo. Smashing says refining is usually where the experience hurts most.

Four patterns do most of the work:

• Offer a few options, not one. web.dev says this stops users feeling stuck with a result they don't like.
• Let users fix one part. Highlight a sentence, change that sentence. Smashing describes prompts that act on the highlighted bit, not the whole output.
• Let users accept or edit before anything saves.
• Keep undo one click away.

Does the answer stream in word by word? Give people a stop button. Make it obvious when it's done.

Tip: log every regenerate, accept and edit. web.dev says to collect these signals so you can tune the feature. We'd go further. Those three numbers tell you more than a survey will.

Trust patterns: say what the AI did

Trust isn't a badge you stick on once and forget.

Start with disclosure. NN/g's PACED framework turns it into five questions. What does policy say? How does your audience feel about AI? How much does the human touch matter in this context? Do users expect to be told? How much did the AI do? NN/g wrote it for content. We find the same five questions work for a product feature.

Then explain the right amount. Google's People + AI Guidebook has a chapter on explainability and trust with two ideas worth stealing:

• Partial explanations. Explain the bit that shapes the user's choice. Leave out what's too complex or no use to them.
• Two kinds of explanation. General ones cover how the whole system behaves. Specific ones explain a single output. Put the general ones in onboarding. Put the specific ones next to the result.

Watch your wording too. For background features, web.dev suggests plain labels like Summary. It also says to strip out language that sounds too sure of itself.

And for open-ended features, web.dev lists three more habits. Show what the system thinks you asked. Ask before it does anything sensitive, like a refund. Hand over to a human when it isn't sure.

We go deeper on the trust ladder in our AI UX guide for SaaS. For high-stakes calls, read human in the loop. Wrong answers kill trust fastest, so hallucination reduction belongs on the list too. The Orchestrators map out a 90-day human in the loop build if you want a plan to follow.

Accessibility and testing

AI interfaces fail in ways a normal UI test won't catch. So treat access and testing as one job.

The W3C note sets out user needs worth building to:

1. More than one way in and out. Speech, keyboard or switch for input. Spoken or on-screen text for output.
2. A text transcript that stays in sync with any spoken output.
3. Step-by-step help. Screens that lean on memory are hard for people with cognitive disability. Show how many steps are done and how many are left.
4. Support for the symbol sets that AAC users rely on.

Then test the unhappy paths. Slow replies. Wrong answers. A stream that cuts out halfway. A screen reader on a wall of moving text.

One more to watch. Some products now build the interface itself at run time. The W3C has a Generative UI Community Group looking at how to test that. Its scope includes structured test cases and reference builds. It's early work. If your UI is generated, keep an eye on it.

For the scoring side, see our post on LLM evaluation.

One flow, all four patterns

Picture a tool that drafts a weekly status report from task data. This one is a made-up example, not a client build.

1. The user picks a template. That's the input pattern.
2. The tool shows a draft card and lists the tasks it pulled from. That's the output pattern, with sources.
3. The user asks for two other takes on the summary. Refinement.
4. They fix one paragraph in place. Refinement again.
5. They accept it. Nothing sends until they do.

Two calls shaped that flow.

First, the report has known fields. So it's constrained. No open text box needed.

Second, sending a report to a client can't be undone. So it gets a confirm step.

What would we track? First-draft accept rate. Regenerate rate. Edits made after accept.

Where Devwiz fits

We've shipped 200+ apps, including work for NSW Government (Justice and Corrective Services), Briometrix, Vivid and Huskee. AI now runs through how we build and what we build.

Our view is simple. Ship one constrained feature first. Measure it. Then open it up.

The interface is one layer. The platform under it matters just as much. In our white-label AI platform case study, we took a vibe-coded app and rebuilt it as a multi-tenant SaaS. Model routing went in too, so the right model gets picked per tool, per tenant and per task.

We build AI apps and turn programs into AI platforms. New to designing around users? Start with the core principles of user-centred design.

Not sure which type your feature is? A discovery phase sorts that out fast. Worth a chat?

Frequently asked questions

What are UI patterns for AI?

They're reusable interface answers for features where the output can vary. They cover how users give input, how results show up, how users fix a result and how the product earns trust. Google's web.dev course groups them by exposure: background, constrained and open-ended.

How do you choose between constrained and open-ended AI?

Look at the risk and how well you can predict the output. Constrained AI suits a clear, well-defined job started by a button. Open-ended AI suits jobs with lots of variety, like customer support. web.dev suggests teams new to AI start with background or constrained features and open up later.

How should an AI feature disclose that AI was used?

Decide case by case. NN/g's PACED framework asks five questions: what policy says, how your audience views AI, how much the human touch matters in context, whether users expect to be told, and how much the AI did. One generic badge on everything rarely fits.

What accessibility needs apply to AI chat and voice interfaces?

The W3C's note on natural language interface accessibility calls for more than one mode of input and output, such as speech, keyboard or switch. It also covers a text transcript in sync with spoken output and step-by-step help for people with cognitive disability.

Can Devwiz design and build AI interfaces?

Yes. Devwiz builds AI apps and AI platforms with these patterns built in from the start. We've shipped 200+ apps. Book a call and we'll map the right patterns to your feature.