Designing Against Hallucinations: UX Guardrails for AI Products

Picture this: you vibe-coded an app with an AI Q&A feature. You pulled a weekend all-nighter on styling, wired up the domain, posted it to your feed, and by Monday a few hundred users are pouring in. On Tuesday, someone drops a screenshot in the comments — your AI solemnly told them: "We're open until 10 PM on weekends," when your shop actually closes at 3 PM on Saturdays. The user made a wasted trip and left you a one-star review: "The AI lies."

The sting is that the review is right. You know perfectly well that large models hallucinate, but users don't blame the model — they uninstall your app. A hallucination is not a technical bug; from the user's side, it is a trust incident.

This guide takes a clear stance: you can't eliminate hallucinations, but you can design how much damage they do. The same hallucination, shown naked versus shown behind guardrails, differs by an order of magnitude in the trust it destroys. The key to protection is not on the model side (which you can't touch) but on the UX side (which is entirely yours). The eight sections below are a copy-paste-ready protection system for a vibe developer.

1. Know what you're defending against: three kinds of user harm

Don't treat hallucination as a technical term. In front of users it has three distinct faces, each with a different harm mechanism and a different defense. Confusing them is like confusing a cold with the flu and prescribing the wrong medicine.

Harm 1: False facts — fabricated "facts"

The model invents opening hours, prices, policies, and phone numbers that sound completely real. This is the most common crash, and the easiest trap for vibe products, because vibe products usually wire up real business information (stores, prices, rules) — exactly the kind of information that was never in the model's training data.

A real case: in 2024, Air Canada's chatbot invented a bereavement fare policy that didn't exist. A passenger believed it and bought a ticket. The airline tried to argue the bot was an independent third party; the tribunal disagreed and ordered Air Canada to pay up. Every chatbot team now uses this as a cautionary tale: what your bot says is, legally, what you said.

The harm formula: false fact × user takes action = real loss. If the user just reads it, the loss is trust. If the user acts on it, the loss is real money and legal liability.

Harm 2: Fabricated citations — the most convincing lies

Citations are the currency of trust in academic and professional settings, and models are excellent counterfeiters. They invent case numbers, paper titles, and report links — perfect formatting, entirely fictional content.

A real case: in 2023, US lawyer Steven Schwartz submitted ChatGPT-fabricated case law in Mata v. Avianca. The judge checked and found the cases didn't exist; the lawyer was fined and publicly reprimanded. A more recent one: in early 2025, Apple's Apple Intelligence notification summaries "summarized" BBC headlines into events that never happened. The BBC complained directly, and Apple was forced to suspend the feature.

The vicious part of fabricated citations: they hijack the user's verification habit. Seeing "cf. Case X, Vol. 3," users instinctively think "there's a source, it must be legit" and skip verification. With no citation, users stay alert; with a fake citation, they don't even bother.

Harm 3: Confident misleading — the more certain the tone, the bigger the harm

The first two are content problems; this one is an expression problem. Models are born confident storytellers, extremely stingy with "I don't know." Medical, financial, and legal advice delivered in an "I recommend…" / "definitely fine" tone dramatically raises the odds that users act on it.

In 2023, Google's Bard demo confidently flubbed an astronomy question, and Alphabet's market cap shed over a hundred billion dollars that day. The market reaction is investors' business; the real lesson is: users calibrate trust on tone, not content. The same answer with the word "maybe" added cuts users' willingness to act sharply — and that's exactly the leverage point for UX guardrails.

Remember this harm equation: presentation credibility × content actionability = hallucination damage. The whole protection system exists to push both multipliers down.

A note on what makes vibe products special: big companies have legal teams, evaluation teams, and staged rollouts. You have none of that. Your app may be the first AI product a user ever takes seriously — their trust threshold is lower, one crash and they leave, and they'll post the screenshot on social media. A big company's hallucination is a PR incident; yours is an existential one. Don't think "my little product, nobody will scrutinize it." It's the opposite: every hallucination in a small product happens naked.

2. Confidence display: a three-tier UI pattern — never show percentages

A counterintuitive conclusion first: don't display confidence as a number. "This answer is 87% confident" looks scientific, but the number itself is made up — you're annotating one hallucination with another. Users can't tell 87% from 72% anyway; the false precision only adds confusion.

What works in practice is a three-tier system: high / medium / low. Fewer tiers mean faster user decisions. The UI spec for each tier:

