Designing AI experiences

What exactly is that pause before an AI answers? Let's try to understand. In a simple way. A web page feels instant because the file is already written.

It sits on a server, finished, waiting to be sent. An AI answer is not written yet. Before it writes anything, the model has to read your whole prompt. All of it.

If you pasted a long document in, that reading is the first part of your wait. Then it starts writing, and it writes one small piece at a time. One word, then the next. It cannot skip ahead and write the ending first.

And each piece costs a full trip through the model. Billions of numbers, multiplied, just to choose one word. That trip takes the same slice of time, every time. So the wait is really counting words.

Ten words come back fast. Five hundred take fifty times longer. The length of the answer sets the clock, not how hard the question was. A bigger model makes that trip longer.

More numbers to go through for every single word. So the smarter model is usually the slower one. Your request also leaves your device and waits in line behind everyone else's. Same prompt, busy hour, slower answer.

And nobody can tell you how long it will take. The model does not know how long its own answer is until it writes the last word. So, the pause is writing time. Read the prompt, then one word per trip.

The longer the answer, the longer you wait. Quick check now. One question is coming up. Let's see if it clicked.

How does streaming an AI answer work? Let's try to understand. In a simple way. Either way, the model writes one small piece at a time.

The only real choice is when those pieces reach your screen. Holding them back is called buffering. The server waits for the very last word, then sends one finished lump. You watch nothing for the whole write.

Streaming keeps the connection open instead. Each piece is pushed out the moment it exists. The first word lands in a fraction of a second. Here is the honest part.

The finish line does not move. Both answers complete at the same moment. Streaming does not make the model any faster. What changes is which clock you feel.

Time to the first word falls from seconds to almost nothing. Time to the last word is untouched. And you read slower than the model writes. So once the words are moving, your own reading hides the rest of the wait.

Moving text is also proof of life. A blank screen could mean thinking, or crashed, or lost. Appearing words say, it is working. There is a catch.

You are publishing before you check. Once a sentence is on the screen you cannot quietly take it back. So streaming fits text a person reads top to bottom. Half a table is not useful to anybody.

So, streaming is the same answer, handed over in pieces. Same finish time, first word almost immediately. Faster to feel, not faster to run. Quick check now.

One question is coming up. Let's see if it clicked.

What exactly is a skeleton screen? Let's try to understand. In a simple way. You send the question, and for a moment the screen is empty.

A blank area says nothing. Not whether it started, not what is coming. A spinning circle is barely better. It says something is happening, somewhere.

It never says what, or where it will land. But your interface already knows one thing. The shape. A title, a few lines of text, a card.

The layout exists before the words do. So draw that shape now. Grey bars where the text will go, an empty box where the card will go. That is a skeleton.

Each block takes exactly the room the real content needs. So when the answer arrives, it swaps in place. Nothing jumps down the page. None of this comes from the model.

Your own code draws the placeholder when the request leaves, and clears it when the first real piece arrives. Careful though. The shape is a promise. Five grey rows and then two real results reads like something broke.

Draw only what you asked for. That soft shimmer is a sign of life, not a measure of progress. A fake bar stuck at ninety percent is worse than none. And if the answer lands in a blink, the skeleton flashes and looks like a glitch.

Hold it for a beat, or skip it. So, a skeleton is the shape of the answer, drawn before the answer exists. Same space, no jumping, and the wait looks like progress. Quick check now.

One question is coming up. Let's see if it clicked.

What exactly is sampling in an AI's answer? Let's try to understand. In a simple way. At every step, the model does not pick a word.

It produces a whole list of possible next words, each with a chance attached. It could always take the highest one. By default it does not. It draws from the list, weighted by the chances.

That is sampling. And each word after is chosen from what is already written. So one different draw near the start sends the answer down another path. Temperature is the knob.

Low temperature sharpens the odds toward the top word. High temperature flattens them, so unlikely words get a real chance. Set it to zero and the roll disappears. The model takes the top word every time, so the same prompt gives the same answer.

Repeatable, but flatter. You can also fix the seed, the starting point of the random numbers. Same seed, same settings, same answer. That reproduces a bug.

Careful though. Some variation is not the roll. A hidden system message, a fresh search result, a quietly updated model. Different input, different answer.

