Add AI search to an existing product when users need help finding or combining information they already have permission to access. Begin with the retrieval task, then choose whether a search box, conversational assistant, or inline answer gives users the clearest path to completion.
The design questions are narrower than “Where can this product use AI?” A team needs to know what people are trying to find, how they recognize a useful answer, and what they do with it. The following is a suggested planning framework, not a prescription to replace existing search.
Should the entry point be search, chat, or an inline answer?
Keep search prominent when users want to locate a known document or record. Results can remain useful even if the system cannot produce a reliable summary. Let people refine a query and open the underlying material.
A conversational assistant may fit a question that needs clarification or several follow-ups. Specify how users can inspect and change the conversation’s scope. A follow-up about a different customer should not silently inherit the previous customer’s context.
Use an inline answer when the surrounding screen already defines the task. In a hypothetical project management product, a summary of unresolved blockers may belong beside the project’s open issues. Asking the user to explain which project they mean in a separate chat would add work.
Prototype the entry point against the existing workflow. Include experienced users who know the filters as well as people who struggle to find the right terms. A change that helps one group can obscure a useful shortcut for another.
What information may an answer use?
Define the allowed collections, workspace boundaries, and user permissions before writing the empty-state prompt. The answer system must enforce access rules when retrieving information and when preparing the response. Hiding a source link after exposing its contents is not a permission safeguard.
Specify what happens when access changes during a session. A conversation should not continue revealing restricted material simply because an earlier turn could retrieve it. Engineering and security owners need to define this behavior; design should make access limitations understandable without disclosing protected details.
For the hypothetical project tool, write example questions for a project member and for a user outside the project. Include a question whose answer spans accessible and inaccessible documents. Review the expected response before testing the visual presentation.
What makes a source citation useful?
A citation should take the user to material that supports the associated statement. Show enough identifying information to distinguish similar documents, and open the relevant section where the product supports it. A list of document titles at the bottom does not show which source supports a disputed deadline.
Keep source age separate from answer generation time. A response generated today may summarize a plan last updated months ago. Where freshness affects the task, show the source’s update date and describe any known retrieval delay accurately.
When sources conflict, surface the disagreement instead of choosing a date without explanation. In an illustrative scenario, an older project brief lists a release in October while a newer issue discusses a delay. The answer can show both records and ask the user to verify the current plan with its owner.
What should happen when search cannot answer?
Distinguish an empty result from a temporary service failure and from a question the product does not support. Each needs a different next step. An empty result may warrant broader search terms; an unavailable service may warrant a retry.
Google’s People + AI Guidebook on errors and recovery describes different sources of failure and the need for actionable recovery. For search, that means a no-answer screen should explain the available path forward without pretending the requested information exists.
Keep access to ordinary results when they are available. Let users narrow the date range, choose a collection, or open a document directly. Do not turn every unsuccessful question into a demand that the user learn better prompting.
What should a citation test card contain?
Illustrative example, not a client result: a teammate asks when a release will ship. An approved project brief names October 15; a newer issue says the launch is delayed but gives no replacement date. The expected answer should describe the conflict rather than select a date that sounds plausible.
- Question: When will the release ship? Record the user role and documents that role can access.
- Expected behavior: identify the old date, describe the unresolved delay, and link each statement to its supporting passage.
- Failure conditions: invent a replacement date, cite the wrong document, or reveal information from a restricted source.
- Recovery: offer the ordinary search results and identify the responsible project owner when that information is available.
- Repeat after access changes. A correct answer for an administrator may still be an unacceptable answer for another user.
How should the team test the feature before rollout?
Build a task set with known-item searches, questions requiring several sources, ambiguous terms, stale documents, and questions with no supported answer. Include permission boundaries and conflicting records. Have domain experts judge whether the answer supports the task, not merely whether it sounds plausible.
Hamel Husain and Shreya Shankar’s article on building AI evaluation systems recommends learning from concrete errors before settling on metrics. Apply that discipline to the retrieval tasks: record the failed question and source context, then decide which quality checks the product needs.
Before commissioning AI integration UX for an existing SaaS product, agree on the entry point, permission rules, citation behavior, and fallback flow. For the wider product experience, read the guide to UX design for AI-powered startup products.
