Last Update:

Nov 10, 2026

UX Design

Search UX Design: Essential Best Practices, Patterns & Examples for SaaS

Quick Summary

Start with user intent: Understand what people want to find before choosing a search pattern or designing the interface.
Choose the right search pattern: Basic, active, focused, global, and command search each serve different user needs and workflows.
Make autocomplete useful: Provide relevant suggestions, distinguish suggested queries from actual results, and avoid overwhelming users.
Prioritize result relevance: Put exact matches first, display useful metadata, and make filters and sorting easy to understand.
Design better zero-results experiences: Explain why nothing matched and offer practical recovery options without exposing private information.
Build accessibility into search: Support keyboard navigation, screen readers, clear labels, and accessible mobile interactions.
Protect user privacy: Apply permission checks across search results, suggestions, snippets, and result counts.
Measure task success: Track whether users find the right information and complete their tasks, rather than relying only on clicks or search speed.
Use AI search strategically: Combine keyword and semantic search when appropriate, but preserve exact-match accuracy and make AI-generated answers verifiable.

Picture this. (It's a made-up example, but a very common one.) A finance manager opens her company's billing app and types INV-1042 into the search bar. The search bar looks great, and results pop up instantly. But she gets twelve invoices that just happen to contain "1042" somewhere, in a total, a date, or a customer number. The one invoice she wanted isn't there. In the end, she gives up and asks a coworker to send her the link.

Nothing on the screen looked broken. Still, the search failed, because it didn't help her do the one thing she came for: open that invoice and check if it was paid.

That's what search UX design is about. It isn't only about making a nice-looking search bar. It's about making sure people can find what they need, quickly, and trust what they found. People call this findability.

In this guide, you'll learn how to:

figure out what people are really trying to find
pick the right type of search for your product
design the search bar, suggestions, and results
handle searches that find nothing
make search work for everyone, including keyboard and screen reader users
test whether your search actually works

Along the way, we'll use research from trusted sources like Baymard Institute, Nielsen Norman Group, IBM's Carbon Design System, and the W3C. We'll also point out when a finding comes from online shopping sites and may not fit software products the same way.

What Is Search UX Design?

Search UX design is the planning and design of everything that happens when someone searches inside a website or app. It covers what they type, what the system finds, how the results look, what happens when nothing matches, and whether the person gets what they came for.

The search box is just the part you can see. Every search goes through five simple steps:

Ask. The person turns a goal ("Was this invoice paid?") into words ("INV-1042").
Find. The system looks for matching items, but only in the right place, and only items this person is allowed to see.
Check. The person looks at the results and decides if one is right.
Fix. If not, they change their words, add a filter, or search somewhere else.
Finish. They open the item, get the task done, or confirm the thing doesn't exist.

If any step goes wrong, it feels like "search is broken" to the user, even when the real problem is hidden behind the screen.

Search also works side by side with your menus. Together, they affect two things. Findability is how easily people find something they know exists, like a certain invoice. UX discoverability is how easily people come across things they didn't know about, like a handy export button. Search is great for findability.

It doesn't help much with discoverability, because people don't search for things they don't know exist. That's why search can't replace clear menus and labels.

Search UX vs. search UI

Search UI is what you see: the search box, the icon, the dropdown of suggestions, the filters, the result cards, and the "no results" message.

Search UX is all of that, plus the parts you can't see, such as:

how the system reads and cleans up what you typed
how it pulls matching items from its search index (its organized list of everything that can be searched)
how relevance ranking decides which result comes first
which items each person is allowed to see
what happens when nothing matches

Why does this matter? Because a beautiful search bar can sit on top of search logic that treats an invoice number like random text, and no design polish can fix that. It also means search isn't only a designer's job. Designers, developers, and the people who manage the data all shape it. If your plan just says "make the search bar better," you might end up fixing the wrong thing.

Website search vs. in-app search

"Site search" and "in-app search" sound alike, but they usually do different jobs:

	Website search	In-app search
Who searches	Often visitors who aren’t logged in	Logged-in users with different roles
What they search	Pages, articles, products, help docs	Their own work: customers, tickets, invoices, files
What they type	Topics and everyday questions	Names, ID numbers, and codes
Who sees what	Mostly everyone sees the same things	Each role may see different things
What success looks like	Reading or buying something	Opening a record or finishing a task

Both are different from SEO. SEO is about getting your pages to show up on Google. Search UX design is about what happens once someone is already on your site or in your app and uses its own search box.

Key search UX terms

Here are the words you'll see in this guide, explained in plain English:

Term	What it means
Query	The words someone types into search
Search intent	The goal behind those words, like checking if an invoice was paid
Search index	The organized list of content that search looks through. If something isn’t in the index, search can’t find it
Retrieval	Finding the items that match what someone typed
Relevance ranking	Deciding which matching items show up first
Autocomplete (typeahead)	Suggestions that appear while someone is typing
Live results	Real matching items that update as someone types
Scope	The area search looks in, like one folder or the whole app
Filter	A rule that hides results that don’t fit, like “Status: Unpaid”
Facet	A group of filters for different details at once, often with a count next to each
Zero-results state	What people see when a search finds nothing
Findability	How easily people find something they know exists

Start With the User's Search Task

It's tempting to jump straight to the search bar: where to put it, whether to add suggestions, how the results should look. But it's hard to make good choices until you know what people are trying to do when they search.

It's also worth asking: is search really the problem? Sometimes people search because they can't find things in the menus. Maybe an important page is buried three clicks deep, or the menu uses words your users don't use.

Before you redesign the search bar, check whether your product's information architecture (how your content is organized and labeled) makes things easy to find in the first place. A better search box can cover up messy navigation, but it can't fix it.

Four kinds of search tasks

People search for different reasons. A popular way to group them, used by Pencil & Paper and others, is by what the person wants at the end. In a software product, one search bar often has to handle all four.

Type of search	Example	Success looks like	What often goes wrong
Finding one exact item (known-item search)	Open invoice INV-1042	That exact invoice shows up first	Lots of “close” matches bury the right one
Exploring	Find unpaid invoices over $5,000 for one customer	A list you can narrow down and trust	Not enough filters, or results in a confusing order
Going somewhere or doing something	“billing settings” or “export invoices”	You land on the right page or start the action	Search only looks at records, not app features
Checking that something doesn’t exist	Make sure vendor “Northwind” isn’t already saved before adding it	A clear “no match” you can trust	You can’t tell if it’s truly missing, filtered out, or in another area

Don't skip that last one. Sometimes "no results" is exactly the right answer, as long as the person can trust it. That only works if the screen clearly shows where search looked and which filters were on.

Fill in a Search Task Contract

A Search Task Contract is a simple one-page template we suggest for planning a search task. It isn't a scientifically tested method. It's just a handy way to put the right questions in one place, so designers, developers, and product managers agree on what search should do.
Here's one filled in for our invoice example. The scenario and data are made up.

Question	What it means	Our invoice example
What’s the job?	What the person is trying to finish	Check if INV-1042 was paid before replying to a supplier
What will they type?	The words or numbers they’ll probably enter	The invoice number, sometimes partial (“1042”) or written differently (“INV1042”, “inv 1042”)
Where should the search look?	The default area, or scope	Invoices in the current company account, with an option to search everything
What can they see?	Their permissions	Finance staff see all invoices; a sales rep sees only their own customers’ invoices
What should show up?	The ideal result	The right invoice at the top, showing status, amount, customer, and due date
What if it isn’t found?	The backup plan	Say no invoice matched in this area, show any filters that are on, and offer to search more widely. Never hint that a hidden invoice exists
How do we know it works?	Proof of success	In a test with sample data, people open the right invoice and correctly say whether it was paid

Filling this in helps you make decisions that usually get skipped. For example, should typing "1042" also match an invoice total of $1,042.00? For this task, no. The person typed an ID, so money amounts are just noise. Should "INV1042" without the dash still find it? Yes.

These sound like technical rules, but they come straight from understanding the task. Once the contract is written, they're much easier to explain to your developers.

How to Choose the Right Search UX Pattern

A search UX pattern is a common, proven way to design search. Each one works well in some situations and badly in others. To pick one, you balance four things: what users need, how much data you have, how fast your system is, and how well users know the content.

Basic, active, and focused search

IBM's Carbon Design System describes three handy patterns. They're useful even if you don't use Carbon.

Basic search: you type, press Enter, and see results on a new page. Carbon recommends it when searching is slow or heavy for your system, or when users don't know the data well. It runs only one search each time someone submits, so it's easy on your servers.
Active search: results update right under the box as you type each letter, with no search button. Carbon suggests it for small data sets, product catalogs, filtering a list already on the page, and users who know what they want. The catch: your system has to handle a search on almost every keystroke.
Focused search: a mix of the two. It shows live results only inside the area you're in, like one folder or project, plus an option to search everything. Searching a smaller area keeps the load down, and Carbon notes that chosen filters stay in place between searches.

Active search feels fast and modern, so it's tempting to use it everywhere. But in a big, slow invoice database, results can jump around while you type. You'll see matches for "1", then "10", then "104" before you've even finished the number.

Global, scoped, advanced, and command search

Global search looks through everything you're allowed to see. It's great when you don't know where something lives. The downside is clutter: searching "Acme" might return a customer, 40 invoices, a dozen tickets, and an email template.

Scoped search only looks in one area, like the current project or table. Results are cleaner, but there's a risk. If someone doesn't notice they're searching only one area, they may find nothing and think the item doesn't exist. So show the scope clearly in the search box, and let people change it from the results page.

Advanced search lets expert users build precise searches with extra fields or special search words. Tools for developers and project teams use this a lot. For example, GitHub lets you type filters like repo: and is:open, and Jira has its own search language. It's great for trained users who run the same exact searches often. It's a bad idea as the only way to search, because casual users won't learn the special words.

Command search, often called a command palette and opened with a keyboard shortcut, helps people find actions and pages instead of records. Think "create invoice" or "go to billing settings." It's a big time-saver for regular users. Just remember it's a different job from finding records. If your command palette shows both, group and label them clearly.

There's one more option: maybe you don't need better search at all. If most people keep searching for the same few pages, better menus might solve the problem faster and more cheaply.

Where to put the search bar on desktop and mobile

There's no single perfect spot. It depends on how important search is in your product. In a help center or documentation site, where many visits start with a search, a big, open search box near the top makes sense.

In a work tool where people search only now and then, a small search icon plus a keyboard shortcut may be enough. A big search box there just takes space away from the main work.

On mobile, many apps use a search icon that opens a full-screen search. It saves space, but it adds an extra tap and hides which area you're searching until it opens. If search is the main way people get around your app, keep it easier to reach.

Which pattern fits which task?

This table is a starting point we suggest, not a proven formula. Use it to talk through options with your team, then test your choice with real tasks.

What people are doing	Pattern that often fits	Works well when	Probably wrong when
Finding one exact item in a small data set	Active search	Results come back fast and lists are short	IDs are long and partial matches flood the list
Finding one exact item in a big data set	Basic search that puts exact matches first, plus record suggestions	IDs follow a clear format	Suggestions show records the user can’t open
Exploring	Basic search with a results page and filters	Records have good, consistent details	Many records are missing details, so filters come up empty
Searching inside one area	Focused or scoped search	Users clearly know where they are	The scope label is easy to miss
Going to a page or doing an action	Command palette	Users are regulars who like keyboard shortcuts	Users are new and don’t know it exists
Expert searches done often	Advanced search	Users are trained and repeat the same searches	It’s the only option for casual users

Search Bar Best Practices: Inputs, Autocomplete, and Suggestions

The search bar is where people turn what they want into words, so small details here make a big difference. A good habit is to design every state of your search, not just the "happy" one. There are six to sketch:

The empty search box
The box while suggestions are showing
The results
The results after filters
A search that finds nothing the person can open
The way back from there

Teams that only design the happy path usually meet the other five for the first time after launch.

Search bar label, scope, and query

Tell people what they can search. "Search invoices" is clearer than just "Search", and in a scoped search it also shows where search is looking.

Don't use placeholder text (the gray hint inside the box) as the only label. It disappears as soon as someone starts typing, and screen readers need a proper name for the field, either a visible label or a hidden one like aria-label.

A few more small things matter a lot:

Keep the search words in the box after searching, so people can edit them instead of retyping.
Add an easy way to clear the box.
If someone opens a result and goes back, keep their search words, filters, and scroll position. Otherwise they have to start over.

Search suggestions vs. live results

Different things can appear under a search box, and people need to know which one they're looking at:

Query suggestions finish or reword what the person is typing. This is what most people call autocomplete or typeahead. Picking one runs a search.
Record suggestions point to one specific item, like "INV-1042 · Acme Corp · Paid". Picking one opens it.
Recent searches show the person's own past searches.
Live results are real matching items that update as the person types.

If you mix these without clear groups, people won't know what a click will do. There's also a hidden problem: a suggestion promises that results exist. Nielsen Norman Group's guidance on site search suggestions says to only suggest searches that lead to useful results. In a software product, that has to mean results this particular person is allowed to see.

Keep your expectations realistic, too. In the same article, NN/g reported that people picked a suggestion in 23% of the cases where suggestions appeared (31 out of 136, give or take 7%). That came from a study of online shopping sites, published in 2018, so it isn't a rule for every product.

Still, it shows that many people just keep typing and ignore the dropdown. Suggestions should help, never get in the way. NN/g also recommends making the suggested words look different from what the person typed, for example with bold text, so it's clear what was added.

You'll often see a "best" number of suggestions quoted online. There's no magic number. It depends on screen size, how different the suggestions are, and whether they're grouped.

Keyboard and screen reader basics

Autocomplete is one of the trickier things to make accessible, so start from a trusted guide instead of inventing your own behavior. The W3C's ARIA Authoring Practices combobox pattern explains how it should work. It describes a few styles of autocomplete, such as a list that filters as you type, or a list plus the rest of the word filled in right in the box. It also explains what the keyboard should do. Simply put: the cursor stays in the search box, the Down Arrow moves through suggestions, Enter picks one, and Escape closes the list.

The small details are where custom builds usually break. Following the W3C pattern is a good start, but it isn't proof that everyone can use it. Always test with a keyboard and with real screen readers.

Search Results UX: Make Results Relevant and Easy to Judge

A good results page does two jobs. It puts the most useful items near the top. And it gives people enough information to pick the right one without opening every result. Most teams focus on the first job and forget the second.

So how does search decide what goes first? In software products, it's usually a mix of signals, such as:

an exact match on an ID or name
where the match was found (a match in the title usually counts more than one hidden in a note)
how recent the item is
whether the item belongs to the person or their team

The right mix depends on the task. Showing the newest items first helps when people want recent activity, but it gets in the way when they want one old invoice. Whatever rules you use, help people see why a result showed up, for example by highlighting the matching words or showing the sort order.

Show the details people need to choose

Good result details (designers call them metadata) answer the question the person has right now. For our invoice task, that's the invoice number, customer, amount, status, and due date. Often that's enough to finish the task right from the results page.

For a help article, it might be the title, a short snippet showing the matching words, and the product area. For a shared document, who owns it and when it was last edited often matter more.

Three details are easy to forget:

Type. In global search, "Acme" could be a customer, an invoice, or a ticket. A small label saves a click.
Status or version. A draft invoice and a sent invoice with the same number look identical without it.
Location. Which account or project the result belongs to, so people can tell similar items apart.

Here's a simple test: can someone pick the right result, or rule them all out, without opening each one?

Filters, facets, and sorting

These three often get mixed up, but they do different things. Nielsen Norman Group has clear definitions of filters and facets:

Filters narrow the list by hiding items that don't fit.
Facets are a set of filters for several details at once, like status, customer, date, and amount, which people can combine.
Sorting changes the order of results without hiding any.

Facets are powerful for exploring, but NN/g points out a hidden cost: someone has to add and look after the details behind them. A "Customer" facet is only as good as the customer field on every record. If half the records leave it blank, the facet quietly hides half your data.

Two problems come up a lot in software products. The first is filters that stay switched on without being visible, so people come back days later and get confusing results. The second is results sorted by date when people needed the best match, which pushes the exact invoice INV-1042 below newer ones. The fix for both: show active filters near the results, and show the sort order.

Exact IDs vs. everyday questions

Some searches need precision. Others need the system to understand meaning. Many apps get both. Here are two made-up searches in the same invoice app:

Search	What the person needs	What search should focus on
INV-1042	One exact record	Matching that exact ID, even if typed slightly differently, and putting it first
invoices Acme disputed last quarter	A group of related records	Matching the customer, status, and date, maybe with help from meaning-based search

This is where the technology behind search becomes a design choice. Keyword (lexical) search matches the actual words you typed. It's great for IDs, codes, and names. Semantic (vector) search matches by meaning, which helps when people describe something in different words than the record uses.

Microsoft's guide to hybrid search in Azure AI Search explains how some systems run both kinds at once and combine the results, because each one has its own strengths. For an ID like INV-1042, exact matching matters most. If "similar" invoices show up above the exact one, search has failed the task.

Keep private records private

In most business apps, some records exist but aren't meant for everyone. Search can leak that information in surprisingly many places:

a suggestion that completes a customer name the person shouldn't know about
a snippet that shows a line from a private document
a count like "Acme Corp (12)" that includes records the person can't open
a message saying "You don't have access to this invoice", which confirms it exists

OWASP, a well-known web security group, lists broken object-level authorization as the number one risk in its API Security Top 10 (2023). In simple terms, that's when a system doesn't check whether a person is allowed to see the specific item they asked for. The same idea applies to search.

The permission check has to happen everywhere: in results, suggestions, snippets, and counts, not only when someone opens a record. Designers decide which of these parts exist, so this is a design issue too. Have someone who knows security review any search design for an app with permissions.

No Search Results UX: Design Useful Recovery

Most advice about the "no results" screen, often called the zero-results page, focuses on the words: be friendly, suggest something, don't leave people stuck. That's good advice, but it skips a step. Before you decide what the page should say, find out why it's empty. The right fix depends on the cause.

Find out why nothing came back

A search can come back empty for very different reasons:

The item really doesn't exist.
It exists, but search hasn't added it to the index yet.
The person used different words, like "client" instead of "customer".
They combined details that search doesn't understand together.
They searched the wrong area.
A filter is hiding it.
It exists, but this person isn't allowed to see it.

Baymard Institute, which studies online shopping sites, gives a great example of the fourth reason. In its 2026 analysis of search query types, Baymard reports that 56% of the sites in its study don't support people's searches well enough.

That's based on more than 10,000 ratings across 170+ online stores and apps. In one test on Home Depot's mobile site, someone searched for a refrigerator using both a size and a style. They got a "No results" page. But the site had filters for both, and 45 matching fridges could be found by browsing that category.

Two things to keep in mind. This research is about online shopping, and the Home Depot result is what Baymard saw during testing, not necessarily how the site works today. Still, the lesson fits software too. The empty page wasn't a writing problem. The products were there, and search just didn't connect the words to them. Nicer "no results" text would never have found those 45 fridges.

Make the empty screen honest and helpful

Once you know the likely causes, the empty screen can actually help:

Repeat what was searched, and where. "No invoices matching INV-1042 in the Acme account" tells people exactly what happened.
Show active filters, each with a one-click remove. If a filter is the cause, this is usually the fastest fix.
Offer to search a wider area if the search only looked in one place.
Suggest a spelling fix only when search is confident. A wrong "Did you mean...?" is worse than none.
Give a useful next step, like creating the record if that makes sense, or contacting an admin about access in general terms.

The empty screen should never reveal private information. "This invoice exists, but you can't view it" tells someone about a record they may have no right to know about. In many products, "No matching invoices you have access to", plus a general way to request access, is the safer choice. Check this with whoever looks after security for your product.

When "no results" is the right answer

If someone is checking that a vendor isn't already in the system before adding it, "no results" is exactly what they hoped to see. So don't treat every empty search as a failure, in design reviews or in your analytics.

The design job here is to make "no results" trustworthy. People need to see that the search looked in the right place, that no filters were hiding matches, and that small spelling differences were covered. Without that, they'll search three more ways, or create a duplicate.

The Search Failure Diagnostic Worksheet

This is a simple worksheet we suggest for testing search problems on purpose, so your team finds real causes instead of guessing. Set up a test account with made-up sample data and at least two user roles. Try each case, write down what happens, and test again after you make changes.

What to test	Example search (made-up data)	What should happen	If it fails, the likely cause
Exact ID	INV-1042	The invoice shows up first	Search treats the ID as loose text; exact matches aren’t put first
ID written differently	INV1042, inv 1042	The same invoice is found	Search doesn’t ignore case, spaces, or dashes
Typo	Acme Crop	Acme Corp records, or a confident spelling fix	No typo tolerance for names
Different word	“client Acme” when records say “customer”	Customer records are found	Search doesn’t know the words mean the same thing
Combined details	unpaid invoices over 5000	A filtered list, or a tip to use filters	Search can’t turn words into filters
Old filter still on	Any normal search with a forgotten filter	A visible filter with a way to clear it	Filters stay on without showing
Wrong area	An invoice searched from the Tickets area	A prompt to search more widely	The search area is unclear or can’t be changed
Private record	A real ID searched by someone without access	No result, and no hints in suggestions, counts, or snippets	Permission is checked only when a record is opened
Truly missing	INV-9999, which doesn’t exist	A clear “no match” people can trust	The empty screen hides the search area or filters
Brand-new or slow	A record created a few minutes ago	Found, or a clear note that it’s still being added	The search index is behind; no loading message

When you use it, add columns for what actually happened, what you think caused it, and retest the date. If the same problems keep showing up along with confusing menus and labels people don't recognize, the issue may be bigger than search.

How to Make Search Accessible on Every Device

Search is always changing on screen: lists pop up, results update, filter counts shift. That makes it an easy place for accessibility problems to hide, especially for people who use a keyboard or a screen reader.

The tips below point to official W3C guidance. Following them in your design is a great start, but only testing the finished product can show whether it really meets the WCAG accessibility standard.

Keyboard access, labels, and focus

Every part of search should work without a mouse. People should be able to reach the search box, move through suggestions, add and remove filters, and jump from the results back to the box, all with the keyboard.

Focus, the spot on the page that's currently active, should behave in a predictable way. If results update while someone is typing, focus should stay in the search box, not jump to the first result. When a filter panel opens and closes, focus should return to a sensible spot, not leap to the top of the page.

The ARIA combobox pattern mentioned earlier covers the suggestion list. Filter panels, result lists, and page numbers need the same care. They're often built separately and never tested together.

Tell screen reader users when results change

When results change without the page reloading, sighted people see it happen. Screen reader users may have no idea anything changed. WCAG 2.2 Success Criterion 4.1.3, Status Messages (Level AA), covers this. It says short status updates should be read out by screen readers without moving the person's focus.

The key is knowing the difference between the results and the status. A short message like "12 results" or "No matching invoices" is a status message. The list of results itself is not. A good approach is to announce a short summary once the results settle, not after every single keystroke, which quickly turns into noise.

Tap targets and mobile filters

Mobile search screens are full of tiny buttons: the clear button, filter chips, the little "x" on each filter. WCAG 2.2 Success Criterion 2.5.8, Target Size (Minimum) (Level AA), sets a minimum size of 24 by 24 CSS pixels for things people tap or click.

There are some exceptions, for example when a small target has enough empty space around it, when it's a link inside a sentence, or when another control does the same job at a bigger size. The stricter Level AAA rule (2.5.5) asks for 44 by 44 CSS pixels. Tiny "remove filter" icons squeezed close together are an easy place to fall short.

Mobile filters also raise a question with no single right answer: should each filter apply right away, or should people pick several and then tap an "Apply" button? Applying right away gives instant feedback and works well with fast systems and simple, single-choice filters.

A "Show 37 results" button works better with slower systems and multi-choice filters, and it stops results from jumping around after every tap. Whichever you choose, show how many results the current choices will give, and make sure the update is announced to screen readers.

How to Test and Measure Search UX

It's easy to measure search the wrong way. Dashboards fill up with numbers like how many searches happen, how many results get clicked, and how long people stay on the results page.

None of those tell you if people found the right thing. A click on the wrong invoice still counts as a click. A short visit might mean success, or it might mean someone gave up.

Decide what success means first

Success looks different for each kind of search, and your Search Task Contract already spells it out. Success might be:

opening the right record (finding one exact item)
getting a list of results the person trusts enough to act on (exploring)
landing on the right page or starting the right action (going somewhere)
confidently confirming that nothing they're allowed to see matches (checking something doesn't exist)

