Why is "overstuffing" a particularly common mistake specifically when AI generates dashboards, compared to generating a regular screen?
A regular screen (a login page, say) usually has a clear, limited set of elements, so the model finds it relatively easy to judge what belongs there and what doesn't. But a dashboard is fundamentally about presenting data, and a dataset often has dozens of fields and dozens of possible ways to slice it — every field could theoretically become a chart, and without being told which fields actually matter for this specific use case, the model tends to plot everything it can, because leaving out a potentially useful field feels riskier than adding one unnecessary chart.
The mechanism behind this: when the model is uncertain what the user actually wants to see, it defaults to the highest-information output rather than the most precisely targeted one, because the former looks more "complete" on the surface and is less likely to be criticized for missing something. This is also why explicitly telling the model "show at most this many charts, these are the core metrics" works much better than just saying "make me a dashboard" — you're effectively doing the prioritization judgment for the model that it won't proactively make on its own.
Why do both "too many charts" and "missing comparison baseline" require explicit prompting, rather than something the model can figure out on its own?
Because what these two problems have in common is that the correct answer depends on the use context, not on what the data itself looks like. The same revenue data shown to a CEO versus a financial analyst calls for a completely different number of charts and a different answer on whether to include a month-by-month breakdown — but the model, looking only at the data itself, has no way to infer who this is for. Similarly, whether "$1.2M revenue" needs a comparison baseline depends on whether this dashboard's purpose is "a quick glance to confirm everything's fine" or "a deep dive into trend analysis" — another question the data alone can't answer.
This means the problem isn't a capability gap in the model — it's missing critical contextual information. The fix, accordingly, isn't a stronger model — it's spelling out that context clearly: who this dashboard is for, whether the purpose is a quick scan or a deep dive, which specific metrics are core. Only the user knows this information; the model has no way to guess it out of thin air.
How serious is this data Hallucination problem in practice, and how does it specifically happen?
Data hallucination refers to the model, while generating a dashboard, inventing fields, relationships, or calculations that look plausible but don't actually exist in the data. For example, if the data only has an "order date" and "order amount" field, but the model generates a "customer lifetime value" chart — that's a metric that sounds reasonable and is common in dashboards, but if the underlying data has no customer ID or repeat purchase records, the numbers on that chart were likely derived or even fabricated by the model rather than genuinely calculated from the data.
This problem is especially dangerous precisely because it doesn't make the dashboard look "broken" — it makes it look more complete and more professional. It's exactly that surface-level completeness that makes people more likely to let their guard down and trust the numbers. In practice, it's worth spot-checking at least a portion of the generated numbers by hand — pulling out a calculator or spreadsheet to confirm that each chart genuinely traces back to a field you actually provided, rather than something the model filled in on its own. If a dashboard is going to inform an important decision, this verification step shouldn't be skipped.
If I don't have a data analytics background, which of these five prompt fixes is most worth prioritizing?
If you can only pick up one first, prioritize the traceability fix from mistake five (requiring the model to account for each number's data source). The reason is that this fix's benefit isn't limited to solving one specific problem — it also tends to surface the other four problems along the way. If you require the model to account for each chart's data source, a dashboard overstuffed with unnecessary charts will naturally take more effort to justify, exposing that "this chart doesn't actually matter." A number missing a comparison baseline will also more easily reveal, when asked to account for its source, that "this number is missing a point of comparison."
In other words, the habit of "demanding traceability" tends to force the model to trim its own content, because things that can't clearly account for their source are usually things that shouldn't have been included in the first place. This is an easier habit to build than trying to memorize five separate rules up front, and it transfers more readily to other AI content generation contexts too, not just dashboards.
Hand a dataset to an AI design tool and ask it to generate a dashboard, and the most common result is: the screen fills up with charts, but you can't tell which number actually matters. This isn't the tool being bad at its job — it's that a language model, faced with an open-ended instruction like "make me a dashboard," tends to plot everything it can, because it was never told which details are secondary and which one is the actual thing to look at. Left without that guidance, the model defaults to the safest option: show everything. This piece lays out five specific, common mistakes and the prompt-level fix for each one, rather than redesigning the whole workflow.
The model tries to plot every dimension it can find in the data, and the result is a dozen-plus charts crammed onto one screen with no indication of which to look at first. The fix is to set an explicit cap on chart count in the prompt and require the model to decide upfront which are core metrics and which are secondary details, deferring the details to a second-level view. For example: "Show at most 5 charts. First list the core metrics being tracked this time; move everything else into an expandable detail view rather than the first screen."
Without an explicit instruction, the model's default tendency is to jump straight to full charts rather than giving a few numbers that are legible at a glance. The fix is to explicitly require a row of KPI cards up front, with trend indicators specified: "Display 3 to 5 KPI cards at the top, each showing the current value and a direction of change relative to the previous period. Put charts below the KPI cards."
The model sometimes picks a visually flashy chart type that doesn't actually fit the data — forcing a dataset with only three or four categories into a pie chart, or plotting a time trend as a bar chart instead of a line chart. The fix is to specify chart types tied to data shape directly in the prompt: "Use bar charts for category comparisons, line charts for time trends. Only use pie or donut charts when the data breaks into 3 to 5 parts of a whole — switch to a bar chart for anything above 5 parts."
A number on its own — "$1.2M revenue this month" — has no meaning by itself; the reader has no way to tell if that's an improvement or a decline. Left unprompted, the model tends to only show a snapshot at a single point in time. The fix is to explicitly require every metric to come with a comparison baseline: "Every metric must show both a period-over-period comparison (vs. last period) and a year-over-year comparison (vs. the same period last year). Never present a number without a baseline to compare it against."
This is the one that needs the most caution — the model sometimes "invents" fields or data relationships that look plausible but don't actually exist, making the dashboard look complete while the underlying data doesn't actually line up. The fix is to require the model to use only explicitly provided fields, and to proactively demand it account for each chart's data source after generation: "Only use the fields I've provided — don't add or infer any new fields. Below each chart, label exactly which field this number was calculated from. If a data point can't be derived from what I've given you, say explicitly what's missing rather than filling it in with a plausible guess."
If you're using a tool like Claude Design to quickly generate internal-use dashboards, you don't need to apply all five fixes at once — start with whichever problem you're actually hitting. If your generated screens keep coming out overstuffed with charts, apply the fixes for mistake one and two first. If this dashboard is going into a decision-making presentation, the traceability fix for mistake five should be the highest priority, because a dashboard that looks complete but has hallucinated data underneath is more dangerous than one that's obviously incomplete — at least the latter tells you not to trust it, while the former quietly convinces people they can.