Chat Won't Kill the Dashboard

Founders keep asking me if chat will kill their UI.

The short answer is no.

Chat is better at one type of work in your product. But it's worse at two others. If you get the split right, chat becomes a useful new tool you can layer on top of what you have. If you get it wrong, you'll end up with a product that's harder to use.

Before you redesign anything, organize what your product does into three buckets.

Bucket 1: Friction work. Chat wins this.

Take calendar booking, configuration screens, or forms with a dozen fields. Anywhere the user knows what they want and the UI is a tax on getting there, chat will win.

Pasting a Calendly link and asking the other person to find a slot was always going to be replaced by "find me 30 minutes with Sarah next week." That's just cutting out the clicks. It's not news to anyone.

The same logic applies for the 47 settings nobody can find in your admin panel. Same logic for the multi-step form where the user has to think harder about your form than about their answer.

This is where you should lean in. These are the parts of your product nobody loved. Chat will absorb them whether you build for it or not.

Bucket 2: Sensemaking work. Chat loses this.

Let's take a sales pipeline. You scan the board. You spot the deals clustering in mid-stage. You see the rep with gaps. You drag a stuck deal forward. You regroup by close date to check the next month.

The work is in the seeing. It's spatial. Now ask a chat "how's my pipeline?" and you get a paragraph back. "23 deals, 8 in late stage, $145K weighted."

That's not the same thing. The thing you actually wanted to know (the mid-stage deals are stalling) lived in the spatial view, not in the chat response.

Chat can describe what's on the board. It can't be the board.

Even as chat interfaces start rendering visuals, charts, and interactive elements, the dynamic doesn't change. Chat is still request-and-response. You ask, you get shown, you ask again. A real Kanban view is the working surface, not a thing you retrieve. You don't query it. You drag, you regroup, you scroll. You see other things while you work on one thing.

This isn't a model problem. Better LLMs won't fix it. Multimodal chat won't fix it. It's a layout problem. Anything in your product that involves comparing, scanning, or spotting patterns in data needs to live on a visual surface. And probably a better visual UI than you have now.

Bucket 3: Authorization work. Chat loses this.

When the action is "send this $7,500 invoice", users want to see what they're committing to before they click. The line items, the total, the tax breakdown, the customer name spelled correctly.

A chat confirmation collapses everything you need to check into one line. A reviewable screen lays it out so you can scrutinize, edit, and stop. When money moves, people want to read the page before pressing the button.

Modern agents will start showing you a structured preview of the invoice before they send it, and that helps. But it's still a preview inside a conversation. The screen disappears the moment you act. A real review surface is somewhere you can sit, navigate to the customer record to double-check the address, come back, edit a line item, then commit. That difference matters more as the stakes go up.

This isn't just current behavior either. Audit trails, compliance, and regulatory requirements all assume a visible record of what was authorized and when. Even when users trust the agent, the system around them often legally needs to show the page.

But not every "user has to confirm" action belongs here.

Rescheduling a meeting is friction work with a confirm step. Sending a $7,500 invoice is authorization work. The difference is the consequence of being wrong, not whether confirmation is needed. Once you sort by consequence, the category gets bigger fast: billing changes, bulk operations, customer emails, deletions, anything irreversible or externally visible.

For most B2B SaaS products, this bucket is bigger than the friction one. So if you're deciding where to invest design time, start here. Make the visual review screen clearer about what's about to happen.

Build for the split

Chat handles the friction. Visual UI handles the judgment.

Review your product this week and map each screen to one of the three buckets. The friction screens are where chat will really help.

The sensemaking screens need more design, not less. The authorization screens stay visual, and they need to make the stakes obvious before the user commits.

Most founders bolt chat onto the visual interface without thinking about what it's good for or where it doesn't belong. The product isn't one thing. It's three things, and each one needs a different answer.

Chat won't kill the dashboard. It will kill the parts of your product that were never doing real work.

That's good news if your dashboard was ever any good in the first place.