Earning user trust in AI products during onboarding

Users do not arrive at an AI product neutral. Some expect magic and will be disappointed by anything less. Others expect it to be wrong and are looking for the first mistake. Most carry a bit of both. Whatever they expect, they make up their minds quickly, and they do it based on what the product shows them, not what the marketing promised.

Building trust in an AI product during onboarding is therefore a design problem with a few concrete parts: setting honest expectations, showing where answers come from, asking for as little as possible, and reaching a first piece of real value fast. Across Oryvelon's companies the products are very different — a store assistant, an eligibility checker, a learning tool, a reading app, a talent marketplace — but the onboarding principles are shared. This article sets them out, with examples.

Why the first session decides so much

AI products carry a trust burden that ordinary software does not. A spreadsheet does not make things up. A booking form does not sound confident about something it has wrong. When an AI product gets something wrong early, users do not file it as a bug. They conclude that the product cannot be relied on, and they stop checking whether later answers are better.

The reverse is also true. A user who sees the product be accurate, modest about its limits and clear about its sources in the first few minutes tends to extend some patience when it later makes a mistake. They have a model of how it works. They know where to look to check it.

So onboarding is not a welcome tour. It is the period in which the user builds their mental model of what the AI is, and the product has a short window to make that model accurate.

Principle 1: say what the AI does, and what it does not

The most useful thing an onboarding flow can do is tell the user, early and plainly, what the AI is responsible for and what it is not.

We write this as a short statement for every AI product, in the product's own voice, and use it in onboarding, in help pages and next to AI-generated content. The statements come straight from each company's source-of-truth document, which already defines what the company will and will not do.

Some examples, in paraphrase:

• MerchNivo: "Your numbers come from your store. MerchNivo's assistant explains them and suggests what to look at first. It does not change anything in your store without your approval."
• KeşifAtlası: "Eligibility results come from our verified rules database. The assistant explains which rules apply to you. It does not make the decision, and difficult cases are reviewed by a person."
• ZodiVela: "Readings are for reflection and entertainment. They are not predictions and not advice."
• EduRelia: "The assistant helps you practise and understand. Your teacher and school remain in charge of your learning."

Notice what these avoid: capability boasting, vague phrases like "powered by advanced AI", and anything the product cannot keep. A limit stated upfront reads as honesty. The same limit discovered by the user reads as a failure.

Principle 2: separate what is generated from what is verified

A trustworthy AI screen makes it obvious which parts were written by a model and which came from verified data or a person.

In practice this means consistent visual treatment. Figures pulled from a store, rules pulled from a database, profile details confirmed through verification — these are shown as data, in tables, labels or cards. AI-generated explanation is shown as explanation, visually distinct and labelled as such. Users quickly learn to read the two differently, which is exactly what we want them to do.

This mirrors how the products are built. Under our principle that AI explains, verified data decides, the facts never originate in the model. The interface just makes that architecture visible to the user.

Principle 3: show sources from the first screen

If an answer rests on something, the user should be able to see what.

For MerchNivo, a briefing line about refunds links to the orders it summarises. For KeşifAtlası, an explanation cites the specific rules, with their effective dates, and the user can open each one. For EduRelia, an explanation points to the lesson or curriculum item it relates to.

Showing sources in onboarding matters more than showing them later, because it sets a habit. A user who clicks through to a source in their first session learns that the product can be checked. That changes how they treat every later answer: less blind belief, less blanket suspicion, more informed use.

It also keeps the product honest internally. If a screen cannot show a source for a claim, that is a sign the claim should not be there. The mechanism that makes this reliable — outputs that must cite identifiers supplied in the input — is described in Structured outputs: validating AI responses before users see them.

Principle 4: ask only for what the first task needs

Onboarding flows love to collect data. Every extra field feels harmless on its own. Together they make the product feel greedy, and in AI products users are right to wonder what the data will be used for.

Our rule is that onboarding asks only for what the first useful task requires. Everything else is requested later, in context, when the user can see why it is needed.

For a MerchNivo store, the first briefing needs read access to orders, products and inventory. It does not need write access to anything. Write permissions for suggested actions are requested later, feature by feature, when the merchant chooses to use them.

For KeşifAtlası, the free eligibility test asks only the questions the rules need to produce a result. Documents and detailed history belong to the paid report, if the user chooses it. See From free test to paid report.

For EduRelia, a student profile holds the minimum the learning experience requires, and schools decide what is set up. See Data minimisation for children in edtech.

Consent works the same way. Product consent — what the product needs to function — is asked separately from marketing consent, and neither is bundled into the other. We explain the difference in Marketing consent vs product consent.

Principle 5: get to first value quickly — and make it checkable

The strongest trust signal is a useful result the user can verify. Not a demo on sample data that could be staged, and not a promise of what the product will do once fully set up.

We design each product's onboarding backwards from its first value moment:

The best first value moments rest on data the user already knows well. A merchant who sees yesterday's refund count correctly stated, with a sensible observation attached, has just done their own quality check on the product.

If first value requires setup that takes time — a store sync, a school licence, identity verification on a marketplace — we say how long it will take and show progress honestly. A clear "your first briefing will be ready after the sync, usually within the hour" is better than a spinner.

Consumer products need the same care in a different register. At ZodiVela, first value is a short reading, but the framing comes before the content: a single line explaining that readings are for reflection and entertainment, shown before the first one appears rather than tucked into terms. Credits and subscriptions are explained in plain numbers before anything is charged. People enjoy a product more when they know exactly what it is, and they are far less likely to feel misled later. See Positioning consumer AI as entertainment.

Principle 6: be honest about uncertainty and limits in the moment

Expectations set on the first screen fade. They need reinforcing at the points where they matter.

