How to design an ai chatbot user interface (2

ai chatbot user interface (2: what should appear before the first message?

Answer. Put clear promises and limits on the screen before a user types. Brief onboarding or a short disclaimer should state capabilities, limits and verification actions, and link those to lightweight checks the user can run from the chat prompt, as Nielsen Norman Group recommends (Nielsen Norman Group, 2025). See our AI product design service for component and copy patterns that make those promises testable.

A concrete scene. A person opens your product and sees the chat entry. They decide instantly whether this assistant is for drafting, for factual lookup or for policy guidance. Name the tasks the assistant can handle, give example prompts that produce good output, and state what it will not do and who to contact for those cases. That single screen sets expectations and reduces misuse.

Turn promises into checks. If you claim the assistant cites sources, surface an obvious 'view sources' affordance. If you promise human review, surface the escalation control and the expected service window. These are product choices that change what you must log and audit at runtime, not small copy edits. The interface must make the verification actions discoverable and usable from the place the user starts typing.

How should the chatbot show it is thinking?

Answer. Match the progress indicator to the wait time and surface what the system is doing for longer waits. Nielsen Norman Group recommends delaying any indicator until roughly one second, using an indeterminate spinner for waits of a few seconds, reserving skeleton screens for short content‑shaped loads, and switching to a percent‑done indicator when waits exceed about ten seconds (Nielsen Norman Group, 2014).

A scene that goes wrong. A user asks the chat for a multi‑source summary. If the model can stream the answer quickly, let text arrive as it is generated. If the model calls external tools and work takes several seconds, show labelled steps so the user understands the work in progress. If the operation will take noticeably longer because it runs search then reasoning, surface a determinate progress cue when the system can compute percent complete.

Make the work visible. Management Science research shows users prefer visible work when waits are long: in one experiment users chose a transparent progress display over a blind progress bar at noticeable delays, which means reveal work steps when latency is noticeable (Management Science, Buell & Norton, 2011). Practical tactics are streaming text, step labels when tools are called, and switching to a determinate indicator only when it is reliable.

How should a chatbot show sources and provenance?

Answer. Put provenance cues close to the answer, make sources inspectable, and surface clear verification actions. A recent systematic review found disclosure and provenance cues change credibility judgments, but their effect depends on wording, placement, framing and whether human oversight is signalled (Frontiers in Artificial Intelligence, 2026). Design provenance so users can run quick checks with minimal friction.

Design for quick checks. Show a short source snippet under the answer and a compact list of source titles with a 'view original' link that opens the cited passage. Keep the main answer concise so provenance is visible without scrolling. If a user wants more, expand into a panel with the passage highlighted and the retrieval query alongside it.

Choose explanation styles with care. A narrative review reports that counterfactual explanations reduced overreliance compared with salient‑feature explanations in the studies it synthesised, which means explanation style can help users test claims rather than persuade them (MDPI, Information, 2026). Use explanation formats that make it easy to falsify a claim or to repeat the verification step yourself.

Practical UI patterns. A small provenance badge beneath each claim that opens a compact source list, highlighted passages with direct links to the original, and an explicit verification control such as 'compare with source' or 'show retrieval query' let users check results quickly. When users upload files, show which uploads contributed to the answer and a confidence cue for each file so users can prioritise checks.

How should the chatbot phrase uncertainty so users can act?

Answer. Phrase uncertainty to guide verification, not to offload responsibility. An experiment reported at FAccT found that first‑person hedging such as 'I’m not sure, but...' reduced user agreement and confidence while improving task accuracy, which shows wording affects how users respond to model uncertainty (Proceedings of ACM FAccT, Kim et al., 2024). Pair any confidence cue with an explicit next action so users know what to do.

Actionable templates you can copy. Replace vague hedges with a short confidence cue plus a next step. For example, 'Confidence: Medium. Check source A or request a citation' or 'Confidence: Low. The model may lack recent data. Request sources or escalate to human review.' The wording reduces blind trust while keeping the next action obvious.

Visual language. Use a compact badge with a small set of states such as high, medium and low confidence so people can scan answers. Pair the badge with a nearby action button that runs the verification step, shows the retrieval query or starts an escalation. Keep the verification action immediately accessible from the answer itself.

What should the UI do when the model is wrong or cannot answer?

Answer. Design the failed state first. Show the answer, its provenance and confidence; surface verification controls; and offer clear paths to edit, retry or hand off. CHI guidelines and Microsoft’s HAX toolkit recommend preserving provenance, making actions reversible, keeping humans ready for takeover and recording an auditable trail rather than relying on token checkboxes (Amershi et al., CHI/HAX, 2019).

A single‑screen pattern. Present the suspected wrong answer with a provenance strip and a confidence cue. Below the answer surface Accept and save, Edit the answer in place, and Escalate to human review. If the user edits, record the delta and give a clear 'submit correction' control that adds the edit to support or retraining logs. If the user escalates, include the transcript, provenance and verification attempts in the escalation packet.

Make retries useful. Offer a 'Try variant' control that rephrases the prompt into a constrained alternative such as 'Restrict to academic sources' or 'Focus on dates only.' Log which variant produced better output so the product team can improve prompt templates and reduce repeated errors.

Design the recovery workflow for support. Surface actions that let support reproduce the issue: the retrieval query, the top sources, the model and model settings, and any user edits. That bundle is what support needs to triage and what machine learning teams need for retraining rather than asking users to fill forms retroactively.

If you want the single‑screen accept, edit and retrain pattern, see our article on chat correction UX which specifies components, editable fields and auditing rules to implement this flow and keep recovery discoverable from the error state. That pattern is the bridge between product, support and ML teams.

How do I turn these choices into a buildable system?

Answer. Define a dynamic design system that lists the components the model may use, the states each component supports, and the rules for when each state may appear so the runtime UI is predictable and testable. That document is the product to engineering contract your developers implement. See our dynamic design systems and AI product design services for the handoff artefacts engineers need.

Inventory the parts. Typical components include result cards, provenance badges, streaming text blocks, skeleton layouts, spinners, percent bars and handoff panels. Typical states include loading, streaming, uncertain, failed and accepted. Rules define when to use each state such as when the model calls external tools or when provenance is required for a claim.

Write runtime rules as interface contracts. For every model decision and user action specify which component may appear, which properties it receives and which audit events must be emitted. For example, when the model calls a search tool emit step labels such as 'Searching sources' and 'Ranking results', stream partial text while results arrive and record the search query plus the top source identifiers in the audit log. That audit log becomes the source of truth for support and retraining.

Decide how the model chooses components. Constrain the model to a small palette of components and a set of deterministic rules so it cannot render arbitrary layouts. Teams implement this by mapping component IDs to front‑end templates and exposing a clear API for the model to request a component with a fixed set of inputs. Engineers then add hooks that capture every user edit as a recorded delta for downstream use.