Building an Interactive Data Visualisation in a Single Conversation

I have been an Indiana Pacers fan for most of my life. One of the less enjoyable aspects of following the Pacers is watching them consistently miss out on top draft picks while other franchises seem to land generational talents year after year. I wanted to quantify this properly: which franchises had actually held the most top-five picks since 1996, and where did the Pacers land? The result is this interactive visualisation, and it confirmed my suspicions in the most deflating way possible. It also took about an hour of conversation with Claude to build.

What a Claude Artifact Is

Claude can produce runnable code directly inside its chat interface, rendered as a live preview. These are called artifacts. A single HTML file with embedded CSS and JavaScript is the most capable format: it can include charts, interactivity, filters, animations, and anything else a modern browser can run. The output is a shareable public URL with no hosting required on your end. There is no deployment step, no repository, no build process. The artifact just exists at a URL.

This makes artifacts a good fit for self-contained data visualisations. The data lives inside the file. The rendering logic lives inside the file. You share a link and the other person sees exactly what you see.

Starting the Conversation

The first prompt was fairly direct: build an interactive HTML visualisation showing the top-5 draft picks for every NBA franchise from 1996 to 2025, with the ability to filter by team. Claude's first attempt had the right structure but the data was incomplete and the layout was hard to read at a glance. Rather than starting over, I described what wasn't working: the pick numbers needed to be more prominent, the team filtering needed to be faster, and a few of the historical picks were wrong.

This is the part that matters most with artifact-style development. You are not writing a specification upfront. You are reacting to what you see and describing the gap between that and what you want. Claude is good at targeted revisions, which means you can treat each response as a working draft rather than a final product.

Three Versions to Get There

The file is named nba_draft_picks_v3.html, which is a reasonably honest record of the process. Version one established the data structure and basic layout. Version two fixed the filtering and corrected several data errors I spotted by scrolling through teams I knew well. Version three refined the visual design: tightening the spacing, making the pick slots visually distinct by draft position, and adding a colour scheme that read clearly without being garish.

Three rounds is a fairly typical arc for this kind of project. The first pass does the heavy lifting of getting everything into place. The second pass fixes the things that become obvious once you can actually interact with it. The third pass is taste: the difference between something that works and something you'd share.

What Made It Work

A few things made this easier than it might sound. The subject matter is well-documented, so Claude had accurate underlying data for most of the draft history without needing an external API. HTML artifacts are a complete execution environment, which means there were no dependency issues or environment mismatches to debug. And the feedback loop is fast: Claude generates a new version, you see it rendered in the same window, you respond. There is no context-switching between a code editor and a browser.

The constraint is also the point. An artifact only works for something that fits in a single self-contained file. That rules out most production software but covers a wide range of exploratory data work, internal tools, and one-off visualisations. For those use cases it is a genuinely fast path from a question to an answer you can look at and share. As for the Pacers: zero top-five picks in thirty years. Confirmed.