• High confidence (green, non-intrusive): display the answer normally, no extra warnings needed. Conditions: the answer comes from your own knowledge-base retrieval with highly relevant hits, or the model generated it twice independently with consistent key claims. Note: high confidence doesn't mean "guaranteed correct" — it means "we have evidence." Disclaimers can shrink to a minimum.
• Medium confidence (yellow, verify reminder): a gentle note next to the answer: "Generated by AI — please verify key details." Don't use red: red means "danger" and scares users away; yellow means "heads up," which matches exactly the "useful but don't fully trust" mindset. Most AI answers should live in this tier.
• Low confidence (gray, proactive downgrade): the whole answer card turns gray, slightly smaller type, leading with "The AI isn't sure about this," and the "Correct this" button placed front and center. The goal of a low-confidence answer isn't to be read — it's to be corrected.

A key detail: score confidence per claim, not per answer. In one answer, "today is Friday" is high confidence while "the return policy is 30 days" is low confidence; labeling the whole thing "medium" labels nothing. On the engineering side, start with coarse rules: any claim containing numbers, dates, person names, place names, or URLs gets downgraded one tier by default — these are precisely the hallucination hot zones.

Where does confidence come from? A solo developer doesn't need a fancy calibration model; three signals are enough:

1. Retrieval hits: if you have RAG, the similarity scores of retrieved passages are the most honest signal. No hits or weak hits → straight to low confidence.
2. Self-check consistency: have the model answer the same question twice (temperature > 0); if key claims disagree → downgrade. This doubles cost, so reserve it for high-risk scenarios.
3. Rule-based downgrades: the numbers/dates/proper-noun rule above, plus an automatic downgrade whenever the model says things like "I remember" or "based on my knowledge" — the harder the model insists it remembers, the more likely it's inventing.

Shippable code — a React confidence badge component in 30 lines:

type Confidence = 'high' | 'medium' | 'low';

const CONFIDENCE_UI: Record<Confidence, { label: string; className: string; note: string }> = {
  high:   { label: 'Sources verified', className: 'badge-green',  note: '' },
  medium: { label: 'AI generated · verify advised', className: 'badge-yellow', note: 'Confirm key details via official channels' },
  low:    { label: 'AI is unsure', className: 'badge-gray',   note: 'Low-confidence answer — corrections welcome' },
};

export function ConfidenceBadge({ level }: { level: Confidence }) {
  const ui = CONFIDENCE_UI[level];
  return (
    <span className={`confidence-badge ${ui.className}`} title={ui.note}>
      {ui.label}
    </span>
  );
}

// Backend scoring: rules first, simple and explainable
function scoreClaim(claim: string, retrievalHits: number): Confidence {
  if (/\d{4}|\$\d+|https?:\/\/|[A-Z][a-z]+ [A-Z][a-z]+/.test(claim)) return 'low'; // numbers/proper nouns downgraded by default
  if (retrievalHits === 0) return 'low';
  if (retrievalHits < 3) return 'medium';
  return 'medium'; // default to medium: conservative beats bold
}

Note the last line: the default tier should be "medium," not "high." High confidence is earned (retrieval, verification), not default. Many products get this exactly wrong — everything defaults to high confidence until a crash forces warnings in.

One more nuance on display timing: don't make all three tiers equally loud. The high-confidence badge can be tiny, showing its full text only on hover; medium gets a persistent yellow strip; only low confidence deserves to steal visual focus. The design principle for guardrail UI is "allocate attention by risk" — the riskier the state, the harder it should grab the user's eyes. Conversely, slapping a big red warning on every answer is crying wolf; after three days users stop seeing it.

3. Citations: every key claim traceable

Confidence answers "how sure," citations answer "verifiable by whom." If a user can verify a claim's source in two clicks, even a hallucination does limited damage — the user will catch it themselves. But there's a precondition: the citations must be real.

An iron rule first: only clickable, openable, content-matching references count as citations. A "[1] Some Report" the model tossed off is not a citation — it's decoration. Decorative citations are more dangerous than no citations (see fabricated citations in Section 1), so a citation system must verify.

The citation component's data structure

Don't concatenate citations into the body text as strings; make them structured data. Each key claim is a Claim with its citation list:

interface Citation {
  id: string;          // citation number c1, c2...
  label: string;       // display name: "Return policy page"
  url: string;         // must be reachable
  quote: string;       // source excerpt, ≤60 chars
  verifiedAt: string;  // last reachability check
}

interface Claim {
  id: string;
  text: string;                 // the claim itself
  confidence: 'high'|'medium'|'low';
  citations: Citation[];        // key claims need at least 1
}

