Users Trust the Source Before They Trust the Answer

Picture the person on the other side of an enterprise AI feature. Not a curious consumer poking at a chatbot. A research analyst at a bank, forty minutes from a deadline, who has to put a number in front of an investment committee. If that number is wrong, it is not the model that gets the blame. It is them.

That is the user I spent the last few years designing for. Everything I believe about AI UX comes from watching that person decide whether to trust a machine.

Users trust the source before they trust the answer.

That is the whole thing. If you take one sentence from this page, take that one. Almost every good decision I made downstream came from it, and almost every mistake came from forgetting it.

Nobody Acts on a Confidence Score

The instinct when you ship a probabilistic system is to expose the probability. Show a confidence percentage. Let the user decide.

It does not work. Tell an analyst an answer is 87% confident and you have told them nothing they can use. 87% of what? Compared to what baseline? What does the other 13% look like, and would they recognise it if they saw it? A percentage feels like transparency to the team that built the model. To the person who has to defend the number in a meeting, it is noise wearing a lab coat.

What they actually want is smaller and much more boring. Where did this come from. Can I open it. Does it say what the summary claims it says.

So the interface leads with provenance instead of probability. Every significant claim carries a direct, checkable citation, and the path back to the primary document is one click, not a footnote. On Factiva AI Smart Content that meant the reframe was not really about AI at all. It was moving Factiva search from find the documents to get the answer, with the documents attached.

Design the Distrust State First

Most AI features are designed for the happy path and then patched for doubt. Do it the other way around. Design the moment where the user does not believe you yet, because that is the moment that decides whether the feature gets used twice.

Concretely, that means three things.

AI-generated text must be visually distinct from primary content. If a user cannot tell at a glance which words a machine wrote and which words came from a licensed source, you have not built a research tool. You have built a liability.

Low-confidence and no-answer states must be explicit, and they must be designed, not degraded. An honest I cannot answer this builds more trust than a fluent paragraph that turns out to be wrong. Every hedge the system does not make is a hedge the user has to make for it.

And disagreement has to surface. Real sources contradict each other. A system that quietly picks a winner is making an editorial decision on the user's behalf and hiding it. On the conversational assistant work, flagging when trusted sources disagree made verification a visible part of the interface rather than fine print.

Do Not Build an AI Mode

The most common enterprise AI mistake I see is shipping a separate destination. A tab. A sidebar. A place you go to do AI.

Expert users do not have a job called using AI. They have a research workflow they have run for a decade, and they will not leave it to visit your chatbot. If the AI is not inside the thing they already do, it does not get used, no matter how good the model is.

Anchor the feature in the existing workflow. Give the user an escape hatch back to primary sources at every step. This is the same discipline that makes advanced search and a risk and compliance dashboard work: meet the expert inside the task, do not invent a new place for them to stand.

What I Would Do Differently

Push verification and currency patterns earlier. Much earlier. I treated them as things to solve once the core experience worked, and they turned out to shape nearly every downstream decision. Trust is not a layer you apply at the end. It is the load-bearing wall, and you find that out expensively if you frame it late.

The sequencing lesson underneath it: solving the blank-slate problem earned the right to solve the harder ones. Memory. Multi-entity analysis. Collaboration. You do not get to those until the first answer is trustworthy, because nobody comes back to a tool that burned them once.

The Part That Transfers

None of this is specific to financial research. It applies anywhere a professional stakes their name on a machine's output: clinicians, lawyers, compliance officers, engineers signing off on a spec.

The pattern is always the same. The model is not the product. The model is a component. The product is the apparatus around it that lets a competent, skeptical, accountable adult decide whether to believe it this time.

Build that apparatus and a mediocre model becomes useful. Skip it and a brilliant model stays a demo.