Designing for software that is usually right

Conventional interface design assumes the system is correct and the user might not be. AI-native design inverts that: the system is fast and usually right, and the interface has to make it cheap to check, obvious when to doubt, and safe when it is wrong. Most AI products fail here rather than in the model.

  • Interfaces designed for review, not just for output. The measure is how long it takes a person to confirm or correct, because that number decides whether the product saves time at all.
  • Calibrated trust. Users who know when to check and when not to, because the interface tells them honestly rather than presenting everything with the same confidence.
  • Safe failure. Wrongness that is visible, cheap and reversible instead of quiet and expensive.
  • A tested prototype. Clickable, in front of real users, before anybody writes production code.
Talk to us about this

What is delivered

  • Interaction model

    Where the system proposes, where the person decides, and how a disagreement is expressed. The central design decision, made explicitly rather than by default.

  • Uncertainty design

    How confidence is shown without a meaningless percentage, what the system says when it does not know, and what it must never guess at.

  • Review-first layouts

    Screens designed so a correct result can be confirmed in seconds and a wrong one is obvious. Optimising the common case is what makes the product economic.

  • Provenance and explanation

    What the answer was based on, reachable in one click. Users trust systems that show their sources and abandon ones that do not.

  • Correction paths

    How a person fixes a wrong output, and how that correction teaches the system rather than being discarded.

  • Prototype and test findings

    A working prototype tested with people who do the job, with the failures written down rather than smoothed over in the readout.

How it runs

  1. 01

    Watch the current task

    How the work is done now, with timings. The baseline the product has to beat, which is rarely what anybody assumed.

  2. 02

    Model the interaction

    Decide the propose-and-confirm shape before drawing screens. Layout follows from it, not the other way round.

  3. 03

    Prototype

    Clickable, with realistic wrong answers included. A prototype that only shows good outputs tests nothing that matters.

  4. 04

    Test and revise

    With people who will actually use it, measuring review time and error catching rather than asking whether they liked it.

A good fit when

  • You are building a product or internal tool where a model produces something a person acts on.
  • An existing AI feature is technically working and nobody uses it.
  • Users are either over-trusting the output or ignoring it entirely.
  • You need the design settled before committing engineering budget.

Not the right service when

  • The AI runs fully in the background with no human touchpoint. Then this is an engineering and monitoring problem, not a design one.
  • You want a visual refresh. That is worth buying, and it is not this.
  • The underlying task is not yet defined. Design will expose that, but it is a slow way to find out.

Frequently asked questions

Is this UX design or product design?
Both, focused on one thing: the interaction between a person and a component that is usually right. Visual design is included where it serves that, and we will say when what you need is a design studio rather than us.
Do you deliver a design system?
If that is what is needed, yes. More often the valuable output is the interaction model and a tested prototype, because that is what determines whether the product works, and a design system built before that is decoration on an unproven idea.
How do you show confidence without a percentage?
Usually by structure rather than by number: what the answer rests on, what was ambiguous, and what the system chose not to answer. Percentages are read as precision by users and almost never mean what they appear to mean.
Can you work with our existing design team?
Yes, and that is often the best arrangement. They know your product and your users; the part we add is the design language for uncertainty, which is genuinely new work and not something experience with conventional software prepares anybody for.
How long does it take?
An interaction model and a tested prototype for one workflow is typically three to five weeks. Longer than that usually means the underlying task was not defined, which is a finding worth having early.

Keep reading

Other services