Only after that do numbers like completion rate, time taken, or how often people retype their search really mean anything. The same number can even mean opposite things. Retyping a search several times is a bad sign when someone wants one exact invoice, but it's perfectly normal when someone is exploring.

Developers often check search quality with two measures from the world of information retrieval. Precision is how many of the returned results are actually relevant. Recall is how many of all the relevant records the search managed to find.

Both need a set of test searches with known right answers, and both are worth tracking. But they measure the search engine, not the person using it. Search can find every relevant invoice and still fail someone who can't tell which of twelve similar invoices is the right one. Use these numbers alongside task success, not instead of it.

Test with tasks where you know the answer

The most reliable way to test search is with tasks where you already know the right answer. Set up a test account with made-up sample data, create logins for the roles that matter, and write tasks from your contracts, like "Find out whether invoice INV-1042 has been paid."

Because you know the right answer, you can tell the difference between someone who found the right record and someone who confidently picked the wrong one.

Ask people to think out loud while they search. You'll hear why they chose certain words, what they expected to see, and where they stopped trusting the results. To understand both what people do and why they struggle, mix task-based testing with other UX research methods, such as interviews about how people describe their records and analytics on real usage.

Use search logs, but know their limits

Search logs show what people searched for, in their own words, across many users. Nielsen Norman Group's guide to search-log analysis explains how teams can use them to spot popular searches, failed searches, and word mismatches. Useful things to look for:

