Summarize with AI
For most AI products, chat is the right interface only when the request changes every time, or when the user cannot say what they want until they see something. When people repeat the same task, a GUI wins. A screen with a table, a filter and one clear button does the job faster than a conversation, because the screen holds the request so the user does not have to type it again.
This matters for an early AI team because the chat box is usually not a design choice. It is what ships when nobody has decided what the interface should be. The founder can make it sing, because he knows exactly what to ask. A new user types four words, gets a paragraph back, and leaves without saying why.
Match March invoices, and a paragraph comes back
Picture an AI tool for small finance teams that matches supplier invoices to bank payments. It shipped as a chat window because that was the fastest thing to build. The whole screen is one text box with the placeholder Ask about your invoices, a paperclip icon and a send arrow.
A controller at a forty-person company opens it on the third working day of April and types Match March invoices. A spinner runs. The reply is a paragraph. It says the assistant found 226 invoices for March, matched 212 of them to payments, and found 14 that need a look. Then it lists the 14 as bullets, each one a full sentence: INV-0412 from Northgate Supplies, invoiced 4,180.00, paid 4,018.00, possibly an early payment discount. It ends with a question. Would you like me to mark the 212 matched invoices as reconciled?
She types yes. Then she scrolls back up to bullet six, because she knows that supplier pays in two parts, and sends a second message to hold that one back. Then she opens her spreadsheet in another tab. The chat has no place to see all 226 rows, sort them by supplier, or tick one off.
What she needed was a screen titled March reconciliation. A table with 226 rows and five columns: Invoice, Supplier, Invoiced, Paid, Status. 212 rows marked Matched in green. 14 rows in amber, with the reason in the Status cell, like Short by 162.00 or Two payments found. A filter at the top reading Needs review (14). One button, Approve 212 matched. The model does exactly the same work. Only the shape of the answer changes.
Next month she will type Match April invoices, and all of it will happen again.
The chat box is the interface nobody decided on
A chat box is the easiest interface to build around a model, because the model already speaks text. One input, one output, a scrolling list of messages. It needs no decisions about which objects exist, what the columns are, or which button matters most. That is exactly why teams ship it. It postpones the design work and still looks finished.
Most advice on chat interface vs GUI treats it as a matter of user taste. Some people like to talk, some like to click. That framing is wrong. Nobody prefers typing the same request every month. People put up with it because nobody built the screen. For a repeated task, the chat box is not one of two options. It is the missing option.
The founder rarely sees this from inside. When he demos the invoice tool, he types a long request: match March invoices, flag anything off by more than 2 percent, show it as a table with invoice, supplier, invoiced and paid. The model returns a clean table and the call goes well. He knows the product, so he knows what to ask. A stranger only knows the problem.
Good prompts, pasted into the welcome email
In this example, the signs show up as behaviour, not as complaints. He keeps a doc called Good prompts and pastes a link to it into the welcome email. He records a short video on how to ask for a table. He adds three suggestion chips above the box: Match this month, Show unpaid, Export to CSV. Every fix teaches users to talk to the product the way he does.
Meanwhile the session logs repeat one pattern. New accounts send one or two short messages and stop. The accounts that stay are the ones he walked through on a call. He reads that as proof the product works once people get it. It is proof the product works when he is the interface. Jakob Nielsen calls the gap between knowing what you want and putting it into words the articulation barrier. A blank chat box puts every user in front of that gap on every visit, and only the founder gets over it easily.
The repeat-use test for chat vs a screen
Run each task your AI does through four questions. Be honest about the answers, not hopeful.
- Will the same person do this task again next week or next month? If yes, it wants a screen. Repeated work should never depend on retyping a request.
- Does the answer hold more than about ten items the user must compare, sort or act on one by one? Then it is a table or a list, not a paragraph.
- Is there a main action at the end, like approve, send or publish? Then that action is a button with a count on it, not a reply that says yes.
- Can the user state the whole request before seeing anything? If not, and they need to try, look and adjust, chat earns its place.
A yes on any of the first three points to a screen. A no on the last one points to chat. Most work in a B2B AI product, such as matching, triage, reporting and review, lands on the screen side. Drafting, research and one-off questions land on the chat side. Our conversational UI design guide covers how to make chat work once you have chosen it. This post is about making that choice on purpose.
What a chat box costs when the task repeats
The first cost is activation. If the activation event for the invoice tool is a first month reconciled, the chat version hides it behind a prompt the user has to invent and a list they rebuild in a spreadsheet. Product-led SaaS benchmarks put activation at 20 to 40 percent for most products, and a ten point lift typically drives a 15 to 25 percent increase in free-to-paid conversion. A screen that hands over 212 matches behind one button is a cheap place to win those points.
The second cost is margin. Every retyped request and every correction is another model call. AI product builders average around 52 percent gross margin, against 70 to 80 percent for traditional software, because inference sits in cost of goods. A chat flow that needs three turns to do what one button does pays for the same work three times, for every customer, every month.
The third cost is the founder's calendar. If the product only works when someone knows how to ask, growth runs through the people who know how to ask. That is usually one person. Investors notice when every good number traces back to the founder being on the call, and they price the company more like a service than like software.
Chat that opens a screen instead of writing a reply
The fix is rarely to delete the chat. It is to change what the chat returns. In the invoice tool, Match March invoices should not come back as a paragraph. It should open the March reconciliation screen, already filled in, with the 14 amber rows at the top. The text box stays as a way in. The result is an object the user can sort, edit and approve.
This is the pattern behind most AI products that hold up under daily use. The model does the work. The interface gives the work a home: a table, a draft, a diff, a chart, a list with checkboxes. Once the object exists, the next step is a click, not a sentence. When the screen itself is built on the fly by the model, the same rule holds, and our post on generative UI patterns covers where that helps and where it breaks.
Over time the box becomes the least used part of the product. That is a good sign. It means the repeated work found a screen, and chat is left for what is actually new.
Move one task off chat this week
You do not need a redesign to start. Pick one task and work through these steps.
- Pull the last 200 messages that new users sent. Group them by what they wanted. In a tool like this one, three or four intents usually cover most of them.
- Take the intent that repeats most. Write down the object it should produce: its name, its columns or fields, and its one main action, with the count in the button label.
- Sketch that screen on paper before anyone opens a design tool. If you cannot name the main button, the team has not decided what the task is yet.
- Ship it as the answer to the chat request first. When a user types that intent, open the screen instead of writing a reply.
- Once people use it, add it to the navigation, so next month they click April instead of typing a sentence.
- Watch five new users do the task with no help. If any of them still opens a spreadsheet, the screen is missing a column.
Where chat should stay
Chat is still the right interface for some jobs. It fits first drafts, open research, questions about the user's own data that nobody predicted, and the moment when someone does not yet know what to ask. It is also a fast way in for an expert who already knows the exact request. The mistake is not having a chat box. The mistake is letting the chat box be the whole product, because nobody decided what else it should be.
Studio Maydit designs the screens an AI product needs once the chat box stops being enough: the first run, the repeated task, the object a request should produce. We work with AI founders in the US, UK and Europe, usually on a fixed scope of three to four weeks that ends with a diagnosis of where the product is losing people. The Dualite case study shows that kind of work on an AI dev tool, which reached 100,000+ users in seven months after design work supporting a repositioned ICP. If you would rather compare studios first, here is our ranking of design agencies for AI chat interfaces. If your product only lands when you are the one typing, book a call and we will pick the first task to move off chat.
