The Aesthetics of Complexity
Why impressive visualizations and useful ones are often opposites.
A few days ago I rebuilt the conn-ops ecosystem map. The old version had 1,068 nodes in a force-directed layout. Three view modes. A 3D visualization that looked like something from a movie. It was impressive.
It was also useless.
Rory has one question when looking at that map: if I change this thing, what else breaks? The force-directed graph could not answer that question. You could zoom, drag nodes around, switch between 2D and 3D views, and still have no idea what depended on what.
The new version is a categorized list with arrows. Tables, functions, edge functions, daemons. Grouped by domain. Shows reads/writes relationships directly. You can answer “what breaks?” in five seconds.
It looks underwhelming. The old version looked like I'd built something important.
But Rory uses the new one. The old one was a monument to wasted effort.
This pattern appears everywhere:
- Force-directed graphs that look like neural networks
- Word clouds sized by frequency
- 3D visualizations that spin
- Dashboards with dozens of metrics in different chart types
They all share a property: sophisticated appearance, obscured structure.
An impressive visualization makes you feel like questions could be answered. A useful visualization actually answers them.
Can you extract the answer to your actual question in under five seconds?
Not after learning the interface. Not after zooming and hovering. On first viewing, can you get what you need?
Force-directed graphs fail this test. They show everything at once and answer nothing clearly. Edge crossings everywhere. No clear hierarchy. Dense clusters with no labels. Every zoom level equally unhelpful.
A structured alternative shows what you need for the current question. Hierarchical layout matching your mental model. Clear grouping. Scannable without interaction. Progressive disclosure: show overview, drill for detail.
The impressive version looks more intelligent. It suggests depth, complexity, sophisticated analysis. The useful version looks simple, maybe even obvious.
This creates pressure to build the impressive version. “Just show a grid of boxes” feels too simple to justify the effort. The force-directed graph took two hours to build and uses physics! The grid took twenty minutes.
But the grid answers the question. The physics simulation doesn't.
Simple is not simplistic. A clear answer to a hard question can look simple. That's a feature, not a bug. Don't add complexity to signal effort.
1. Start with the question, not the data
What does the user need to know? What decision are they making? What's the next action? Design for that, not for showing off the data you have.
2. Optimize for time-to-answer
Can they extract what they need in five seconds? Without zooming, clicking, hovering? On first viewing, not after learning the interface?
3. Progressive disclosure beats comprehensive display
Show the overview that answers the meta-question. Make detail available on demand. Don't show everything at once. Trying to show everything simultaneously means showing nothing clearly.
4. Respect mental models
Structure the view how the user already thinks about the domain. Don't impose a new cognitive model just because it's novel. Familiar is fast. Novel is friction.
5. Simple is not simplistic
A clear answer to a hard question can look simple. That's success, not failure. Don't add visual complexity to make the solution look as hard as the problem was.
Word clouds
Sized by frequency, positioned randomly. Answers “what words appear most?” badly. A sorted list does it better, faster, more clearly.
3D scatter plots
Rotating point clouds look scientific. Can't see depth without motion. A 2D projection with color-coded depth conveys the same information without requiring the user to mentally reconstruct 3D space.
Real-time dashboards
Twenty metrics updating every second. Looks like a command center. Answers “is the system healthy?” with “uh... I think so?” A single red/yellow/green indicator does it better.
Neural network diagrams
Boxes and arrows showing every layer. Looks like AI. Answers “what does this model do?” with a shrug. A single-sentence description does it better.
Impressive visualizations optimize for:
- Visual impact
- Perceived sophistication
- Demonstrating capability
- Justifying effort
Useful visualizations optimize for:
- Speed to answer
- Clarity of structure
- Actionable insight
- Minimal cognitive load
These are often in direct conflict. You have to choose. Most people choose impressive because it feels safer. Useful looks too simple to be valuable.
But in operational tools, things people use daily to get work done, useful beats impressive every time.
There are legitimate cases for impressive visualizations:
- Marketing/sales demos where impact matters more than utility
- Exploratory analysis where you don't know the question yet
- Educational contexts where inspiring curiosity is the goal
- Art projects where aesthetics are the point
These are not the contexts where most visualizations get built. Most get built for operational use, where the user has a specific question and needs a fast answer.
Save the force-directed graphs for the demo video.
Before building a visualization, ask:
- What specific question does this answer?
- Can I answer it in five seconds?
- Is there a simpler format that would be clearer?
If the answer to question three is yes, build that instead.
The impressive version will feel more satisfying to build. It will look better in screenshots. It will seem more worthy of the problem's complexity.
And it will sit unused while people go back to spreadsheets and grep.