searches that find nothing, grouped by type (IDs, typos, feature names)
searches that are quickly retyped
searches for features or pages, which may point to menu problems
searches followed by no click and no next step

Logs show what happened, but rarely why. A search with no results might be a missing record, a word mismatch, or a correct "it doesn't exist." Treat what you find in logs as clues to test, not as final answers.

The Task Success Scorecard

The scorecard is a simple way we suggest to record test results the same way every time. Score each task on its own points, instead of squeezing everything into one "search score", which tends to hide the exact problems you need to see.

What to check	What to write down	Example: the INV-1042 task
Correct	Did the person reach the right result, based on the known answer?	Opened INV-1042, not a similar invoice
Finished	Did they finish, give up, or ask for help?	Finished without help
Mistakes	Wrong results opened, wrong filters used, wrong area searched	Opened one wrong invoice first
Effort	Number of searches, retypes, and time taken	Two searches, under a minute
Recovery	When something went wrong, did the screen help them get back on track?	Noticed the area label and searched more widely
Confidence	How sure were they? Ask after the task	“Fairly sure”; checked the status twice

Confidence matters most when people are checking that something doesn't exist. If someone correctly says "no match" but isn't sure, they may well create a duplicate record in real life.

Use the scorecard before and after a change, with the same tasks, roles, and sample data, so the comparison actually means something. A redesign that makes search faster but less accurate isn't an improvement when people need one exact record.