When the AI is less sure, the product says so. When a question is outside what the product covers, it says that too, rather than attempting an answer. When something needs a person, the route to that person is visible. See Designing human escalation paths in AI products.

We avoid confidence theatre in both directions. No percentage scores that imply a precision the system does not have. No excessive hedging on every line, which trains users to ignore warnings. A limit is stated once, clearly, where it applies.

A worked example: a merchant's first day with MerchNivo

Imagine a merchant installs MerchNivo on their Shopify store.

Minute one. The install screen explains, in three short lines, what MerchNivo reads (orders, products, inventory), what it does not do (change anything without approval) and where its numbers come from (the store). Permissions requested are read-only.

Minutes two to five. While the store syncs, the merchant sees a short example briefing, clearly labelled as an example, showing what a briefing looks like: figures in one style, explanation in another, each line linked to its source. It also shows what happens when there is not enough data, so the first real "not enough data yet" message is not a surprise.

First real briefing. Once the sync completes, the merchant gets a briefing about their own store. Every figure is clickable. The explanation is short. One suggested action is offered, with a note on why and a clear "do nothing" option.

The first mistake. Imagine the merchant disagrees with a suggestion — perhaps the assistant flags a product as slow-moving that the merchant knows is seasonal. The product offers a simple way to say so, and the note changes what the merchant sees next time. The assistant's reasoning was visible, so the disagreement is about judgement, not about whether the product is inventing things.

Nothing in that sequence depends on persuasive copy. It depends on the product being accurate, modest and checkable from the first minute. The store's own numbers do most of the persuading.

When the user is not the buyer

Onboarding gets harder when several people need to trust the product for different reasons. Two of our companies show this clearly.

At EduRelia, the school often chooses the product, the teacher introduces it and the student uses it, while families want to understand what it does with their child's learning. A single welcome screen cannot serve all four. So each gets its own short explanation, in its own terms. The school sees what data is processed, where limits sit and what it controls. Teachers see what the assistant will and will not do in a lesson and how to review what students see. Students get a simple, age-appropriate statement of what the helper is for. Families get a plain summary they can read without a login. The content differs; the facts underneath are identical, drawn from the same source-of-truth document. See B2B2C licensing for schools.

At CastLyra, talent and brands arrive with opposite worries. Talent want to know that their contact details, images and availability will not be handed to anyone who asks. Brands want to know that profiles are real. Onboarding for talent therefore starts with consent and contact-detail access rules — who can see what, and when — before any AI helps draft a profile. Onboarding for brands starts with what verification means on the platform and what it does not guarantee. The AI profile assistant appears only after those foundations are clear, and it works only from details the talent has supplied. See Verification in talent marketplaces.

The general lesson: map every party whose trust the product depends on, write down what each one needs to hear first, and make sure none of the messages contradict each other. A product that tells a school one thing and a family another will lose both.

What we avoid in onboarding

A few patterns erode trust in AI products quickly, and we keep them out deliberately.

• Anthropomorphic overselling. Giving the AI a personality that implies more understanding than it has. Friendly is fine; pretending to be a person is not.
• Hidden AI. Presenting generated text as if a person wrote it, or as if it were verified data.
• Dark-pattern consent. Pre-ticked boxes, bundled permissions, or making the product unusable without optional data sharing.
• Cross-product familiarity. An Oryvelon product never greets a user with knowledge from another Oryvelon product. There is no shared user data across companies, and onboarding must not imply otherwise.
• Staged demos presented as real. Example content is always labelled as an example.
• Tracking the user harder than the product needs. Onboarding analytics measure whether people reach first value, not everything they do.

Measuring whether onboarding builds trust

Trust is hard to measure directly, but its effects are visible. The signals we look at for each product's onboarding:

• Time to first value. How long from sign-up to the first real, useful result.
• Share reaching first value. How many new users get there at all.
• Source engagement. Whether users open sources in the first sessions. Some checking is healthy; none at all may mean sources are hidden, and heavy checking of the same item may mean something looks wrong.
• Early corrections and disagreements. What users push back on, and whether the product handles it well.
• Return in the first week. Whether people come back after the first session.

We read these as part of each company's 30/60/90-day checkpoints, and they feed straight into product decisions. A product where users reach value quickly but never return has a different problem from one where they never reach value at all.

A checklist for AI onboarding

• Is there a plain statement of what the AI does and does not do, visible before first use?
• Can users tell generated content from verified data at a glance?
• Does every factual claim show its source?
• Does onboarding ask only for what the first task needs?
• Is there a first value moment based on data the user can verify?
• Are waiting times stated honestly?
• Is the route to a person visible where it matters?
• Is example content clearly labelled?
• Are product and marketing consent separate?

Summary

Trust in an AI product is decided early, by what users see it do rather than what it claims. Our onboarding across Oryvelon's companies follows the same principles: state plainly what the AI does and does not do, visually separate generated explanation from verified data, show sources from the first screen, ask only for the data the first task needs, reach a checkable first value quickly, and be honest about uncertainty and the route to a person. The result is users who understand how the product works, check it when it matters and give it the benefit of the doubt when it earns it.

Questions and answers

How do you build trust in an AI product?

Set honest expectations about what the AI does and does not do, show where each answer comes from, ask only for the data the first task needs, and deliver one piece of real, checkable value early in the first session.

Should AI products tell users they are using AI?

Yes. Users should know which parts of the product are generated by AI and which come from verified data or people, so they can judge each part appropriately.

What is 'first value' in AI product onboarding?

First value is the moment a new user receives something genuinely useful and verifiable from the product, such as a correct summary of their own data, ideally within the first session and with as little setup as possible.

Published by Oryvelon, a digital company builder · About the group · Our companies · More in AI Operations

NextDesigning human escalation paths in AI products →