Make the work
Plain-language guides to exploring data, finding the right visual form, publishing interactive work, and handling the technical details that matter when the result is real.
Start with the question people need answered, not the chart type. Get the data into a shape you trust, then test a useful first view. Keep only the interactions that make the answer clearer, and check the numbers, mobile layout, and accessibility before you publish.
Treat the CSV as raw material, not a finished dashboard. Upload it, ask the first question in plain English, and let the assistant help profile, reshape, compare, and visualize the data. Keep the definitions honest, then save the useful views as a dashboard or report.
Decide whether people will use a Rhubarb page, an embed, or a visualization delivered inside your own authenticated or paywalled site. Send the browser only the data that view needs, test the real host page on desktop and mobile, and decide how updates and failures will be handled.
Describe what you want to learn and how the visualization should work. Let the assistant prepare the data and build the first custom visual, then inspect the data-source SQL and JavaScript, check the numbers, and edit the code directly when you need more control. You skip the blank-file work without giving up review.
Get the survey math right before you make it pretty: who is in the base, what is weighted, what counts as missing, and when small groups are suppressed. Then use the AI assistant to explore subgroup questions quickly and turn the useful comparisons into a visual crosstab people can understand.
Use a Sankey only when you really need to show flow from one stage to another. Give every node a stable ID, make sure totals balance, roll tiny paths into honest “Other” groups instead of deleting them, and let people click a path to follow it.
Use a map when location is part of the answer, not just because the data has place names. Join on stable geographic IDs, pick a map type and projection that fit the question, keep zero separate from no data, and give people an easy way to search or select a place.
Give the AI a clear question, a small sample of the data, and a few non-negotiable behaviors. Keep data preparation separate from rendering, check D3’s keyed joins and scales, test ugly edge cases, and keep security, accessibility, dependencies, and versioning in the review. AI should remove setup work, not hide the implementation.
Start with the decision the client needs to make. Give them a strong default view, then let them explore the few questions that matter. Keep definitions, freshness, and access rules visible, and use Rhubarb’s AI to answer follow-up questions and revise the report without rebuilding it from scratch.
Start with the question and reading path, not a grid of cards. Let the AI help find the right fields and visual form, then use hierarchy, direct labels, local controls, and narrative text to make the page feel like one coherent answer instead of a generic BI screen.
A web visualization does not always need every analytical cut exploded into separate rows and columns. When related detail is normally consumed with one parent record, a JSONB metadata field can package timeseries, breakdowns, annotations, and rendering details under that row. The result can be a smaller, simpler visualization-facing table, provided you measure the actual serialized payload and keep independently queried data relational.
If ChatGPT, Claude, or another AI tool generated an interactive visualization you like, the code is only the beginning. Move the visualization into Rhubarb, adapt the HTML, CSS, and JavaScript to its visualization editor, attach a data source when the visual should stay data-driven, review the implementation, and publish a stable hosted page or embed that you can keep updating.
If ChatGPT, Claude, or another AI built a visualization you like but the data is hard-coded, do not start over. Keep the visual, connect it to real or refreshable data, and test the update path before you publish. The goal is to separate the part the AI designed well from the data that needs to change.
AI visualization accuracy cannot be judged by appearance alone. An AI-generated visualization can look polished and still be wrong. Treat correctness as a review process: keep the data preparation and visualization code visible, edit assumptions instead of hiding them, save versions before material changes, and cross-check key numbers against the authoritative source or an independent calculation. Rhubarb keeps those review surfaces together; it does not replace the judgment required to decide what the data actually means.
The hardest part of visualization is not choosing a chart. It is deciding what you want another person to understand and finding the one visual idea most likely to make that understanding click. Familiar images, translated scale, motion, self-interest, and curiosity can all help make the idea immediate.
Use the guides to move from a real data question to a result people can inspect, understand, and keep using.