// Ground rule: verify every citation URL is reachable before storing
async function verifyCitations(claim: Claim): Promise<Claim> {
  const checked = await Promise.all(claim.citations.map(async (c) => {
    try {
      const r = await fetch(c.url, { method: 'HEAD', signal: AbortSignal.timeout(5000) });
      return { ...c, verifiedAt: r.ok ? new Date().toISOString() : '' };
    } catch { return { ...c, verifiedAt: '' }; }
  }));
  const alive = checked.filter(c => c.verifiedAt);
  // All citations dead → claim auto-downgrades to low confidence, never silently stripped
  return { ...claim, citations: alive, confidence: alive.length ? claim.confidence : 'low' };
}

The last two lines are the soul of this snippet: when citations die, the correct move is to downgrade the claim, not hide the citations. Quietly removing citations swaps an "evidenced claim" for an "unevidenced claim" without the user ever noticing.

Two UI patterns — pick by scenario

• Inline superscript (Q&A, customer support): "The return window is 30 days[1]" — clicking the superscript pops a citation card (title + excerpt + jump link). Pro: doesn't interrupt reading. Con: tiny tap targets on mobile — make superscript hit areas at least 32px.
• Side citation panel (long answers, research reports): a dedicated "Sources" column where numbered claims map to references. Pro: auditable. Con: eats space. Best for desktop admin panels and learning products.

One easily missed rule: citations need a freshness stamp. Policies, prices, and versions expire; a 2023 citation can become a fresh hallucination source in 2026. Put a small "source updated 2024-03" line on each citation card, and auto-flag stale ones yellow. This matters doubly for vibe products, whose knowledge bases are often loaded once at launch and never maintained.

4. "Draft, not answer": wording and visual downgrade tactics

The cheapest, fastest win. The core idea in one sentence: don't let AI output look like "the answer." Users treat "answers" and "drafts" as two different postures: answers are for using, drafts are for editing. You want to flip the user from "use" to "edit."

Draft badge spec

Every AI-generated content block gets a badge in its top-left corner. Three rules:

1. Write like a human: "AI draft — please verify," not "This response was generated by artificial intelligence and is for reference only." The former is an action instruction (go verify); the latter is liability blah-blah (users read it and do nothing).
2. Style it "unfinished": dashed border, light gray background, small italic text. The visual language tells users "this isn't final." Never use a gold-gradient mega-badge — the fancier the packaging, the more users take it as gospel.
3. Place it before the content: the badge must appear before the user reads the content. A badge at the end of an answer is read after the fact — which is to say, never.

The geography of disclaimers

Disclaimers live in three places, with wildly different effectiveness:

• Page footer (worst): nobody reads it. Equals nothing, plus clutter.
• Under the input box (okay): "AI can make mistakes — verify important info" where users type sets expectations upfront. Fine for general chat products.
• Before the user's action (best): when an AI answer contains actionable advice (call, pay, take medicine, sign), show a targeted prompt next to the action button: "AI suggestion above — confirm with official sources before acting." This is the direct lesson of the Air Canada case: disclaimers belong at the moment users reach for their wallets, not in the footer.

Wording blocklist and allowlist

Constraining wording in the system prompt treats the root cause better than UI patches after the fact. Give the model a wording spec:

• Banned: "definitely," "guaranteed," "without a doubt," "officially confirmed" — the model has no standing to make guarantees on your behalf.
• Use with care: "based on my knowledge" (a classic hallucination tell — downgrade confidence on sight).
• Recommended: "possibly," "consider," "one common approach is" — swap statements for suggestions, swap "what is" for "what you could try."

Anti-pattern warning: don't do disclaimers as modal popups. Users click "Got it" with their eyes closed, and after three times they don't even look. Popup disclaimers are a placebo for legal, not a guardrail for users.

5. One-click correction loop: make every user correction count

The first four sections are defense; this one is counterattack. Hallucinations can't be eliminated, but every hallucination a user flags is free labeled data. Products with a correction loop see hallucination rates fall over time; products without one are still making the same mistakes three years later.

But there's a brutal precondition: a correction entry nobody processes is worse than none at all. A user spends 30 seconds correcting you; it vanishes into the void; next time they won't correct — they'll just leave. So before shipping this feature, ask yourself: can I spare one hour a week to process corrections? If not, don't ship it yet.

The feedback component: correctable in three seconds

Every extra field in a correction form halves completion. The minimum viable shape: two buttons at the bottom-right of every AI answer — "Helpful / Correct this." Clicking "Correct this" opens one input asking exactly one thing:

export function CorrectionBox({ claimId, onSubmit}: { claimId: string; onSubmit: (c: Correction) => void}) {
const [text, setText] = useState('');
return (
<form onSubmit={(e) => { e.preventDefault(); onSubmit({ claimId, text, at: new Date().toISOString()}); setText('');}}>
<p>What went wrong? One sentence is enough.</p>
<textarea value={text} onChange={(e) => setText(e.target.value)}
placeholder="e.g. Return window is 7 days, not 30 — official link…" rows={3} required />
<button type="submit">Submit correction</button>
<p className="hint">Thanks! Verified corrections improve future answers.</p>
</form>
);
}

interface Correction { claimId: string; text: string; at: string;}

Detail: after submitting, give the user an explicit receipt ("Received — thanks for the correction"), not silence. Users need to know their 30 seconds weren't wasted.

Feeding corrections back: a few-shot template

Once a correction lands, the lightest way to feed it back isn't fine-tuning — it's turning the correction pair into few-shot examples appended to the relevant scenario's prompt:

CORRECTION_PROMPT = """
You are a support assistant. The following correction has been human-verified.
Apply it to similar questions going forward:


User: What is your return policy?
AI: 30-day no-questions returns. [1]


Correct answer: 7-day no-questions returns; customized items are final sale. [1]
Correction note: The window is 7 days, not 30; customized items excluded.
Effective: 2026-10-01

Rules:
1. For return-policy questions, prefer the corrected version;
2. Never repeat the wrong example's "30 days";
3. If users ask for details, cite the official returns page.
"""

Engineering tip: bucket the correction library by topic (returns / pricing / hours…), retrieve relevant corrections per topic before each answer, and splice them into the prompt dynamically. A solo developer can run this on SQLite with a vector column — no vector database required.

Measure the correction rate, not the hallucination rate

Hallucination rates are hard to measure precisely (they need heavy human labeling), but correction rate = corrected answers / total answers is free. It's imperfect — the silent majority never corrects — but it's real-time and directionally correct. Correction rate climbing two weeks in a row means some knowledge changed (you updated the return policy but not the knowledge base) — go look. Correction rate trending down long-term means the loop is working.

6. High-risk circuit breakers: red lines for medical, legal, and financial

Everything so far was "soft" protection; this section is the "hard" circuit breaker. In some scenarios the cost of a hallucination isn't a bad review — it's the wrong pill, the wrong contract, the lost principal. For these, the UX strategy switches from "downgraded display" to "refuse or hand to a human."

Start with a risk-tiering checklist — walk your vibe product through it row by row before launch:

Scenario	Risk tier	Circuit-breaker action
Medical diagnosis, medication advice	Critical	Refuse direct answers; switch to "info retrieval mode": authoritative source links only + mandatory "consult a doctor" prompt; never name specific drugs or dosages
Legal interpretation, contract review	Critical	Lead with "not legal advice"; case-specific questions → route to a human lawyer entry, no conclusions given
Investment advice, stock picks	Critical	Refuse individual stock picks; only organize public information, every data point with source and timestamp
Support: prices, policies, hours	High	Must hit the knowledge base via RAG; no hit → say plainly "couldn't find it, suggest contacting a human" — never invent
Tutoring, coding Q&A	Medium	Three-tier confidence + citations suffice; for code answers, nudge users to run tests first
Chit-chat, creative writing	Low	One generic disclaimer is enough; hallucination here is arguably a feature

The engineering can be dead simple: maintain a high-risk keyword list ("take medicine," "dosage," "sue," "contract," "which stock to buy"…). Questions hitting the list auto-route into the breaker flow. The list doesn't need to be perfect — 50 words is enough for v1; the correction loop grows it over time.

A human review gate is standard for critical-tier scenarios: the AI drafts, a human clicks "approve" before it reaches the user. For a solo developer this means a "pending review" queue in your admin panel. Don't see it as a step backward — "AI drafts + human approves" is currently the most accepted pattern for medical/legal products, and the one regulators are most likely to accept. It also solves cold-start trust: with low early volume, you can review everything.

One sentence for this section: risk tier dictates UX shape. Low-risk scenarios are about experience; high-risk scenarios are about liability. Styling medical advice as a confident standard answer isn't a design problem — it's a liability incident.

7. Evaluation: a manual hallucination spot-check SOP

No measurement, no improvement. But a vibe team can't afford a labeling team. The answer: a weekly 30-sample manual spot check — small enough to sustain, large enough to catch trends. Best bang-for-buck evaluation there is.

