Our panel on data visualization in the age of AI

Paolo Ciuccarelli wrote up a great synthesis of our panel at Northeastern’s Design Research Week on “Data Visualization in the Age of AI.”

One thread I keep coming back to: the engineering of constraints around AI-native tools.

There’s broad consensus that AI collapses implementation time. I built dtour (https://dtour.dev) in two days as a working prototype, which would have taken me weeks/months before. But the harder, more interesting question is: what makes the output good rather than generic?

I believe it’s about shaping the solution space. The goal of a visualization tool is to help people gain insights fast. Classic tools often have a deep learning curve before that insight rate goes up (if at all). AI-native tools can lower that curve and offer deeper insights, but only if the tool’s solution space is well-constrained to guide AI. Without constraints, you just get mediocre results faster.

Constraints aren’t just guardrails, they’re architecture. It’s like mentoring an intern. You don’t let them explore aimlessly, but you also don’t dictate every step. You define the problem boundary, set the right level of structure, and let productive exploration happen within it. Over-constrain and the work is predictable. Under-constrain and it’s inefficient. The same holds for AI agents generating data visualizations.

Jeff Heer, Ellie Fields, Andy Caley, and I are trying to put this into practice at Ridge AI: well-scoped declarative specs, automatic interactions, and hard constraints where they matter (like using SQL instead of Python for analytics) to produce useful and trustworthy analytical dashboards as fast as possible. So users can focus on what matters: answering data questions.

The question of what’s the right level of guidance extends to the human in the loop as well. If the tool suggestions are too precise or elaborate, people might rubber-stamp and stop thinking. Too little, and AI feels unproductive. You need the right amount of friction, as Angie Boggust pointed out. I’m curious how other folks approach this balance in their work.