So in your interface, make the second try a real button. And call what comes back another answer, not a better one. Never judge a prompt from one run. Run it five times and look at the spread.

One good answer can be luck. So, the same question meets a fresh roll at every word. Temperature sets how loaded that roll is. Only zero buys the same answer twice.

Quick check now. One question is coming up. Let's see if it clicked.

What exactly is a confidence score? Let's try to understand. In a simple way. Every word the model writes comes from a list of candidates, each with a chance attached.

The chance on the word it picked is a real number. Average those chances across the whole answer, and you get one number. That is what a confidence score usually is. Read what that actually measures.

How ordinary the sentence looked to the model. Not whether the fact inside is true. A smooth, familiar, wrong sentence scores high. So never ask the model how confident it is.

A written ninety percent is just more generated text. It never read the real numbers underneath. A useful score keeps a promise. Of everything marked ninety percent, about ninety in a hundred should be right.

Raw model scores run far too high, so check yours against answers you already know. On screen, never print ninety two point four percent. That decimal claims a precision the number does not have. Three bands are honest enough.

And a badge on its own is decoration. Each band should change what happens. High goes straight in. Medium asks you to check it.

Low never gets shown. One warning. People read a number as a fact. A high score on a wrong answer does not just lose that answer.

It loses the next ten. So, a confidence score is the model's sureness about its own wording, not proof about the world. Calibrate it, show bands, let it change what happens. Quick check now.

One question is coming up. Let's see if it clicked.

How does correcting an AI work? Let's try to understand. In a simple way. Every answer an AI gives is a first draft.

You are the one who can see what is wrong. Your correction is the signal. Here is the surprise. When you fix it, the model does not learn.

Its numbers are frozen, identical for every user, and your typing never touches them. So where does the fix go? Straight back into the conversation. That corrected line is text the model rereads before writing its next reply.

Which means it lasts only as long as that thread. Open a fresh chat, and the same mistake walks right back in. To survive the new chat, your own code has to store the correction and paste it into the next request. The model files nothing away.

Store it as a pair. What it wrote, and what the person changed it to. A thumbs down says something was wrong, never what. So put the edit right on the answer.

If fixing it means hunting for a feedback form, nobody bothers, and your best signal is gone. Then show what you kept, in their words. Otherwise people assume the model learned it, and feel tricked when the mistake returns. Every correction also lands in a log.

The team reads them together, and the ones that repeat become test cases, or training data later. So a correction is data you catch, not learning the model does. Fix the thread, store the pair, change the model later. Quick check now.

One question is coming up. Let's see if it clicked.

What exactly is a hallucination? Let's try to understand. In a simple way. A hallucination is an answer that is fluent, confident, and completely false.

Not a typo, not a crash. It sounds just like the true ones. Here is why. The model never stored a table of facts.

Training pressed everything it read into numbers that predict the next word. And it never has the option of a blank. For any question, some word is the most likely next one. So it writes that one.

So when the real detail was rare in training, the shape of the answer is still there. A date, a name, a paper title. It fills that shape with something typical. Notice that nothing broke.

The same machinery that gets capital cities right is what invented that paper title. There is no separate faulty mode. Which is why it cannot warn you. Inside, nothing marks remembered apart from reconstructed.

Both arrive at the same speed, in the same tone. The good news is that the failures are predictable. Exact figures, quotes, citations, dates, prices. Anything rare and specific is where the guessing lives.

And instructions do not remove it. Telling a model to never make things up cannot put back a fact it never stored. What helps is leaving fewer gaps. Hand it the document to answer from, and make the specifics cheap to check.

So, a hallucination is not lying. It is a pattern finished where the fact was missing, in the same confident voice as everything else. Quick check now. One question is coming up.

Let's see if it clicked.

How does showing sources work? Let's try to understand. In a simple way. An answer on its own leaves you two choices.

Believe it, or go check everything yourself. Nothing in the writing says which part to doubt. A source changes that. Beside the sentence sits the passage it came from.

Checking now costs seconds, instead of an afternoon. Where does that link come from? Not the model. Your code searched your documents first, and every passage came back carrying a title and a link.

The answer is then written from those passages, and each sentence marks the one it used. The link you show is stored data. Now the trap. Skip that search, and simply ask a model for its sources, and it writes them like everything else.

