Een Foreside-sessie waarin werk op het scherm wordt besproken

Designing for trust: UX for AI features

AI features rarely fail on the model and often on the interface. A system that is sometimes brilliant and sometimes wrong demands different design than a button that always does the same thing. Four principles from our practice.

The interface is the promise

Classic software is predictable: the same button gives the same result, and users build blind trust on that. AI breaks that contract. The same request can give a good answer today and a mediocre one tomorrow, and from the outside the user cannot tell which of the two they got. Every design choice around an AI feature is therefore, at its core, expectation management: what do you promise, and does that promise hold on a bad day.

It starts with framing. Call something an answer and people expect it to be right. Call it a proposal or a first draft and they expect to look at it themselves. That one word changes your users' behaviour more than any model upgrade. That is why our Kompas literally says it is a starting point for a conversation, not a sales machine. That honesty is not modesty, it is design.

Show what is happening, including the doubt

The reflex when designing smart features is to hide the machinery: a clean answer, no fuss. With AI that backfires. Users who cannot see where an answer comes from cannot judge whether to trust it, and drop out at the first mistake. So show what an answer is based on: which source, which fact, which assumption. An answer with its sources is worth more than a better answer without them.

And dare to show doubt. A system that says it is not sure and asks the user to double-check feels like weakness to a product manager, but like honesty to a user. The paradoxical effect is known from research and from our own projects: well-dosed uncertainty increases trust in the moments the system is confident.

Give the human the wheel, visibly

The best AI features do not feel like a vending machine but like a good assistant: it does the groundwork, you decide. Translate that literally into your interface. Everything the AI produces can be edited before it counts. Every action with consequences asks for a confirmation that shows what is about to happen. And everything can be undone, visibly and without hassle. Not because it is often needed, but because knowing that it is possible determines whether people dare to use the feature.

Corrections are not failure but nourishment. Every time a user adjusts a proposal, they are telling you exactly where the system falls short. Design that feedback loop deliberately: make correcting easier than complaining, and show that something happens with the feedback. In SARA, care workers adjust a client's programme, and it is precisely that adjusting that makes the system fit better every week.

Design the failure, not just the success

Every AI feature has a failure mode, and that failure mode is the real design. The question is not whether the system will get it wrong at some point, but what the user sees and can do at that moment. An empty state with a generic error message is a design flaw. A well-designed failure says what did not work, gives the user a manual alternative, and degrades gracefully: when the smart route fails, the normal route keeps working.

Finally, watch the tone. Precisely because AI answers sound human, words weigh heavily. An assistant that is too chummy breeds distrust at serious moments; an assistant that stays assertive after a mistake burns its credit. Write the microcopy for your AI feature with the same care as your most important sales page, because this is where your user decides whether they still believe your product.

Five choices on one screen. Together they decide whether a user dares to rely on the feature, even on a bad day.

What it comes down to

Trust is not a by-product of a good model, it is a design choice you make again on every screen. Make the interface honest about what the AI does and you can build a beloved feature even on an average model. Polish it into an oracle and you lose the user at the first mistake. Curious what this looks like in your product?

Schedule a meeting