What makes good AI user experience for non-technical users?

01Start from the user, not the model

When product teams plan an AI feature, the first conversation is usually about the model: how accurate it is, what it can read, how much it can automate. For a product with a less technical user base, that is the wrong first conversation. This is part of our larger guide, AI integration for SaaS: add AI without a rebuild.

Many of the users on a regulated investment platform we worked on were older investors and issuers. They knew their deals well. They did not want to learn how an agent works, and they should not have to. That one fact decided the design more than any limit of the model: every agent gives recommendations, and a person always makes the call. Even a perfect model should not approve a deal for a user who cannot see why it was approved.

Before we design anything, we answer five questions with the product team:

1. 01

   Who is the least technical person who will use this feature, and what do they do today without it?

2. 02

   What happens if that person accepts a wrong suggestion without checking it?

3. 03

   Which decisions carry legal, financial or safety weight, and who is accountable for them today?

4. 04

   What words do users already use for their own work, so the feature can speak the same way?

5. 05

   Where do users look for proof that something worked, such as a saved record, a status or a confirmation message?

The answers become the boundary. They tell you where AI may act, where it may only suggest, and where it must stay out.

02Recommend, then let people decide

On that investment platform, issuers and the operations team used to copy deal data by hand from pitch decks, memos and financials into long deal forms. We built an issuer agent that reads the uploaded documents and fills the deal fields. The tempting design is to save those values straight into the deal. We did not.

Instead, the AI-generated deal is stored next to the human-entered one and the two are shown side by side, with a pre-publish gate that needs human confirmation. Once a person finalizes the data, the human version is the source of truth. A non-technical user does not have to trust the model. They compare two versions of something they understand and choose.

The same idea works for creative and analytical tools. On a governed internal-app builder we are engineering for a founder-led AI company, users turn their own company data into internal dashboards and apps. The edit agent works through select-and-edit and approval cards: the user points at the part they want changed, and the change is shown before it is applied. When the build agent is not sure how two tables join, it does not guess. It pauses and asks for approval, and a rejected join sends the build back to table selection. The user answers a plain question about their data instead of reading a query.

If you are adding agents like these to a product that already has users, our guide to adding AI agents to an existing SaaS product without rebuilding it covers the architecture side.

03AI user experience choices that build trust

Most of the work is choosing the humble option at each point where the AI touches the user. This table summarizes the patterns we use most.

The empty screen deserves a note. Non-technical users often do not know what to ask for. In the app builder, the product suggests three to five starter apps for each connected data source, worked out from catalog metadata that excludes personal data. There is a rule-based fallback if the model is unavailable. A good suggestion teaches the user what the feature is for faster than any help article.

04Make the reasoning visible in plain language

On the investment platform, risk outputs are structured flags only. Each one is traceable to its inputs and kept for audit. For a non-technical reviewer, a flag that says which document and which field triggered it is something they can check in a minute. A free-text paragraph of model reasoning is something they will either ignore or trust blindly, and both are bad outcomes.

Google's People and AI Research guidebook makes the same case in its chapter on explainability and trust. It says to help users calibrate their trust rather than maximize it, match the depth of explanation to the stakes, and state the product's capabilities and limitations early. Microsoft Research's Guidelines for Human-AI Interaction, tested with design practitioners against many AI products, organize their advice around the moments that matter. Those moments are at first use, during regular use, when the AI is wrong, and over time. For non-technical users, the moment when the AI is wrong is the one to design first.

A few practical rules follow:

• Use the user's terms in every label and message, not the model's or the engineer's.
• Show where an answer came from, such as the uploaded document or the data source, next to the answer itself.
• Show confidence only when it helps a decision, and prefer simple levels over percentages.
• Make undo or reject as easy as accept.

05Keep the hard boundaries in the product

Some lines should never depend on a user noticing a mistake. On the investment platform, AI never approves a deal, a KYC check or tokenization. It produces structured outputs and recommendations, and an admin or a human placement officer decides. Token lifecycle states cannot be skipped, and templates stay under admin control. These rules live in the platform, not in a prompt.

In the app builder, a security scan runs before any app is published and blocks publishing on serious issues: leaked secrets, unsafe SQL, unsafe content or columns holding personal data. Users who are not engineers cannot judge whether a generated query is safe, so the product does not ask them to. It checks for them and explains what it found.

The principle is simple. The less technical your users are, the more of the safety work the product has to carry on their behalf.

06What we see in production

On the regulated investment platform, a financial services marketplace for private placements, we built the AI as services around the existing .NET application. The client's own team built and integrated the front end. That split taught us to design the review step into the data itself. Each AI output had to carry what the front end needed to show it beside the human version and to hold it behind the confirmation gate. If the review step is not in the API contract, a separate front-end team will not invent it.

The agent design also grew a great deal during the work, from the handful of agents first scoped to many more, each with a narrow job in the deal lifecycle. Narrow agents turned out to be easier to explain to users, because each one does one recognizable thing, such as reading a pitch deck or preparing an investor report.

On the app builder, which is still in development and not yet in customers' hands, the governance features came first in the plan rather than last. They were the append-only audit log, join approval, query validation and publishing scans. We see that order pay off whenever a product will be used by people who cannot inspect what the AI produced.

07A short checklist before release

• A person confirms before AI output becomes a saved record.
• Every AI suggestion shows its source in terms the user recognizes.
• Regulated or risky steps cannot be completed by the AI under any prompt.
• Rejecting a suggestion is one click and leaves the user's work intact.
• New users see suggestions drawn from their own data, not an empty box.

Frequently asked questions