Sampling: stratified + oversampled

1. Randomly pull 30 AI answers from the past week's logs;
2. Oversample high-risk scenarios: medical / legal / financial / pricing-policy items must be at least 10, even if they're only 5% of volume. Hallucination harm isn't evenly distributed, so sampling shouldn't be either;
3. Verify each one yourself (or with a friend): is each claim correct? Are citations real and reachable? Is the confidence tier reasonable?
4. Dual annotation: once a month, have two people label the same week independently, and discuss disagreements — that's how you calibrate your own judgment.

The weekly 30-sample log

Copy this table — a spreadsheet or Notion page works fine:

#	Date	User question (anonymized)	Scenario	Claims correct?	Citations real?	Tier reasonable?	Issue type	Action
001	10-07	How many days is the return window?	Support–policy	No (said 30 days, actually 7)	Link 404s	No (marked high)	False fact + dead citation	Added to correction library; citation checks on a cron
002	10-07	Can I take this with cold medicine?	Medical	Partially	No citations	No (should have broken, didn't)	High-risk breaker miss	Keyword list += "take with"; route to human flow
003	10-08	Write me a birthday message	Chit-chat	Yes	N/A	Yes	—	—

Keep the "Issue type" column as a fixed enum: false fact / fabricated citation / dead citation / confident misleading / breaker miss / tier mislabel. With fixed enums, a few months in you can chart trends: which issue types are shrinking, which are growing.

Tripwires: when to roll back

Spot checks aren't for writing reports — they're for triggering action. Set two hard lines:

• Overall hallucination rate > 15% (more than 4–5 of 30 problematic): roll back to the last cleanly-checked version before shipping the next prompt or knowledge-base update;
• One breaker miss in a high-risk scenario (should have refused or routed to human, didn't): fix it that day, not next week.

Is 15% made up? Yes. But a made-up line beats no line. Run it for three months, then tune it against your data. The first purpose of measurement is to start measuring; accuracy comes second.

The spot-check log has a long-term value too: it's your evidence when talking to users, regulators, and your future self. When someone asks "is your AI reliable," your answer shouldn't be "we use the most advanced model" — it should be "360 samples over the last 12 weeks, zero breaker misses in high-risk scenarios, overall hallucination rate down from 18% to 9%." Data won't win trust for you, but without data there's nothing to win it with.

8. Pre-launch self-check: 8 items

Finally, compress the whole guide into one checklist. Tick each item before shipping any release with AI-answer features:

1. Is the default confidence tier "medium"? Check that answers without evidence aren't defaulting to high confidence.
2. Does every AI answer block carry a draft badge? Top-left, before the content, dashed border, "AI draft — please verify."
3. Do all citations open? Run the reachability check; fix or downgrade 404ing citations.
4. Are numbers/dates/proper nouns auto-downgraded? Verify the rule regex fires — test three samples by hand.
5. Is the high-risk keyword list wired up? Search "take medicine," "sue," "which stock" and confirm correct breaker behavior.
6. Does the correction entry have an owner? Name one hour a week for processing (that's you), and make the pending queue visible in admin.
7. Does the disclaimer sit next to the action button? Not just in the footer.
8. Is the spot-check sheet ready? This week's 30 samples: when to pull, who labels — put it on the calendar.

Items 1–4 are a weekend's work (badge component + rule downgrades + citation checks + default-medium). Items 5–8 are process (keyword list, correction duty, disclaimer placement, spot-check calendar). Suggested order: do 1–4 first so the product looks honest, then 5–8 so it stays honest.

Back to the opening thesis: hallucinations can't be eliminated, but "confidently talking nonsense" can be designed away. What truly enrages users was never "the AI got it wrong" — it's "it was wrong so confidently, and I actually believed it." Your job is to keep users out of that situation: say how sure you are with three confidence tiers, give users verification handles with real citations, lower the urge to act with draft posture, hold the high-risk red lines with breakers, and make every crash count with the correction loop.

Trust is a bank account: every hallucination is a withdrawal, every honest "I'm not sure" is a deposit. Whether a vibe product's AI feature survives doesn't depend on how strong the model is — it depends on whether that account is in the black. Start with this weekend's first deposit.

One last note for fellow vibe builders: don't try to build the whole protection system to full marks in one go. Make the product look honest first (badges, downgrades, wording) — users will give you time to make it stay honest (corrections, spot checks, breakers). The reverse order doesn't work: an AI that never admits uncertainty gets exactly one crash before it's game over.