Large language models have changed what software is capable of doing. Products can now interpret information, explain patterns, and answer follow-up questions.
But one question kept bothering me:
If AI can explain information instead of simply presenting it, how should it communicate with users?
Why It Matters
Many AI experiences still rely on communication patterns that were designed before software could explain information.
Dashboards, charts, tables, and navigation were built for an era when software's job was to display data and let users interpret it themselves. Today, AI can shoulder part of that cognitive work.
Yet many AI products feel new on the surface while continuing to communicate like traditional software underneath. We're redesigning interfaces without questioning the assumptions they were built on.
The challenge is no longer helping users find information.
It's helping them understand it.
Observation
I noticed this while working on a project for an AI-powered personal finance assistant.
My first instinct was familiar. I started sketching dashboards, spending charts, category breakdowns, and transaction lists — the same patterns that have defined personal finance products for years.
But as I explored different directions, something felt off.
If the AI already understood a user's spending habits, why should users still have to interpret the data before understanding what mattered?
I realized the design challenge wasn't designing an interface.
It was designing a communication strategy — deciding what the AI should communicate, when it should communicate it, and how each piece of information should be delivered.
Experiment
Rather than asking, "What should this screen look like?", I reframed the project around a different question:
How many different ways can the same financial information be communicated?
My first attempt pushed language as far as it could go. I wrote the AI's response as one continuous explanation — total spend, the category that moved, the merchants behind it, all folded into a few sentences. It read naturally, but it broke down the moment there was more than one thing worth comparing. Language is efficient at establishing a single point of understanding. It's much weaker at holding several data points in relation to each other at once.
So I tried the opposite: lead with the chart, use language only as a caption underneath it. This made the problem worse, not better. The user now had to parse the visual before the sentence could tell them what it meant — the AI's understanding of the data wasn't doing any work until after the interpretation had already happened.
Neither extreme worked, for the same reason: I was treating language and visualization as competing approaches instead of asking what each was actually for.
What Changed My Mind
I began the project thinking AI primarily changed the interface.
As I iterated, I realized it changes something more fundamental: the order in which information should be communicated.
That shift changed how I saw visualizations.
I'd initially treated charts as the primary way to deliver insight, but they gradually became supporting elements — language did the work of building context first; visuals earned their place only when they lightened the cognitive load or invited someone to dig deeper.
Instead of asking, "Which chart should I use?", I started asking:
Does this visualization tell someone something language hasn't already told them?
That turned out to be a much better design question.
Distilled Principles
1
Design AI as a communication system, not just an interface.
2
AI changes the order information should be communicated in, not just the medium.
3
Language should build understanding before visuals invite exploration.
4
Every element should either reduce interpretation or enable meaningful exploration.
What's Still Uncertain
I also haven't explored where the balance shifts.
At what point does explanation become unnecessary and exploration become the faster path?
Understanding that transition feels like the next question worth exploring.