By Mehdi HassanHow do you design a dashboard for an AI product?
Design a dashboard for an AI product by making every machine output easy to check, correct and trust. A normal dashboard shows data the system knows is true. An AI dashboard shows output the system believes is probably right, so the interface has to show sources, confidence and a clear path to fix mistakes.
Vendor guides and design-system teams have settled on a similar set of patterns: visible plans, approvals and logs, undo, citations, distinct loading states and shown uncertainty. Most of the advice is opinion rather than user data, so test these patterns with your own users. This guide covers each one and how they fit together. For how the product is sold on the marketing site, see our hub on AI startup website design.
How should an AI dashboard show sources and citations?
An AI dashboard should attach a source to every claim a user might act on, placed right next to the claim, not in a list at the bottom. Inline numbered markers that open a preview of the source passage let users check a fact without leaving the screen.
- Cite at the sentence level for summaries and answers, so users can check the one claim they doubt.
- Preview the passage, not just the file name. Highlight the exact lines the answer used.
- Show when there's no source. If the model is reasoning or generating rather than retrieving, label it, so users don't assume a citation exists.
- Link to the record in your product, such as the ticket, contract clause or row, not just an external document.
How do you show confidence and uncertainty in an AI interface?
Show confidence through behavior and language, not decimal scores. Most users can't act on "0.73". They can act on a result marked "needs review", a highlighted field the model wasn't sure about, or a short note like "two sources disagree on this date".
AI state | What users need to know | Design pattern |
|---|---|---|
Thinking | It's working and roughly how long | Progress steps or a named stage, not just a spinner |
Streaming | Text is still arriving | Visible cursor, actions disabled until done |
Done, confident | It's ready to use | Normal styling, sources attached |
Done, uncertain | Which parts to check | Highlighted fields with a short reason |
Needs approval | Nothing happens until they confirm | Clear plan, approve and edit buttons |
Failed | What went wrong and what to try | Plain error, retry, fallback to manual |
Each state should look different at a glance. If "done" and "uncertain" share the same styling, users will treat every output as done. Color alone isn't enough; pair it with an icon or label so the states work for color-blind users, and check them against our accessible web app UI checklist.
How should human-in-the-loop controls work on an AI dashboard?
Human-in-the-loop controls should put approval where a mistake is expensive and stay out of the way where it isn't. Sending an email to a customer, moving money or deleting records needs a confirm step. Drafting, tagging and summarising usually don't.
Show the plan first
Before an agent acts, list the steps it intends to take in plain language, with the records it will touch.
Let users edit the plan
Allow removing a step or changing a target before approving, not just yes or no.
Approve by risk, not by habit
Require confirmation for irreversible or external actions; let low-risk steps run.
Log every action
Keep a readable timeline of what the AI did, when and why, filterable by user and record.
Make undo real
Offer undo for each action in the log, and say plainly when an action can't be undone.
Teams in high-stakes domains can borrow from adjacent patterns: security dashboard design handles triage and alert fatigue, and fintech dashboard design handles confirmation for money movement.
Should an AI dashboard be a copilot, an agent or a chat?
Choose the layout from the job, not from what's fashionable. A copilot helps inside an existing workflow, an agent completes tasks on its own, and chat suits open-ended questions. Which one is best is still debated, but the job usually makes the answer clear.
Layout | Best for | Typical UI | Risk |
|---|---|---|---|
Copilot | Helping with a task the user is already doing | Side panel or inline suggestions | Clutter if it suggests too often |
Agent | Multi-step work done in the background | Task queue, plan view, action log | Users lose track of what it changed |
Chat | Open questions across lots of data | Conversation panel with sources | Blank-box problem: users don't know what to ask |
Embedded AI | One specific step, like extraction or tagging | A button or auto-filled fields | Low discoverability |
Many good products combine them: embedded AI for the common case, a copilot panel for help, and an agent queue for batch work. If you build chat, give users starter prompts tied to their data so they aren't facing an empty box. For general structure, our web app UI design guide covers navigation and density.
Hypothetical example: an AI dashboard for invoice processing
For example, suppose a finance team uses an AI product that reads supplier invoices and drafts payments.
The main screen is a queue of invoices, each marked ready, needs review or failed. Opening one shows the extracted fields beside the original PDF, with the source region highlighted when you hover a field. Fields the model wasn't sure about, like a smudged due date, carry an amber label and a short reason.
Drafting payments runs as an agent: it shows the planned batch with totals per supplier, waits for approval, then logs each payment with an undo window before the bank file is sent. Nothing irreversible happens without a person confirming.
What empty and error states does an AI dashboard need?
An AI dashboard needs empty and error states that teach users what the AI can do and what to try next. A blank screen with "Ask me anything" is the weakest start. A screen showing three useful actions on the user's own data is the strongest.
- First-run state: sample tasks based on connected data, with a preview of the output.
- No result: say why, such as no matching documents, and suggest a narrower query.
- Model failure: plain language, a retry, and a manual path so work doesn't stop.
- Limits reached: usage or rate limit explained, with what resets when.
- Out of scope: say clearly what the product doesn't do, rather than letting the model guess.
These states are also where trust is won or lost. The same honesty about data and limits should appear on the marketing site's AI trust page, so the product and the promise match.
Why does AI dashboard design need ongoing work?
AI dashboard design needs ongoing work because the product underneath changes faster than any normal software. A new model can change speed, accuracy and failure modes overnight, and the interface has to keep up: new states, new limits, new places where users need to review.
That's why we'd treat AI product UI as a continuous track rather than a one-off project. Watch real sessions, read the action logs, and adjust where users override the AI most often, since that's where the design or the model is failing them. If you're comparing partners for that work, our list of product design agencies for SaaS and AI startups covers the options. And if the dashboard is part of an agent product, see how to design an AI agent website for showing the same behavior to buyers before they sign up.
