Summarize with AI
Good AI search UX design builds the answer out of the results on the page, so a reader can see which result each line came from. Do not put a generated answer on top of the old ten-link results page and call it AI search. Decide per query whether an answer should appear at all, how long it should be, and what the page shows when nothing matches.
Most AI search products ship the stacked version first because it is quick to build. It is also the version users learn to skip, so you pay for every answer and earn none of the trust. If you came here about AI answers taking clicks from your own website, that is a different problem, covered in why position 1 now gets zero clicks. This post is about the search page inside your own product.
The four-paragraph answer above 38 results
Picture an AI search tool for company knowledge. It connects to a customer's Drive, Slack and Confluence. The search bar says Search docs, threads and people. A sales manager at a 140-person company types london per diem, because she flies out on Monday.
The page loads in two parts. At the top sits a box labelled AI answer, with a small Beta chip. It holds four paragraphs, about 260 words. The first paragraph says the London rate is £65 a day. The next three explain what counts as a meal, how to file receipts and who approves exceptions. Under the box, one grey line reads Generated from your workspace.
Below that, the old page carries on as if nothing happened. 38 results. Filter tabs for All, Docs, Slack and People. Ten blue titles, each with a file path, a date and two lines of snippet. Result one is Travel and Expenses Policy 2025, updated 12 March. Its snippet ends with the words London: £80 per day. Result four is Travel FAQ (old), from 2023. That one says £65.
So the answer and the first result disagree, and nothing on the page says which document the answer used. She scrolls past the box, opens result one, reads the number and closes the tab.
What the founder sees from his side
The founder of that tool watches the metrics he built. A tile on his dashboard reads Answers generated: 41,812 this month. Another tile counts thumbs up on answers, and it holds a few dozen. In session replays the cursor moves the same way again and again. It goes down past the box, to the first three links.
His first fix is to make the answer harder to miss. A taller box, a gradient border, the Beta chip moved to the right. Then he makes the answer longer, on the theory that people skip it because it is thin. Clicks on the links stay where they were before the answer existed.
Then a pilot goes the wrong way. A customer tests his product against a smaller rival that indexes fewer apps and runs a cheaper model. The rival's page shows two sentences and three source cards, each with a document title and a date. The pilot summary says something like the other tool was easier to trust. He has eval numbers showing his retrieval finds more. None of that reached the person who chose.
The money sits under all of this. Every one of those 41,812 answers was a model call, paid for whether anyone read it or not. AI product builders average around 52 percent gross margin, against 70 to 80 percent for traditional software, because inference lands in cost of goods. A product that pays for an answer on every query, then watches users scroll past it, spends margin it does not have on a box people ignore.
Why the stacked page gets the worst of both
The common advice is to add the AI answer on top and keep the links below as a fallback. That sounds safe, and it is the layout that fails. Each half makes the other half worse.
The answer pushes the results down the screen, so the thing people trusted before now sits below the fold. The results, in turn, make the answer look unsupported. Ten documents sit right there, and the answer does not say which of them it read. A reader who sees an answer and a list side by side does the reasonable thing. She checks the answer against the list. When she cannot match them, she trusts the list, because the list at least says where it came from.
The founder knows his answer was built from his top results, because he built the retrieval. A stranger looking at the page has no way to know that. To her, a block of text above a list of links is two separate things.
Build the answer out of the results on the page
The fix is a change of layout, not a better prompt. The documents the answer used move up and become part of the answer. Everything else moves down under a label that says what it is.
For the per diem search, the top of the page would read like this. One sentence: London is £80 a day for meals, from the 2025 travel policy. A small marker [1] sits at the end of the sentence. Directly under it is a card numbered 1: Travel and Expenses Policy 2025, People Ops, updated 12 March, with the matching line highlighted. A second card, numbered 2, shows the old FAQ with a grey tag reading Replaced by [1]. Below the cards a heading reads Other matches, and the remaining results sit under it.
There are two ways to show sources at this level. Inline markers after each claim tell the reader which line came from which card. A single source list at the end tells her only that some sources exist. For a search page, put the markers inline and the cards right under the answer, not at the bottom of the page. The marker is how she checks the claim. The card is how she opens the document without hunting for it.
There is a useful parallel outside search. On the website we built for Sawdust, a music licensing company, the page does not ask brands to trust a paragraph saying the music is cleared. It lists each layer of rights, the master recording, the composition, the performer rights, the sync license, and says next to each one who holds it or how it was cleared. The claim and its owner sit side by side. An AI answer needs the same shape, at a much smaller size.
How long the answer should be, and when to skip it
Answer length should follow what the person is trying to do, not a fixed box size. Read a few hundred real queries and most fall into four kinds:
- Find a thing. Q3 board deck, Priya onboarding doc. Show no answer. Put the file first, with one Open button.
- Look up a fact. London per diem, office wifi password, holiday calendar. One sentence with the fact, its source and its date.
- Learn how to do something. How do we run a security review for a new vendor. Three to six short steps, each one tied to a card.
- Pull things together. What did customers say about SSO last month. A short grouped summary, with a count of how many threads it read and a way to see all of them.
Here is a claim many teams will resist: a good AI search page skips the answer often. If the query names a file, a person or a channel, a generated answer only gets in the way. If one document matches far better than all the others, show the matching passage from that document instead. A quoted passage with its title on top beats a paraphrase of the same text every time. One test covers most cases. If the answer would be longer than the passage it came from, show the passage.
Skipping also saves money: every answer not generated is inference not paid for.
The empty screen and the not-sure screen
Two states decide whether people keep using AI search after their first bad result, and both are usually left as defaults.
The zero-result state. Most tools print No results found, or worse, generate a confident answer from nothing. Say what was searched and what came closest instead: No document mentions a per diem for Lisbon. Closest match: Travel and Expenses Policy 2025, which lists eight cities. Then give one next step, such as a button reading Ask in #people-ops.
The low-confidence state. When sources disagree, the stacked page picks one and hides the conflict. Show the conflict instead, ranked by date: Two documents give different rates. The 2025 policy says £80. A 2023 FAQ says £65. The newer one is shown first. That small line does more for trust than a longer answer, because it shows the tool read both and did not guess. Our guide to designing for AI errors covers the wider pattern of making uncertainty visible without making the product look broken.
What to change this week
None of this needs a new model. It needs a decision about the page. A small team can do the first pass in a week:
- Export your last 500 search queries. Tag 100 of them by hand into the four kinds above. Count how many are find-a-thing queries, where the answer box should not appear at all.
- Take 20 recent answers. For each sentence, mark which result on the page supports it. Count the sentences that no visible result supports. That count is your trust problem, written down.
- Move the results each answer used into the answer block as numbered cards. Put a heading reading Other matches over the rest.
- Set a length rule for each query kind and enforce it in the prompt and in the layout. A box that can only hold one sentence for a fact lookup cannot grow into four paragraphs.
- Write the zero-result screen and the sources-disagree screen in real words, with one next step each.
- Stop counting thumbs. Count an answer as used when someone opens a source card, copies the answer, or does not search again within a minute.
If you would rather hand this to someone, our ranking of product design agencies for AI search products compares studios that have worked on this kind of page.
Where Studio Maydit fits
You know your retrieval is good, because you built it. The person typing london per diem knows only what the page shows her, and right now it shows an answer and a list that do not talk to each other. Studio Maydit designs the product screens where people decide whether to trust an AI tool and keep using it, for AI founders in the US, UK and Europe. A fixed-scope project runs three to four weeks and ends with a diagnosis of what is leaking in the product, so you see where users drop the answer before you pay for another month of generating it. If your search page has an answer on top that people scroll past, book a 30-minute call with Studio Maydit.