When AI-Assisted Search Helps, and When It Doesn't

Lots of software teams are now wondering whether to add AI to their search. The useful question isn't "Is AI search better?" It's "Which of our users' tasks would help, and which might quietly break?"

Keyword, meaning-based, and hybrid search

These 3 approaches decide what counts as a match in different ways:

Approach	How it matches	Good at	Not so good at
1. Keyword (lexical)	The exact words and numbers you typed	IDs, codes, names, exact phrases	Different words for the same idea
2. Meaning-based (semantic or vector)	How similar the meaning is	Searches written like everyday sentences	Exact IDs, which can lose out to “similar” items
3. Hybrid	Runs both and combines the results	Apps where people search for both IDs and descriptions	Takes more setup and fine-tuning

Microsoft's guide to hybrid search describes running a keyword search and a vector search at the same time, then merging them into one ranked list. In an app where people search for both "INV-1042" and "invoices from the customer who disputed shipping fees", hybrid search can handle both. Still, test it with your exact-ID searches, because a combined list can push the exact match below items that are only similar.

AI answers need to show their sources

An AI-generated answer sums up information instead of just listing results. Most of these features use something called retrieval-augmented generation (RAG): the system first finds matching records, then an AI model writes an answer based on them. So the answer can only be as good as the search step underneath it.