Real looking titles, dead links. So check them in code. Open every link, and confirm the passage really contains the claim. A citation that fails gets pulled, not printed.

Placement matters too. A pile of links at the bottom is not checkable. Attach each source to the sentence that used it. Careful here.

People trust an answer the moment a link appears, whether or not they click. A source they cannot open earns trust it never deserved. And when the search comes back empty, say so. An answer with no passage behind it should be marked a guess, or not shown.

So a source is not something the model recalls. Your search found the passage, your code checked it, and the reader can look. Quick check now. One question is coming up.

Let's see if it clicked.

How does showing the reasoning work? Let's try to understand. In a simple way. A bare answer is one jump.

Here is the conclusion, trust me. If it is wrong, you cannot see where. So we show the steps. But those steps are not a log of machine thinking.

They are text, written one word at a time, exactly like the answer. That sounds weak. It is not. Every step the model writes is read back in as input for the next words.

So thinking out loud changes the answer. And this only works in one order. Steps first, answer last, built on top of the steps already written. Now the trap.

Ask for the reason afterwards, in a second call. The choice is already made, so the model just writes a story about it. There is a word for the good kind. Faithful.

The steps are faithful only if the answer really came from them. Same call, steps above, nothing rewritten. You can push further. A step that names a number, or a lookup it ran, your code can check.

Pure prose, nobody can. Then the design part. A wall of thinking text buries the answer. Show a few labeled steps, folded shut, and let the reader open them.

One last thing. Those steps are generated words too. They are billed like words, and the reader waits while they are written. So a good explanation is not a look inside.

It is text the answer was built from. Steps first, folded on screen. Quick check now. One question is coming up.

Let's see if it clicked.

What exactly is setting expectations for an AI? Let's try to understand. In a simple way. A blank text box makes a promise.

Anything. So people try the widest thing they can imagine, and the first answer disappoints them. So ask the model what it can do? That fails.

It writes an answer from wording, not from a list of the tools it actually has. So it will claim skills it does not have. So the expectation lives in your interface. Fixed words that you wrote, sitting around the box.

Not generated, so it cannot drift. And it has to say both halves. What this thing does, and what it does not. An unnamed edge is where every bad first try lands.

Say what it can see, too. Which documents, and how fresh. Someone asking about yesterday assumes yesterday is in there. The strongest expectation is not a paragraph.

It is three example prompts sitting in the empty box. People copy the shape they are shown. Timing matters. A note under the answer arrives after they already believed it.

The scope belongs above the box, before they type. Your words set the checking. Call it a draft and people read it carefully. Call it the answer and they paste it straight into the email.

But do not warn on everything. A banner on every single reply turns into wallpaper. Spend the warning where a mistake actually costs something. So expectations are interface work.

Name both edges, show real examples, and say it before they type. Quick check now. One question is coming up. Let's see if it clicked.

How does undo for AI work? Let's try to understand. In a simple way. When you type, your work changes one letter at a time.

When the AI runs, a whole paragraph is replaced at once. No small step to walk back. So the unit of undo is the whole action. One run of the model, one step in the history.

And undo is not a rewind. It is restoring a copy. Your code has to save the old text before the model writes, because afterwards it is gone. Careful with regenerate.

It does not bring the old answer back. It makes a third version, because the model samples fresh words every time. So keep them all. A version history is a list of saved copies, each one labeled with the prompt that made it.

Also show what changed. Nobody proofreads a fresh rewrite, but anyone can check a few highlighted lines. Better still, let them keep part of it. Accept this sentence, reject that one.

All or nothing throws away good work over one bad line. Keep undo reachable later. People notice the bad edit ten minutes on, so one step back is not enough. Every saved version needs a way home.

One hard limit. If the AI already sent the email, restoring your document undoes nothing out there. Those need a confirmation before, not an undo after. So undo for AI means one action, one snapshot, saved before the model writes.

Show the difference, and ask first when nothing can be taken back. Quick check now. One question is coming up. Let's see if it clicked.

What exactly is multimodal input? Let's try to understand. In a simple way. A model reads only one kind of thing.

A long list of tokens. So a photo and a sound clip have to become tokens too. For a picture, an encoder cuts it into a grid of small squares called patches. Each patch becomes one token, read in order.

So a picture costs tokens too. A small one, a few hundred. A large one, over a thousand. More pixels, more patches, slower answers.

