Designing the AI Interface to Match User Intent

We've been embedding a chat box into every product that incorporates AI for two years. It makes sense: models are trained with dialogue, so chat seems like the "natural" interface. But a recent article from Smashing Magazine raises something that Bihotz has been advocating for some time: the correct modality doesn't depend on what the model can do, but on what the user needs at that specific moment.

The article illustrates this with a simple example. Someone running through an airport terminal, with a suitcase in one hand and coffee in the other, needs to know which gate to go to. The app asks them to type their locator into a tiny text box and then responds with a paragraph about the weather-related delay. The gate number is at the end, buried. The input fails because it demands something the user can't provide (typing with busy hands), and the output fails because it demands something else the user can't do (reading calmly while running).

This mismatch is the real problem. It's not that chat is a bad idea; it's that it has become the default for convenience in development, not because it fits the user's context.

Two questions before designing any AI interface

The framework proposed in the article boils down to two questions that are worth asking before sketching anything:

→ What modality can the user physically use to provide that input? Hands-free, busy hands, noisy environment, quiet environment.

→ What modality can they actually process as output? A screen they can look at calmly, or an alert they can only perceive peripherally.

Answers vary depending on the time of day, not on the typical user. A field technician needs voice and audio while climbing a pole with thick gloves, and a visual dashboard once back in the van. The same user, two different modalities, depending on what they are doing with their hands and eyes.

What this means for an e-commerce or brand project

Translating this to our work at the studio: when designing a shopping assistant, a conversational searcher, or any AI feature for a client, the question isn't "Should we add a chat?". It's what that touchpoint needs to respond to: a quick confirmation (button, not text), a product comparison (table or filters, not a paragraph), an open-ended exploratory question (here, chat works better).

Chat remains a valid and powerful tool. The mistake is using it as the only solution when the task calls for something else.