Skip to content
Lines&Frames

· 9 min read

Designing AI features without the magic

AI features fail on ordinary interface problems: unclear scope, invisible state, and no way to correct a wrong answer. Patterns that fix each.

  • AI
  • UX
  • Product

The short version

  • An empty prompt implies unlimited capability, which guarantees early failures — constrain the entry point.
  • Make the work visible: naming inputs and steps buys more patience than a spinner, and lets people judge the output.
  • Design the correction loop, not just generation — people need to keep two-thirds of an answer and fix the rest.
  • Express confidence through layout: a draft presented as a draft invites the review it needs.

The interface pattern for most AI features is still a text box and a hope. It ships quickly, demos well, and then usage flattens — not because the model is weak, but because nobody can tell what the box is for, what it just did, or how to fix it when it is wrong.

None of those are model problems. They are the same three interface problems as any powerful tool: scope, state and correction. What follows is how we design each one.

Show the scope before the input

An empty prompt is the least informative control in software. It implies the system can do anything, which guarantees most first attempts fall outside what it does well. Constrained entry points outperform open ones early in a feature's life: three named actions people can pick from teach the boundary in a way placeholder text never does.

  • Offer named actions first, free text second — not the reverse.
  • Write the named actions as outcomes ("summarise this thread for a customer"), not capabilities ("summarise").
  • Say plainly what it cannot do, once, near the input. Discovering a limit by failing is far more expensive than reading it.
  • Where the model can only work on certain objects, disable the entry point elsewhere rather than failing after submission.

The open box is still worth shipping — but as the second thing people find, once the shape of the tool is established. Ordering these two costs nothing and changes adoption materially.

Make the work visible while it happens

Latency is tolerable when it is legible. "Reading 14 documents", "drafting", "checking figures against the source" buys far more patience than a spinner, and it does something more valuable: it tells people what the system considered, which is the only way they can judge whether the answer deserves trust.

  • Name the inputs the system used, and let people open them.
  • Stream partial output when the shape of the answer is stable, not when it will visibly rewrite itself — watching a sentence get replaced erodes confidence.
  • Distinguish "no answer" from "empty answer". Silence reads as breakage.
  • If a step failed, say which one. "Could not read two of the twelve files" is useful; a generic error is not.

Design the correction, not just the generation

The generation is one step; the loop is the product. Most AI features are designed as if the first output is the deliverable, so the only affordances are regenerate and copy. What people actually need is to keep two-thirds of an answer and fix the rest — edit in place, adjust one constraint, pin what was right and re-run the remainder.

If the only way to improve an answer is to ask again and hope, the feature is a slot machine with better typography.
  1. Make the output editable in place, with no mode switch.
  2. Expose the two or three constraints that most change the result, as controls rather than prose to retype.
  3. Let people lock a good section before re-running.
  4. Keep the previous version reachable. Losing a better earlier answer is the fastest way to lose trust in the loop.

Be honest about confidence in the layout

Confidence belongs in the composition, not in a percentage. A draft that is presented as a draft — editable, clearly provisional, sitting beside its sources — invites the review it needs. The same text set as a finished answer in a confident panel invites the trust it has not earned. That choice is made in layout and typography long before any copy is written.

Numeric confidence scores are usually worse than nothing: they are hard to interpret, rarely calibrated, and they transfer responsibility to a reader who has no way to act on 0.72.

Decide what happens when it is wrong in public

Every AI feature eventually produces something wrong in front of a customer. The design question is not how to prevent that; it is what the interface does about it. Features that survive have an obvious path to report, correct and, crucially, a visible record that the correction stuck. Features that do not, get switched off after the first incident.

  • Route irreversible actions through a human confirmation that shows exactly what will happen.
  • Log the input, the output and the sources for every generation, and make that visible to support.
  • Give the correction a durable effect — even if it is only a per-account preference. A correction that vanishes teaches people not to bother.

Questions we get asked

Why do users not engage with our AI feature?
Usually because the boundary is invisible. An open text box implies the system can do anything, so first attempts land outside what it does well and people do not return. Named, constrained entry points teach capability faster than placeholder text.
How should AI features handle wrong answers?
By making correction cheaper than regeneration. Let people edit in place, adjust one constraint, or pin the correct portion and re-run the rest. If the only options are regenerate and copy, the feature depends on luck.
Should AI output show a confidence score?
Rarely. Percentages are hard to interpret and imply precision the system does not have. Express confidence through the composition instead — a provisional answer presented as editable, beside its sources, invites the review it needs.

If this is the decision in front of you, we can help you make it.

Start a conversation

Related reading