In a help center, a short AI answer to "How do I change my billing email?" can save someone from reading three articles. With business records, it's riskier. "Yes, INV-1042 was paid on March 3" is only useful if the person can see and open the invoice the answer came from.

So show the answer and its sources side by side. Let people open the actual records, and make clear which part of the answer came from which record. When money or legal decisions are involved, people need to check the record itself, not just trust a summary.

Problems to test for

AI search brings some new ways to fail. Add each one to your Search Failure Diagnostic Worksheet:

Wrong ID. Search shows a similar invoice instead of the exact one.
Old information. The answer is based on an outdated document or an index that's behind.
Too confident. The answer sounds sure even when the match is weak.
Slow answers. Writing an answer takes time, which hurts tasks that used to be instant.
Private details. A summary includes details from records the person couldn't open themselves. It's the same permission problem as before, with even more places to leak.

Not every product needs AI search. If most of your users search for IDs and names, improving exact matching and the details shown in results may help more than adding a new AI model.

Frequently Asked Questions

Where should the search bar go?

Place the search bar where users naturally start their tasks. Content-heavy websites and help centers benefit from a visible search box near the top. SaaS products can use a smaller search field or icon with a keyboard shortcut.

Should a product use search or filters?

Most products need both. Search helps users find specific items, such as invoices or customer names. Filters help narrow results by details like status, date, or amount. Users can search first, then apply filters to refine results.

