Why fixed-output thinking fails
Most screens in a normal app are predictable. You click Save, the record saves. You open a report, you see the same report. A designer can draw one screen for each result, and the screen is the truth.
An AI feature does not work like that. You ask the same question twice and get two different answers. Sometimes the answer is great. Sometimes it is slow, wrong, half finished or confident about something it made up. The designer cannot draw "the result", because there is no single result.
This is the main change in AI product design. You stop designing one outcome and start designing a range of outcomes. The model is only one part. Most of what the user feels comes from everything around it: what you tell them before, how the answer arrives, and what they can do when it is not right.
The five states of an AI answer
When we start on an AI feature, we list its states before we draw a single screen. There are usually five.
- Empty. The user has not asked anything yet. This is the screen that decides whether they know what to do.
- Working. The model is thinking or streaming. The user is waiting and wondering if anything is happening.
- Good. The answer is right and useful. Most teams only design this one.
- Wrong. The answer is off, made up or does not match what the user meant. The user needs a way out.
- Unsure. The model does not know, has no data, or the request is outside what the product can do. "I don't know" needs a design too.
A feature that handles only the good state works in a demo. It breaks on the second day of real use. Users forgive a wrong answer if the product makes it easy to see, fix and retry. They do not forgive a product that hides its mistakes.
Setting expectations before the first prompt
Trust starts before the first answer. If a user opens a blank box with a blinking cursor, they have to guess what is allowed. Some will type something too big. Some will type something too small. Some will leave.
A few things help:
- Example prompts that match real tasks. Write them from what your users actually do, not from what looks clever. Three good ones teach more than a paragraph of help text.
- A plain line about what the feature can and cannot do. "Answers questions about your sales data. Does not edit records." One sentence is enough.
- A hint about the data it uses. If the answer comes from connected sources, show which ones are connected. People trust an answer more when they know where it came from.
Our AI Business Assistant work on the work page is an example. It shows a chat that answers with charts and tables, lets people share or rewrite an answer, and shows which data sources are connected. Those small parts are not decoration. They tell the user what the product knows.
Letting users check, edit and retry
The user should never be stuck with an answer they cannot use. For each type of answer, ask what the next step might be.
- Check. Can the user see where the answer came from? A source link, a data table behind the chart or the exact rows used.
- Edit. Can they change the answer directly, or only ask again? For text, direct editing is usually better. For a chart, changing the filter may be better.
- Retry. Can they run it again, or change the question and keep what they had? Losing the previous answer when you retry is a small thing that annoys people a lot.
- Tell you. A simple way to say "this was wrong" gives your team a signal. Keep it light. A thumbs-down with an optional note is enough to start.
None of this is new interaction design. What is new is that every one of these paths is now common, not rare. In a normal app, errors are exceptions. In an AI product, a wrong or partial answer is part of daily use.
Who needs to decide the states
This is where teams get stuck. The states cut across roles, and each decision has an owner.
- Product decides what the feature should refuse to do.
- ML or engineering knows how the model fails, how slow it is and what it can say about its own confidence.
- Design decides how each state looks, reads and behaves.
- Support or legal, where it applies, decide what the product must never claim.
The best moment to bring these people together is early, with real samples of model output on the table. Not the best outputs, the bad ones too. We always ask to read the bad ones. They show us which states we need.
What to hand your engineers
A pile of screens is not enough for an AI feature. Engineers need to know when each screen appears. We hand over a state table next to the designs. Something like this:
| State | What triggers it | What the user sees | What they can do |
|---|---|---|---|
| Empty | No messages yet | Example prompts, short scope line | Pick a prompt or type |
| Working | Request sent | Streaming text or progress note | Stop |
| Good | Answer received | Answer with sources | Copy, edit, retry |
| Wrong | User flags it | Prompt to rephrase or retry | Retry, edit the question |
| Unsure | No data, low confidence or timeout | Plain "I can't answer this" message | Rephrase, contact support |
Fill in your own triggers. The exercise often shows holes in the plan, like "what happens when the model times out?" before anyone has written code.
Where to start with a small feature
You do not need to redesign your whole product. Pick one AI feature, such as a summary button, a search box or a drafting helper. Then:
- Write the five states for it on one page.
- Collect ten real outputs, including at least three bad ones.
- Draw the empty, wrong and unsure screens first. These are the ones that usually get skipped.
- Give it to five people who use your product and watch what they do when the answer is off.
You do not need a finished model for this. Sample outputs are enough to start. If you want a second pair of eyes on your AI feature, the details of how we work are on our AI product design agency page. Or send us one screen for a free design review through the contact page, and we will tell you which of the five states we think is missing.
