This article was written by Tina Poethe, Product Designer at SPREAD AI.
By now, almost every engineering tool has an AI chat box bolted onto it. You type a question, you get an answer. The old worry that conversational AI would make dashboards and visual tools obsolete has mostly resolved itself: the two are converging, and most platforms now offer both.
So the interesting question isn't chat or visuals anymore. It's a quieter one: there's a whole class of engineering work that no chat box can do, however capable the AI model gets. At its heart is a tension between two fundamentally different ways of working with complex data. Sometimes you know exactly what you're looking for and only need to ask for it. Other times you don't yet have the question. You have to explore until something surfaces that you didn't know to look for. Tools that blur those two modes will quietly fail, no matter how good the data underneath them is.
When you already know what you're looking for
When an engineer needs a specific answer from a complex system like "which components are affected by this error across all variants?" or "show me all open tickets related to this ECU", a language interface can be remarkably efficient. You don't need to know which menu to open, which filter to set, which screen to navigate to. You describe what you need and the system figures out the steps. The cost of navigating a complex UI becomes higher than the cost of simply describing the outcome, and people naturally default to text.
This isn't returning to the old command line, where exact syntax was required. It's something new: a surface of control where language itself becomes the interface. And for well-defined queries, it's faster and more accessible than anything a traditional GUI can offer, even to non-technical users.
Engineering problems aren't only queries
Here's where it gets interesting. Errors in complex systems, like a vehicle's electrical architecture, don't happen all at once. They cascade. A sensor stops responding, which corrupts a signal, which triggers an error bit in another device, which produces a diagnostic trouble code somewhere else entirely. It's a domino effect that unfolds over time, and understanding what actually happened means being able to see that sequence, not just a summary of it.
Ask the right question and a model can describe a cascade, even chart it. But you have to know to ask, and no prompt surfaces the chain reaction you didn't anticipate. That's something you need to watch unfolding, tracing the behavior across components and time. An engineer who can see the measurement data for a specific vehicle and a specific case can follow the signals, spot where the chain reaction started, and verify it against what they know about the system. That's doing something fundamentally different from asking a question. They're exploring. They're building an understanding that no single query could have produced.
This is the distinction that matters: language interfaces are excellent for specification, when you know what you're looking for and can describe it. Visual interfaces are essential for exploration, when you need to discover something you didn't know to ask about. These aren't competing approaches. They're different cognitive modes, and the most valuable insights in engineering often come from the second one.
Why exploration keeps getting deprioritized
There's an old observation in media theory that the most effective media are the ones you stop noticing. When a visual interface works well, the engineer finds what they need, forms a judgment, and moves on. The interface disappears. The success is silent. Nobody writes a report saying "the tool was so clear I trusted the data immediately."
This creates a structural problem. The better an interface works, the less visible the effort behind it becomes. Data infrastructure is tangible: you can count connections, measure speed, demonstrate coverage. AI capabilities are demonstrable: you can show a suggestion, a generated summary, an automated analysis. But the work that makes complex information navigable, that lets someone trace a cascade of events across a system and arrive at a confident judgment? That only becomes visible when it's missing, when an engineer looks at a screen full of raw identifiers and picks up the phone to call the colleague who just knows.
This is part of why, in the natural order of priorities, the data layer comes first, the AI capabilities come second, and the interface (the thing that determines whether anyone can actually use all of it) tends to come last. Not because anyone thinks it doesn't matter, but because its contribution is hardest to recognize precisely when it's doing its job.
What trust actually requires
The language interface question isn't abstract. It connects directly to whether engineers trust the tools they're given. When an AI system suggests a root cause for a fault, the engineer's first reaction is almost never "great, thank you." It's "why?" Engineers who've spent years responsible for a specific subsystem have a deep relationship with their component. A suggestion without visible reasoning feels less like an insight and more like an accusation, and the instinct is to push back.
What changes this is when the data becomes visible in a way that matches how engineers actually think. When they can see the signals over time, follow the cascade, and verify the reasoning against their own experience, the tool stops making claims and starts showing evidence. Trust isn't built by providing answers. It's built by making the path to the answer visible.
A chat box that says "component X is the likely root cause" is useful. A visual interface that shows why (the signal behavior, the sequence of events, the dependencies) is what actually earns trust. The most powerful engineering tools will need both. And once the evidence is visible, new questions open up, the same ones we keep designing around at SPREAD: why AI UX needs friction at decision moments, and why earning an engineer's trust takes more than accuracy.
The design challenge ahead
For organizations investing in making their product data more connected and intelligent, there's a question worth sitting with: not just "is the data available?" but "what does it look like when someone needs to use it?"
That question plays out in whether a diagnostic code carries a readable label or just a raw identifier, in whether an architecture view adapts to the task at hand or overwhelms with completeness, in whether an AI suggestion comes with visible reasoning or just a conclusion. These choices shape whether a tool earns daily trust or quiet abandonment. They decide whether the investment in data infrastructure translates into better engineering decisions, or produces another system that people learn to work around.
The real design challenge isn't text versus visual. It's building tools that know when an engineer needs to ask a precise question and when they need to see what's happening, handling both without forcing a choice. An engineer can already get the answer. The tools that matter will be the ones that can also show what happened. And that's ours to design, not the AI's to provide.
Notes
Some of the ideas in this article draw on Michael Gerlich's research on cognitive offloading and structured prompting (Gerlich, 2025), Ben Shneiderman's work on information visualization (Shneiderman, 1996), the Interface Studies essay "When the interface flattens into a prompt", and Marshall McLuhan's "Understanding Media" (1964).