What should a no-results page say?

A no-results page should explain what happened and offer a way forward. Repeat the search query, show active filters, and suggest useful next steps. Let users clear filters or search a wider area without revealing private records.

What is fuzzy search, and when should you use it?

Fuzzy search finds close matches when users make spelling mistakes. For example, searching "Acme Crop" can return "Acme Corp." It works well for names and product terms, but exact matches should always come first for IDs and codes.

Does every search bar need autocomplete?

No. Autocomplete works best when users search for predictable items, such as customer or product names. It is less useful for unique queries. Suggestions should also lead to relevant results that users have permission to access.

When are saved searches worth adding?

Saved searches help users who regularly repeat the same searches with specific filters. For example, finance teams can save searches for overdue invoices. Let users name saved searches, review their filters, and respect individual access permissions.

Search UX Checklist and Next Steps

Here's everything from this guide turned into simple yes-or-no questions you can ask about your own product. Any "no" or "not sure" is worth adding to your Search Failure Diagnostic Worksheet.

The checklist

The task

☐ Have we written down the main reasons people search, including going to a page and checking that something doesn't exist?

☐ Do we know what success looks like for each one?

Search area and pattern

☐ Does search look in the right area by default, and is that area shown in the search box?

☐ Can people change the search area from the results page?

☐ Does our search pattern (basic, active, focused, or command) fit how much data we have and how fast our system is?

