For a long time, large language models were good at one thing: generating text. They could summarize documents, draft emails, and answer questions, but anything involving structure—especially visual structure—felt unreliable. Diagrams, flows, and infographics were either hand-waved or delegated to design tools and humans.
That boundary is starting to move.
Today’s models can reason about steps, hierarchy, and flow well enough to generate reliable visual artifacts—not just descriptions of visuals, but structured outputs like diagrams, layouts, and maps. This shift introduces a new product craft I’ll call Visualization Engineering.
From images to structure
When people hear “AI-generated visuals,” they often think of images: screenshots, illustrations, or stylized graphics. Those are impressive, but they’re not trustworthy in a product sense. They’re probabilistic, hard to test, and difficult to make consistent.
Visualization engineering is not about generating images.
It’s about generating structure.
Instead of asking a model to “draw something,” you constrain it to produce a deterministic representation—SVG, layout rules, ordered steps, explicit groupings. The model reasons about the structure first, then renders the visual within those constraints.
Same input. Same structure. Predictable output.
That distinction—between images and structured visuals—is what makes this usable in real products.
Why this matters for product managers
As LLMs start producing artifacts, not just text, product managers inherit a new responsibility.
PMs are no longer only defining features and flows. They are defining:
What counts as a valid visual output
How structure should be inferred from messy input
What “correct” looks like when the output is a diagram, not a sentence
This is similar to the shift many PMs went through with context engineering. Once models became sensitive to context, PMs had to learn how to shape it, constrain it, and test it. Visualization engineering is the same move—applied to visual outputs.
If a model generates a diagram, the PM owns:
The input format
The structural rules
The failure cases
The tests for consistency and reliability
This is no longer a purely design concern, and it’s not something you can leave entirely to the model.
A concrete example: journey maps
Journey maps are a useful way to make this concrete.
Every product team understands journey maps. They’re meant to show what a user is trying to do, what happens step by step, and where friction or opportunity appears. In practice, the inputs are often messy: notes, narratives, partial descriptions, and conversations.
Traditionally, turning that into a journey map required manual synthesis and design work.
With visualization engineering, the workflow changes:
The model interprets unstructured language
Infers steps and sequence
Applies a consistent visual structure
Produces a deterministic output
Journey maps are just one example, but they’re a good one: familiar, structured, and easy to reason about. More importantly, they demonstrate the core idea—engineering the transformation from intent to visual form.
This isn’t new—but it matters now
Visualization itself is not new. Engineers and designers have been doing programmatic visualization for years using charts, diagrams, and layout systems.
What’s new is that language models now sit between human intent and visual structure.
That means someone has to design how interpretation happens.
Someone has to define the constraints.
Someone has to make the output reliable.
LLMs didn’t invent visualization engineering. They made it unavoidable.
The broader implication
Journey maps won’t be the only artifact affected by this shift. The same principles apply to:
Diagrams
Process flows
Architecture sketches
Research synthesis visuals
Planning and execution boards
As more product surfaces become AI-generated, visualization engineering becomes a core part of product craft.
Not prompting for pictures.
Not chasing aesthetics.
Engineering structure so visuals can be trusted.
