To build a better SaaS dashboard with an AI coding agent, brief it on the decision the dashboard supports, not the widgets it should contain. Name the one question the page must answer, the data behind it, how dense it should be and every state it needs. Without that, most agents produce the same thing: four stat cards, a line chart and a table, all given equal weight.
Common problems with generated dashboards
- No hierarchy. Every metric gets a card of the same size, so nothing is clearly most important.
- Decorative charts. A chart appears because dashboards have charts, not because the trend matters.
- Weak tables. Left-aligned numbers, no tabular figures, tall rows and no sorting or overflow behaviour.
- Happy-path data. Perfect sample numbers, with no empty, loading, partial or error states.
- Invented metrics. Plausible-looking figures with no defined source or calculation.
- Desktop only. Tables and filter bars that break at narrower widths. See making AI-generated UI responsive.
Start with the question
Every useful dashboard answers a small number of questions for a specific person. Write them down before you prompt:
Build the usage dashboard at app/(app)/usage.
Who: workspace owners on a usage-based plan, checking weekly.
Primary question: "Will we go over our plan this month?"
Secondary: "Which projects are driving usage?"
Data (from lib/usage.ts, don't invent fields):
- monthToDate, planLimit, projectedMonthEnd
- byProject: { name, usage, changeVsLastMonth }[]
- daily: { date, usage }[]Naming the data source matters. It keeps the agent from inventing metrics, and it makes the dashboard honest about what it can show.
Hierarchy: answer the question first
Put the answer to the primary question at the top in plain language, with the number that supports it. Supporting metrics can be smaller and inline rather than each getting a card.
Top of page: one sentence answering the primary question, e.g.
"On track to use 82% of your plan", with projectedMonthEnd and
planLimit beneath it. No stat cards. Use a single progress bar
for monthToDate against planLimit.Tables: where dashboards are won or lost
Most dashboard work happens in tables. Give the agent explicit rules:
- Right-align numbers and use tabular figures so digits line up.
- Pick a row height for the density you want (for example 40px) and keep it consistent.
- Mute secondary columns; keep the primary column at full contrast.
- Define sorting, truncation and what happens with long names.
- Decide whether the table paginates, virtualises or loads more, and test it with hundreds of rows.
Filters
Generated filter bars often expose every possible filter at once. Ask for the two or three filters people actually use, with the rest behind a “More filters” control. Once filters are applied, show them as a summary that can be cleared in one action, and make the result count visible.
Charts: only when the shape matters
Use a chart when the trend or comparison is the point. A single current value is clearer as a number. When you do use one, specify it:
- Chart type that fits the data: lines for change over time, bars for comparing categories.
- One highlighted series in the accent colour; others muted.
- Labelled axes and units, and a sensible y-axis baseline.
- An accessible fallback: a data table or text summary.
Density and readability
Dashboards people use daily should be denser than marketing pages, but density isn’t cramming. Reduce chrome (borders, shadows, card backgrounds) before you reduce type size or spacing. Hairline dividers and consistent alignment can carry a dense layout that boxes would make noisy.
States
Ask for each one by name and review them all:
- New account: no data yet, with what will appear and how to get there.
- Loading: skeletons that match the final layout.
- Partial: some data, such as the first few days of the month.
- Error: what failed and how to retry.
- Extreme values: zero usage, usage far over the limit, very long project names.
Review it like a dashboard user
Open it with realistic data and give yourself five seconds. Can you answer the primary question? Then use the full checklist in how to improve AI-generated UI, and check your components against the system with the design system guide. The overall flow from brief to review is in the design engineering workflow.
Give the agent better dashboard references
The fastest route to a better dashboard is a few strong references with notes on what each one does well: how one handles dense tables, how another summarises applied filters. Explaining that in every prompt gets repetitive, and it’s part of why generated dashboards look alike.
With Attuna, those references and notes live in your library, and a Taste Profile can be set up for specific contexts such as dashboards. Your agent asks for direction for “a usage dashboard” and gets the principles and references that apply.