Over the past couple of weeks, I’ve run an experiment testing Claude’s ability to recreate Tableau dashboards using the standard Superstore sample dataset. Given the vast potential of AI-tools for data visualization, I wanted to see how effective Claude is at handing this task right now.
In my experiment, I gave Claude screenshots of two dashboards (here and here) that I found on Tableau Public and thought were well designed and easy to use. These dashboards are good examples of how to make the large Superstore data set navigable for users, so I wanted to see if Claude could recreate them quickly and efficiently. I fed Claude the raw Excel file of the underlying data and asked it to build an interactive, filterable, standalone dashboard like the originals. I limited my work with Claude to no more than an hour, so there are still some bugs and tweaks that I’d want to make before “publishing.”
On the surface, the results were genuinely impressive, but after a deeper look, a bit less so. This post is kind of a “field report” on both halves of that experiment: how fast the dashboard recreations came together and the data issues (relatively minor, but still) that were completely invisible once the polish was applied. (You can check out all dashboards by using the links in the image captions below.)
The Reward: It’s Fast
Overall, Claude created the two dashboards quickly and without too much instruction. Iterating was basic and straightforward: “make the map bigger,” “fix the KPI card heights,” “make the line charts interactive,” etc. There was no manual chart-by-chart building here. Claude produced a full HTML/JavaScript version matching the layout: KPI cards with sparklines, a gauge chart, a US choropleth map and a hex grid map, ranked bar lists, and hover tooltips, all wired to the original Superstore dataset.
In terms of speed when using it, the Claude versions are faster than Tableau—no spinning while the filters get applied. In terms of responsiveness, the first Claude dashboard looks good on all screen sizes, while the second dashboard has some overlapping wonkiness towards the bottom and doesn’t size very well between desktop and mobile. Additionally, the second dashboard took several iterations to get Claude to arrange the hex grid map correctly, and even now the projection looks strange.
I’ve written previously about my doubts around dashboards, but if your goal is to get something working quickly, especially for internal use, Claude offers a different speed of iteration than building the same thing in Tableau. However—and this is a huge caveat—I came to the experiment with a clean dataset and a preset dashboard ready to replicate. There wasn’t much creativity or original data analysis needed. So, this experiment was more to see what AI can do with pre-existing content, not how to create a new dashboard.
The Risks: Data Issues You Can’t See From the Outside
Despite the speed gains Claude offered, the final products included issues that someone skimming the finished dashboard would likely not catch because nothing looks wrong on the surface. Upon review, I found a handful of data and layout problems that were masked by the dashboard’s polish.
1. Incorrectly labeled data
The first dashboard’s headline “Sales” value summed every country in the dataset (the US and Canada); whereas the state map directly beneath it, on the same screen, silently filtered to US states only. It’s not entirely clear to me whether this is also a problem with the original dashboard or not. There is no note in either dashboard that the aggregate numbers are US only, so in some ways it’s understandable that Claude would use the entire dataset.
Ultimately, nothing in the user interface signaled what the number included, so the dashboard looked internally consistent because it did not visibly contradict itself. Only when I fact-checked the numbers did I find the inconsistency ($733.3K for US-only versus $745.6K for US plus Canada; you can grab my Stata code here, if you’re interested.)
When you build a dashboard manually, you (hopefully) make conscious decisions about the data source, the sample selection, and the filters. With Claude, however, the filter decision was buried in the middle of a data-processing script. This issue wouldn’t be a problem if I wrote the script myself, but with Claude, I didn’t have that level of hands-on quality assurance.
2. Compounding rounding decisions led to incorrect data
The recreated dashboards displayed two distinct rounding bugs, both of which traced back to a number rounding more than once before reaching the screen.
The first was in a sub-category growth-rate calculation. The Claude pipeline has two steps: a Python script computed each sub-category’s year-over-year growth and rounded it to one decimal place. For example, 33.456741% became 33.5%. Then, separately, the front-end JavaScript rounded the already-rounded number again, to 34%, for display.
Individually, each rounding step was correct. But stacked together, they produced the wrong answer: 33.456741 rounded directly to the nearest whole number is 33 but the dashboard displayed “+34%.” That’s a real, if small, factual error. While it only happens when the true value sits just below a rounding boundary, that low incidence means it isn’t consistent or predictable from the outside. Some sub-categories in the same table were fine, but the aggregate number wasn’t.
The second rounding bug was structural rather than a one-off. To keep the second dashboard’s embedded dataset compact, every individual sales amount was rounded to the nearest whole dollar. The dashboard then summed those already-rounded values live in the browser. Each individual rounding error is tiny (at most $0.50), but when summed across roughly 3,300 transactions, the errors didn’t cancel out.
In total, these rounding errors compounded to a value about $65 higher than the exact sum in the data and shown in the original Tableau dashboards. While that equals a small percentage error, it’s still incorrect. The size of the drift depends entirely on how many rows happen to round up versus down, so in a different dataset or different year, this is the kind of error that could end up being much larger.
Neither bug involved incorrect arithmetic at any single step. The problem was architectural: rounding happened in more than one place along the pipeline, and the polished, final dashboard gives you no visual cue that this happened. In the future, I could probably specify a rule about rounding that would address this issue.
3. The hex map: A reminder that pictures aren’t data
The first attempt at the hex grid map in the second dashboard started from a screenshot of the full dashboard. Claude made an effort, but the image probably wasn’t large enough for Claude to read all the two-letter state abbreviations. As a result, the first grid map nudged several states into wrong positions and some hexagons overlapped.
Early Version of the Recreated Dashboard Had Layout Issues
I iterated a few times with hex grid map screenshots from other projects, but Claude still couldn’t generate the correct map. What fixed the problem was giving Claude an actual GeoJSON file containing the exact hexagon coordinates for every state. Once the layout existed as structured data rather than as pixels to be visually interpreted, the map looked mostly correct, though still a little off.
The general lesson for anyone doing similar work: if precise layout matters, hand the tool the underlying data, not a picture of the result you want. Screenshots are great for communicating a broad look and feel, but they are a poor substitute for exact specifications.
4. The second dashboard’s layout still isn’t quite right
Even after several rounds of fixes, the Executive Performance Overview dashboard’s layout isn’t fully solved. At certain browser widths, chart panels crowd or partially overlap, and getting genuinely responsive behavior took multiple explicit rounds of prompting “here’s what’s broken.” I’d stop short of calling it fully solved even now.
However, Tableau (at least as I understand it) is a fixed canvas by default, meaning it doesn’t reflow for different screen sizes at all without deliberate design work on the author’s part. What Claude built is more flexible out of the box because it does reflow, wrap, and adapt to some degree without being asked. But “more responsive than a tool that isn’t responsive at all” is a low bar to clear, and this experiment was not a “hand it a screenshot, get pixel-perfect adaptive layout for free” experience. It took iteration, testing at multiple screen widths, and fixing CSS bugs that wouldn’t have been obvious without specific checks.
Takeaways
At the end of the day, this experiment demonstrated a few lessons to me—some of which are likely to make a few of you mad while validating others:
- Speed is real. Draft, even polished, interactive dashboards came together in minutes of conversation of Claude when they would have taken hours—at least for me—to build by hand in Tableau. Further, iteration after the first draft was cheap, with the caveat that I already had a layout to mimic. If you have a template of grid layouts to replicate, that may be sufficient for most standard dashboarding projects.
- “Looks finished” and “is correct” are different. A slick, well-formatted dashboard is not itself evidence of accuracy. Scope decisions (which rows count toward a total) and rounding decisions (how many times a number gets touched before it’s displayed) are easy to get wrong and functionally invisible in the finished output.
- Verify independently, not by re-reading the same code. The scope mismatch and both rounding bugs only appeared once I fact-checked the results.
- Give spatial/layout tasks real data, not screenshots. The hex map went from approximately-right to exactly-right the moment it had coordinates to work with instead of pixels to interpret.
- Treat AI-built dashboards as a draft. Claude offered a fast, often very good, and genuinely useful result as a starting point. But it required an independent fact check before it could responsibly be presented to anyone making a decision with it.
