What makes AI different

Most interfaces are deterministic: press the button, get the same result every time. That predictability is the quiet foundation of almost every usability principle you know. AI features break it.

An AI system's output is probabilistic — the same input can produce different results — so you must design for the range of possible outputs, not the happy path.

You cannot fully specify what the screen will show, because the system itself doesn't know until it runs. When you design an AI feature, you are not designing an output — you are designing a container that has to look right no matter what the system puts inside it. A summary might come back short or long, confident or hedged, brilliant or slightly off. Your layout, copy, and controls need to hold up across that whole spectrum.

This also changes how you prototype. A static mockup with one perfect, hand-written AI response tells you almost nothing. Test your designs with real outputs, including the mediocre ones, because that is what users will actually see.

    keywords
  • #Probabilistic
  • #RangeOfOutputs
  • #Uncertainty

Interaction patterns

Most AI features fall into a handful of recurring interaction patterns. Knowing them helps you pick the right shape for the problem.

Conversational interfaces

An open text box that accepts anything is both the most powerful and the most terrifying input in interface design: users can express any need in their own words, but a blank canvas gives no clue about what the system can do. Faced with an empty field, many users freeze or type something the system handles poorly — this is the blank-canvas problem.

The core job of a conversational interface is to teach its own boundaries: show what the system can do, and be honest about what it can't. Suggested prompts are your main tool here. A few example requests near the input ("Summarize this document", "Compare these two plans") do double duty: they get users started, and they quietly communicate the system's strengths. Vary them by context — an empty project deserves different suggestions than a finished report.

Copilot patterns

A copilot assists inside a workflow the user already owns: it suggests the next sentence in an email or proposes a formula in a spreadsheet. The user stays in charge; the AI rides along.

The essential affordances are accept, edit, and reject — and all three must be effortless. If accepting takes one keystroke but dismissing takes three, you are nudging users to accept things they don't want. A good copilot is judged less by the quality of its suggestions than by how gracefully it stays out of the way when they aren't wanted. Inline suggestions should be visually distinct from the user's own content, easy to ignore, and never able to interrupt typing or steal focus.

Generation patterns

Generation flips the workflow: the AI produces a draft — an image, a paragraph, a layout — and the user refines it. Because the first output will rarely be exactly right, the refinement loop is the real interface. Offer variations so users can compare directions, and offer regenerate so a weak result is a shrug, not a dead end.

Above all, make the output editable. Editability is a trust signal: a draft the user can change says "starting point," while a locked result says "take it or leave it" — and users rarely take it. If a travel app generates an itinerary and the traveler can swap one restaurant without regenerating the whole trip, the feature feels like a collaborator rather than a slot machine.

    keywords
  • #Conversational
  • #Copilot
  • #Generation
  • #SuggestedPrompts
  • #Editability

Onboarding users to AI

Users arrive at AI features with wildly different expectations — some expect magic, others expect nothing. Both end up disappointed if you let them guess. Set capability expectations early, in the first-run moment, not buried in a help article.

Show two or three concrete things the feature is good at, and name one thing it isn't. Setting expectations up front is cheaper than apologizing later: a user who knew the limits forgives a miss, while a user promised magic churns on the first mistake.

Keep the onboarding in the flow of use. A short hint next to the input beats a tour the user dismisses without reading, because it appears exactly when the question "what do I type here?" arises.

    keywords
  • #Expectations
  • #FirstRun
  • #Capabilities

Designing the failure modes

In an AI feature, a wrong, weird, or partial output is a normal state to design for — not an error edge case to handle if there's time left.

Traditional error design assumes failure is rare and binary: the request worked or it didn't. AI fails on a spectrum. The output might be mostly right with one wrong detail, plausible but off-topic, or half-finished. None of these will trigger an error dialog, and none should — the interface has to make imperfect output easy to notice and easy to fix.

Design for graceful correction. Let users edit the specific part that's wrong instead of forcing a full retry, and let them refine their request ("shorter", "more formal") rather than starting over. Then close the loop: lightweight feedback controls on each output tell the team what's failing in the wild, and tell users their judgment matters. A correction flow that takes three seconds turns a bad output from a broken promise into a normal step in the work.

    keywords
  • #FailureModes
  • #GracefulCorrection
  • #FeedbackLoops

Latency as UX

AI features are often slow by interface standards — seconds, not milliseconds. You usually can't remove the wait, but you can design how it feels. Streaming is the strongest tool: showing output as it's produced turns dead time into reading time.

When streaming isn't possible, show progress that means something. A status line that says what's happening ("Reading your document…", "Drafting a reply…") reassures more than an anonymous spinner, because it proves the system understood the request. Perceived speed is a design decision: the same five-second wait feels fast when something meaningful is happening on screen and broken when nothing is. And always give users a way out — a visible cancel keeps a long wait from becoming a trap.

    keywords
  • #Streaming
  • #PerceivedSpeed
  • #ProgressSignals

When not to use AI

The last skill is restraint. A deterministic feature that works every time beats a probabilistic one that works most of the time. Sorting a list, calculating a total, filtering by date: adding AI to these makes them slower, less predictable, and harder to trust, without making them better.

Before reaching for AI, ask what the user's job requires. If the task has one correct answer, build the feature that produces it. If it involves interpretation, drafting, or open-ended input, AI may genuinely help. AI is a means to serve a user need, not a badge to prove your product is modern — if a simpler mechanism does the job better, the simpler mechanism is the better design.

    keywords
  • #Restraint
  • #Deterministic
  • #UserNeeds

Takeaways

Designing AI features means designing for a range of outcomes: the good output, the mediocre one, the wait in between, and the correction after.

Pick the interaction pattern that fits the task, teach the system's limits before users discover them the hard way, treat imperfect output as a first-class state, and make waiting feel purposeful. When a plain, predictable feature solves the problem, ship that instead.