Skip to main content

Send feedback

Tell us what works and what could be better. We read every submission.

Send feedback

Tell us what works and what could be better. We read every submission.

← Explore audiences

Data journalism and newsroom graphics teams

Turn a year of storm reports into a data story

Prototype a visual narrative from NOAA public records, with interactive state comparisons, annotated timelines, and editorial review.

See an example project → · Evaluating for your team? Discuss a scoped pilot

Want a custom visualization delivered by a specialist instead? Explore professional visualization services.

Dataset-backed demo concept

A Year of Extreme Weather

A graphics reporter turns NOAA's 2024 storm reports into a mobile-friendly story about event types, reported impact, and regional patterns, verifying every editorial claim before publication. This illustrative project is not a client commission or an endorsement by any data provider.

Curated source data

NOAA Storm Events 2024 reports: event dates, state, hazard type, injuries, fatalities, and reported property/crop damage.

Example instruction

“Build a state-level interactive summary with monthly event timeline and ranked hazard types. Add filters and sourced annotations, describe damage as reported estimates, and avoid claiming long-term climate trends from a single year.”

Target deliverable

An annotated, mobile-first 2024 storm-report story prototype

Interactions to test

  • Select a state to update the timeline and summary
  • Filter by event type and reported impacts
  • Explore annotated peaks and source notes
Browse published visualizations

Gallery projects are community examples, not implementations of this brief.

Where the workflow helps

Deadlines limit exploration

Graphics teams need to choose which stories justify custom development.

Test different visual story structures quickly

Templates cannot tell every story

Original reporting may require unusual comparisons, annotations, or narrative interactions.

Review live interactions rather than static mockups

Publication standards are strict

Accuracy, mobile responsiveness, accessibility, and CMS integration remain essential.

Preserve source-code inspection and editorial approval

Prototype with AI. Approve with your team.

  1. 1. Bring data and a brief. Give VizHub the dataset and the question you want to explore.
  2. 2. Try working directions. Explore alternate live interactions instead of relying only on mockups.
  3. 3. Review and publish. Inspect code and revisions, verify the result, then export or share it.
Watch the general product walkthrough

What to verify in a pilot

  • Cross-check counts, sums, dates, damages, and annotations
  • Do not invent event geocoordinates or infer long-term climate trends
  • Test mobile layout, attribution, and accessible interactions

AI-generated code and analysis require human verification before production use.

Try this on a real project

Start with non-sensitive data and evaluate the complete workflow. Teams can also discuss a scoped 90-day design partnership.

Help us understand data journalism and newsroom graphics teams

We are testing assumptions about this workflow with practitioners. The answers below are working hypotheses, not actual interviews, testimonials, or endorsements. Expand a question group if you would like to contribute.

Questions specific to your team (8 questions)

How many original graphics ship during an ordinary week?

Working hypothesis: The mix of quick graphics and longer custom investigations varies with the news cycle.

What happened on the last breaking-news visualization?

Working hypothesis: Data verification and editorial review competed with coding time inside a compressed publication deadline.

When is custom interactivity worth building?

Working hypothesis: Stories that benefit from reader exploration or a novel visual explanation may justify work beyond standard chart templates.

What limits graphics throughput?

Working hypothesis: A mix of data availability, reporting quality, limited engineering capacity, and review bottlenecks constrains output.

Where do reusable newsroom templates fall short?

Working hypothesis: Unusual storytelling structures and multi-view interactions may resist standard templates.

What publishing requirements cannot be compromised?

Working hypothesis: Mobile rendering, accessibility, load time, editorial accuracy, updateability, and CMS compatibility are fundamental.

Who approves newsroom visualization tooling?

Working hypothesis: Graphics leads can champion a tool, but newsroom, product, or engineering leadership may control purchases.

Which recent idea was simplified for lack of time?

Working hypothesis: A compelling custom interactive concept may have been reduced to static charts for a timely story.

Workflow, volume, pain, and budgets (10 questions)

How does a dataset become a published visualization?

Working hypothesis: The work typically spans data preparation, choosing an approach, implementation, review, and publication. The handoffs, rather than chart rendering alone, may create delays.

How many charts do teams make per week or month?

Working hypothesis: Volume varies widely. Total chart count may be a poor proxy for need: one bespoke interactive can require more effort than dozens of standard charts.

How many are standard versus custom or interactive?

Working hypothesis: Most routine graphics may be handled by established tools; custom interactions and unique layouts are a smaller but disproportionately costly category.

What tools are used today?

Working hypothesis: Excel, R, Python, Datawrapper, Flourish, D3, and AI coding tools may cover different stages. VizHub must complement rather than replace these workflows.

Where does most of the time go?

Working hypothesis: Data cleaning, story selection, implementation, stakeholder review, and publishing may each dominate depending on project type.

What was the last difficult visualization?

Working hypothesis: The most revealing example may involve linked views, nonstandard interaction, complex data, or repeated changes to a bespoke design.

Which ideas were abandoned because of cost or time?

Working hypothesis: Teams may choose a static or templated chart rather than develop an ambitious interactive tool, even when the latter could improve understanding.

What determines using a template versus building custom?

Working hypothesis: Budget, deadline, editorial goals, interactivity, accessibility, and the available developer capacity likely influence the decision.

Who requests the work, who produces it, and who approves spending?

Working hypothesis: End users, technical evaluators, and budget owners may be different people. A paid pilot needs an identified champion and sponsor.

How is visualization work funded?

Working hypothesis: The relevant baseline may be internal salary time, external development fees, project grants, or publishing budgets rather than software subscriptions alone.

Product fit, trust, purchasing, and pilot validation (9 questions)

Where would a dataset-to-prototype workflow fit?

Working hypothesis: Early exploration and custom interactive prototyping are the likeliest entry points; replacing established production systems is a higher bar.

Which capability would matter most?

Working hypothesis: Multiple genuinely different working concepts, reviewable source code, and the ability to iterate may matter more than generating a single chart.

What must be true to trust the output?

Working hypothesis: Teams will need reproducible transformations, correct calculations, accessible interactions, readable code, and human approval before publishing.

What would make adopting a new tool worthwhile?

Working hypothesis: Measured reductions in effort to a production-acceptable deliverable, not merely time to a visually appealing first draft.

What would prevent adoption?

Working hypothesis: Poor code maintainability, inaccurate analysis, workflow incompatibility, data-security requirements, and unclear costs could all stop adoption.

What real dataset could be used for a pilot?

Working hypothesis: An existing public dataset and comparable published result offer a credible, low-risk evaluation.

What would justify paying for this?

Working hypothesis: Recovered developer capacity, faster client delivery, new publishable experiences, or increased research output would need to be demonstrable.

Who can authorize a pilot?

Working hypothesis: A user may champion the tool while a team lead, department owner, or procurement process controls the purchase.

Would a $2,000, 90-day design partnership make sense?

Working hypothesis: A paid pilot could be attractive after a technical evaluation, provided the scope, support, deliverable, and success criteria are explicit.

Are these assumptions wrong or incomplete? Tell us how your team actually works.