| UI or UX | UI + UX - Filter and results exploration surface | UI + UX - Search recovery state |
| UI guidance | Render filter controls, active chips, counts, result list, clear controls, and no-results state. | Render zero-result copy, active criteria, remove-filter actions, and alternative suggestions. |
| UX guidance | Help users progressively narrow a large result set without losing orientation. | Help users recover when their own search or filters excluded all results. |
| Good UI | Facet groups, counts, selected chips, result count, and clear controls are visually grouped. | Zero-result state shows query/filters, result count, and clear or broaden actions. |
| Bad UI | Facet panel overwhelms the results with dense unchecked options. | No results text alone with no criteria shown. |
| Good UX | Users can add, remove, combine, and clear facets while understanding result count changes. | Users can remove one filter, clear all, edit query, or try suggested alternatives. |
| Bad UX | Changing filters resets unrelated query or sort silently. | Telling users nothing exists when filters caused the state. |
| Best fit | The data set has structured attributes users understand. | Search, browse, or filter controls can produce an empty result set. |
| Avoid when | The result set is small enough that filtering adds complexity. | There is genuinely no possible next action and the system should instead explain availability. |
| Required state | Unfiltered state with result count and available facets. | Zero-result state that preserves the user's criteria. |
| Accessibility burden | Applied filters should be announced and removable without pointer-only interaction. | Announce result-count changes where search results update dynamically. |
| Common misuse | Using internal database labels as facets. | Showing a blank list with no explanation. |