Conversation is the new responsive.

A merchant wants to change a price. She opens the catalog, finds the product, clicks through to edit, changes the number, and hits save. Five steps through screens somebody designed years ago, and she does this dozens of times a week.

Now she types one sentence: update product X to $49.99. The system asks her to confirm the SKU, pulls the current data, shows her a draft of the change, and asks once more before it applies. Then it tells her what happened and links to the product so she can check. Fewer clicks, a lot less screen to wade through, and honestly more clarity about what just happened.

The belief we run into is that this is a chatbot you add to the corner of the product. Put a bubble on the screen, connect a model, call it done. We are convinced that gets the whole thing wrong, because conversation doesn't change the layout, it changes the flow.

Conversation changes the flow

None of this is new. In 2015, design teams such as Fjord, part of Accenture, were already playing with conversational interfaces when none of the pieces to build one existed. There were no large language models and no real infrastructure, so most people read it as a research curiosity. To us it was always the endgame, because interfaces had been a workaround for machines that couldn't hold a conversation with you.

Responsive design made us rethink layout. This asks for something harder. We are no longer designing screens only, we are writing exchanges, with prompts and replies and little checks along the way, and the user is the one steering. The interface doesn't disappear. Its job shifts from being the main event to supporting the conversation with clarity, feedback, and a reason to trust what just happened.

The best model is a call center

Responsive design had grids and breakpoints to lean on. For conversation, the best working model we know is the humble call center. Those scripts have been tuned for decades for speed, clarity, and repeatability, and whether you want to change a password or close an account, a tested path is waiting to walk you through it.

So when we design a conversational feature, we think like the person on the line:

• What is the user trying to do?
• What is the clearest path to get them there?
• Where should we confirm, clarify, or redirect?
• How do we show the result in a way that builds trust?

The new craft is reusable conversation patterns, and flows with clear entry points, confirmations, and exits, much like we do for interface components. And not everything should be conversational. Responsive never killed desktop-first thinking either, this simply adds one more option to the table, so data representations go in when they add value and not by default.

It is cheaper to build than it sounds

The second half of the belief is that this needs a big new stack: an agent server, a tool server, a team to run them. Sometimes it does. Often it doesn't, because the thing you need is already sitting in the product, your REST and your GraphQL, the APIs your own front end has talked to for years.

On Companion, the assistant we built into the BigCommerce admin, the model orchestrated the platform's existing APIs, with no dedicated backend. More recently we built a working shopping agent on a test store that runs in the browser with an emerging standard called WebMCP, so the agent talks straight to the same APIs from the page. Around five hundred lines of server-side machinery, the part whose whole job was shuttling a tool call across the network and pouring the conversation back in to resume, simply went away, and the agent worked better without it. That kind of agent, the chatbot that actually does things, can be stood up in days when it leans on what you have already built.

That prototype also became the reference. The engineers who wanted the same tools on a server later got the complete list, every tool, instead of a document to interpret.

What to bring to the conversation

If you are thinking about this for your own product, the useful asset is probably not a model. It is a clean set of APIs, a handful of tasks people do over and over, and a clear idea of where a person must confirm before anything changes. Those are enough to start designing the exchange and to put a real prototype in front of your team. The teams that understand this early are the ones who will shape whatever comes next.