Chat Won't Kill Your Product UI

Founders keep asking me if chat will kill their product 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 project board. You scan the columns. You see what's in progress, what's blocked, what shipped this week. A chat could tell you all of that.

But you also see what isn't there. There's no card for the security review, and you can't launch without it. Nobody created it.

Ask a chat "how's the project?" and you get a confident answer. "18 tasks, 5 in progress, 3 blocked, on track for Friday." It's summarizing the board it was handed. It can't flag the task that was never on it.

The work is in the seeing. The board shows you what's missing. A summary only knows what's there.

Even when chat can render the whole board, the problem doesn't change. Jason Fried made this point recently. Say a chat spins up your dashboard on request. Impressive the first time you see it. But do you want to type that request out every morning, or click once and have it sitting there the way it always was?

It's 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. Asking someone to prompt for a view they used to get in one click isn't progress. It's a slower version of what they already had.

And it's more expensive. A dashboard that used to be a cached database query becomes an LLM call, regenerated every time someone opens it. Multiply that across a whole team pulling the same numbers every morning, and you're paying tokens to rebuild a view you could have just stored.

It's a layout problem, not a model problem. So anything in your product that involves comparing, scanning, or spotting patterns belongs on a visual surface, not in a chat.

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 your UI. 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.