Search bar and suggestions

☐ Does the search box have a proper label, not just gray placeholder text?

☐ Can people tell suggested searches, suggested records, and live results apart?

☐ Do suggestions only show results this person can open?

Results

☐ Do exact IDs show up first, even when typed a bit differently?

☐ Can people pick the right result without opening each one?

☐ Are active filters and the sort order easy to see?

No results

☐ Does the empty screen show what was searched, where, and which filters were on?

☐ Can people trust a "no match" when they're checking that something doesn't exist?

Accessibility

☐ Does all of search work with just a keyboard, with focus where people expect it?

☐ Are result updates announced to screen readers?

☐ Are tap targets at least as big as the WCAG 2.2 AA minimum, or covered by one of its exceptions?

Privacy and permissions

☐ Are permissions checked in suggestions, snippets, counts, and filters, not only when a record opens?

☐ Has someone who knows security reviewed our search?

Testing

☐ Have we tested with sample data and known answers, using different user roles?

☐ Do we read our search numbers alongside clear task goals, not on their own?

Where to start

If you can only do one thing this month, pick your most important "find one exact item" task. Write its Search Task Contract, then run the ten cases from the Search Failure Diagnostic Worksheet in a test account. That small exercise should show whether your problem is in matching, search area, how results look, or permissions. It also tells you who needs to be involved in the fix.

Some teams will find a few small issues they can fix in a week or two. Others will find that search problems are tangled up with menus, messy data, and complex workflows. If that's you and you'd like outside help, experienced UI/UX design support can help you plan and test a redesign across research, interface behavior, and complex product workflows.

Either way, the goal stays the same. Search works when people can finish what they came to do and trust the result, even when the answer is that nothing is there.

Shohanur Rahman

Founder & CEO

As the Founder and CEO of Orbix Studio, Shohanur Rahman brings over ten years of experience in UI/UX and product strategy. He is adept at aiding SaaS and AI startups in their growth journeys. His articles provide practical guidance for both founders and product designers.