Nobody Knows What to Do With the Cursor

I have opened probably forty AI products in the last eighteen months. Founders showing me their beta. Clients asking for feedback before launch. Random tools I found on Product Hunt at midnight. And almost every single one of them has the same problem. The interface has no idea what to tell the user to do first.

There is a blinking cursor in a text box. Maybe a placeholder that says something like 'Ask me anything.' And then nothing. No signal. No example. No sense of what this thing is actually good at. The founder built the model, trained it on their data, made it do something genuinely useful, and then handed the user an empty white box and hoped for the best.

That is not a design problem. That is a product strategy problem that shows up as a design problem. And most teams building AI right now are walking right into it.

The Onboarding Gap Is Wider Than You Think

Traditional SaaS has spent twenty years figuring out onboarding. There are playbooks. There are patterns. Empty states, tooltips, progress bars, the whole thing. AI products are starting from scratch, and most of them do not realize it yet.

When someone opens a standard project management tool, they roughly know what it does. They have used something like it before. The mental model is already there. When someone opens a new AI product, they often have no idea what the ceiling is. They do not know what to ask. They do not know what the tool is exceptional at versus what it will fumble. And if you do not answer that question in the first thirty seconds, they close the tab and do not come back.

I watched a founder demo his AI research tool to a room of potential users. Smart people. The tool was genuinely impressive once you knew how to use it. Three out of five people in that room typed a vague query, got a mediocre response, shrugged, and moved on. The tool was capable of so much more. The interface never told them that.

This is the real onboarding gap. Not the signup flow. Not the email sequence. The moment between landing and the first wow. Most AI products never close it.

Chat Is Not Always the Answer

The AI industry decided that chat is the interface. OpenAI shipped chat. Everyone else shipped chat. And now every AI product, regardless of what it actually does, has a chat box somewhere on the screen.

Chat works when the task is genuinely open ended. When the user needs to explore, iterate, go back and forth. It works for writing assistants, for research tools, for general purpose models where the range of inputs is truly unlimited. But most AI products are not that. Most AI products do one specific thing really well. And wrapping that thing in a chat interface is like putting a steering wheel on a bicycle. Technically you can do it. It does not make the bicycle better.

If your AI product analyzes financial documents, the interface should look like a financial tool with AI built in, not a chatbot that happens to know about finance. If it generates marketing copy, give me structured inputs, tone controls, output previews. Not a blank box and a send button. The teams who figure this out early are the ones building products that actually retain users past week two.

At Kraftelite, we push back on the default chat assumption in almost every AI product brief we get. Not because chat is wrong. Because it is often the lazy answer to a hard design question.

Latency Is a Design Problem

AI is slow. Not always. But often. And the way most products handle that wait time is a placeholder spinner that looks like it was copied from a 2015 SaaS template.

Latency is one of the most underdesigned parts of AI interfaces right now. And nobody is really talking about it. When a user submits a prompt and waits eight seconds for a response, those eight seconds are doing something to their brain. They are either building anticipation, or they are building doubt. The interface decides which one.

Streaming responses changed this. Watching the output appear word by word feels faster than it is. It keeps the user engaged. It signals that something is happening. The products that figured out streaming early feel noticeably better than the ones still showing a spinner. But streaming alone is not enough. The space around it, the sound of it, the typography of it, the way the output lands on screen, all of that is doing design work whether you planned it or not.

Think about what happens after the response loads. Where does the eye go? What is the next obvious action? Most AI interfaces answer this with silence. The response appears. And then nothing. No nudge, no follow up prompt, no path forward. The conversation just stops and waits for the user to figure out what to do next.

Designing for Uncertainty Is a Skill Nobody Taught Us

Here is what makes AI interfaces genuinely hard. The output is unpredictable. A form field gives you the same result every time. An AI response does not. Which means your interface has to handle good outputs and bad outputs and everything in between, and it has to do that gracefully without the designer knowing in advance what the output will look like.

Most teams design for the best case. The clean response. The right length. The formatted output that fits perfectly in the container. Then real users start using the product and the responses come back too long, or too short, or weirdly structured, or just wrong. And the interface falls apart.

Designing for uncertainty means building interfaces that hold up regardless of what comes out. It means thinking about overflow, about error states, about what happens when the model confidently gives the wrong answer. That last one is the one teams consistently ignore. When an AI is wrong, the interface should make it easy for the user to say so and try again. Most products make this awkward. Some make it impossible.

This is not a new design skill. Designing for failure states has always been part of the job. But AI raises the stakes because the failures are less predictable and more varied than anything we have designed for before.

The Visual Language of AI Is Still Being Invented

There are no established conventions yet. No clear patterns for what an AI action looks like versus a manual action. No shared visual language for confidence levels, for source attribution, for the difference between something the AI generated and something the user wrote.

Some products are starting to build this. The little sparkle icon has become a shorthand for AI generated content. But it is still early. Most products are borrowing patterns from adjacent spaces and hoping they transfer. Some do. Many do not.

The teams doing this best are the ones treating the visual language as a product decision, not a styling decision. They are asking what does trust look like in this interface, and then designing toward that answer deliberately. Not just picking a color for the AI bubble and moving on.

At Kraftelite, the AI product work we do starts with that question. What does this interface need to communicate before the user has even typed anything. Because if the visual language is not doing that work from frame one, you are already behind.

Prompt Design Is UX Work

The best thing a designer can do for an AI product right now is spend two hours trying to break the prompts. Type in weird things. Type in vague things. Type in exactly the wrong thing and see what comes back. Because that is what your users will do.

Prompt design is not an engineering problem. It is a user experience problem. How you teach users to write better inputs, how you give them starting points, how you surface examples and templates and guardrails without making the interface feel restricted, that is design work. Real design work.

The products that nail this feel almost magical. You open them and within thirty seconds you understand what to ask and how to ask it. The interface has trained you without you noticing. That does not happen by accident. It happens because someone thought hard about the space between the user and the model and filled it with the right signals.

Nobody has fully figured this out yet. The whole category is still in early innings. But the gap between the products that take this seriously and the ones that treat the interface as an afterthought is already visible. And it is only going to get wider.

Build the Interface Like the Model Depends on It

The model is not the product. The interface is the product. The model is infrastructure. Users do not experience the model. They experience what you built around it.

That shift in thinking changes everything. It means the design decisions are not decorative. They are load bearing. The way you handle the first empty state, the way you surface what the AI is good at, the way you communicate latency, the way you design for wrong answers, all of that is directly connected to whether users stay or leave.

Most founding teams are former engineers or domain experts. They built the model. They understand the model. The interface is the last thing they think about and the first thing users judge. Closing that gap is the work.

If you are building an AI product and the design is still an afterthought, you are going to feel that in your retention numbers before you feel it anywhere else. The teams who figure out that interface design and model quality are equally important are the ones who end up with products that actually grow. Kraftelite works with founders at exactly this stage, when the model is ready but the product still needs to become something people actually want to use every day.