Most tools shrink the image first. Anything finer than one patch is gone. That is why tiny text in a screenshot comes back wrong. Sound works the same way.

The wave is sliced into windows, about twenty five milliseconds each. Every window becomes a picture of frequencies, then one token. Now a design choice. Some apps turn speech into text first, so only words reach the model.

Others feed audio tokens straight in, so tone survives. That choice shows up in your product. Transcribe first, and sarcasm, hesitation and who spoke are dropped. The user heard them.

The model never did. Once everything is tokens, it sits in one sequence. Your question and your picture, side by side. That is how the model compares them.

But this is not eyesight. Each patch is a rough summary, so exact positions and long codes stay shaky. Let people crop and zoom. So seeing and hearing are one trick.

Patches for pictures, windows for sound, tokens for both. Design for what gets thrown away. Quick check now. One question is coming up.

Let's see if it clicked.

How does structured output work? Let's try to understand. In a simple way. A model writes one thing.

A stream of words. Lovely to read, useless to a screen that needs a date and a price. So ask for data instead. Named fields with values.

Title, date, amount. Something your code can read and your interface can draw. You get that by sending a schema. A short list of the fields you want, and the type of each.

Text, number, true or false. And a schema is not a polite request. While the model writes, any token that would break the shape is blocked. So it always parses.

But valid is not correct. The shape is guaranteed. The meaning is not. A price field always holds a number, just maybe the wrong one.

For anything that drives your interface, ask for a closed list. Urgent, normal, low. Then every value can be wired to a real control. And always allow an unknown value.

A required field with no way out forces an answer, so the model invents one. Here is the payoff. Fields let you draw a real screen. An editable chip for each one, a map for the address, a confirm button.

One warning. A broken sentence looks broken. A neat field with the wrong date looks perfect. So show every field for editing first.

So, structured output means naming the fields, blocking anything off shape as it writes, and drawing the values as controls. Right shape. Still check the meaning. Quick check now.

One question is coming up. Let's see if it clicked.

How does proactive AI work? Let's try to understand. In a simple way. The model is not sitting there watching.

It runs only when something calls it. So proactive never means the AI woke up. It means your code called it without the user asking. So every proactive feature starts with a trigger in your code.

An email lands, a file is saved, a clock hits nine. That event fires the call. The trigger also packs the context. The model knows nothing about the moment, so your code pastes in what happened.

Now the hard part. Most of the time the right move is to stay quiet. So the answer needs a way to say, nothing worth showing. That is a threshold.

Ask for a score, and show it only above a line you picked. Below that, the run still happened, and you paid. Then decide, propose or act. Drafting a reply is a proposal.

Sending it is an action. Rank actions by the damage when wrong. Timing matters as much as content. The same tip helps while you write, and lands badly during a call.

Interrupting has a cost. Every dismissal is data. Log it with the trigger that fired. If one trigger is dismissed nine times out of ten, the trigger is wrong.

And give one plain switch to turn it off. People forgive a suggestion they can stop, not one that keeps arriving. So proactive AI is a trigger you wrote, context packed at that moment, and a threshold that keeps it quiet. Quick check now.

One question is coming up. Let's see if it clicked.

How does editing in place work? Let's try to understand. In a simple way. Normally the AI answers beside your work, and you copy the good parts across.

Editing in place skips that. The words land in the document itself. But the model never touches your file. It only produces text.

Your code takes that text and performs the write. The app is always the one editing. And it does not return the whole document. It returns one edit.

The exact old text to find, and the new text to put in its place. That old text has to match character for character. One extra space, and your code finds nothing, so nothing gets applied. Worse, if that line appears three times, which one?

So the edit carries a few lines around it. Enough context to match exactly once. The model wrote its edit from a snapshot. If you typed since then, that anchor is stale, and applying it would clobber your sentence.

It also edits only the slice it was shown. Paste one paragraph, and it cannot know the name you defined thirty pages up. Several edits often arrive together. Apply them one at a time, because the first write shifts every line number below it.

And the region it may touch is a check in your code, never a polite line in the prompt. Outside the selection, refuse the write. So editing in place is a patch. Find this exact text, replace it, and your code decides whether that write is safe.

Quick check now. One question is coming up. Let's see if it clicked.