Problem
There are nine hundred thousand events and the viewer cares about the production ones, from the checkout service, in the last hour, that failed. Four narrowings, and after applying them they need to be able to see at a glance which four they applied.
Solution
A persistent row of controls above the content, each narrowing the set, with every active filter visible as a removable chip. The state is the bar; the content is a consequence.
Two properties do nearly all the work, and both are about visibility rather than about filtering.
Applied filters must be legible without opening anything. A dropdown that says “Service” when three services are selected has hidden the thing that determines what is on screen. Chips showing service: checkout are longer and correct. This is Nielsen’s first heuristic applied to state rather than to progress: the person has to be able to see what the system is currently doing.
Removal must be as cheap as application. Filtering is exploratory, and exploration means overshooting. One click to add and three to remove produces viewers who stop narrowing.
Beyond that, the interesting design questions are about the filter values themselves. Should the bar show only values that exist in the current set, and update as filters are applied? Doing so prevents dead ends where a viewer selects a combination that matches nothing. Not doing so is much cheaper to build, and is why so many filter bars let you construct an empty result and then leave you wondering which choice caused it.
Grafana’s approach is worth studying because it is structurally different: variables are declared on the dashboard, populated by their own queries, and referenced inside panel queries, with the selection carried in the URL. That makes filtering explicit, shareable and chainable—one variable’s options can depend on another’s selection—at the cost of every filter being something an author had to build in advance.
Use when
The population is large, several attributes matter, and different viewers narrow differently. Any triage surface.
Don’t use when
There is one dimension and few values. Three tabs beat a filter bar with one dropdown. Also avoid a filter bar as the only way in: a page whose default state is unfiltered and unusable has pushed its information architecture onto the viewer.
Trade-offs
Filter bars accumulate. Every new attribute someone wants is one more control, and a twelve-control bar is a form. State becomes invisible in screenshots, so a filtered dashboard shared into a channel is routinely misread. Filters can conflict with each other in ways only discoverable by hitting an empty result. And a bar that persists filters across sessions will eventually greet someone with yesterday’s narrowing and no memory of having set it, which is the most confusing five minutes a dashboard can produce.
Checklist
- Can a viewer see every applied filter without opening a control?
- Is removing a filter as cheap as adding one, and is there a clear-all?
- Do the offered values reflect the current set, or can a viewer construct an empty result?
- If the result is empty, does the page say which filter caused it?
- Does the filter state go into the URL?
- Do filters persist across sessions, and does the viewer know?
- Can filters be chained, so one narrows the options of the next?
- How many controls before this stops being a bar and becomes a form?
- Does everything on the page honour the filters, and do exceptions say so?
- Does a screenshot of this page carry enough to be read correctly?
Compare
Grafana makes filters a declared object rather than an ad-hoc control: template variables are defined on the dashboard, populated by queries, chained so one constrains the next, and carried in the URL, which makes state shareable and every filter something someone had to anticipate. Honeycomb puts a query builder where the bar would be, so narrowing is composing a query and there is no fixed set of filterable attributes—the cost is a higher floor for a casual viewer. Sentry uses a single search field with a tag syntax, trading discoverability for speed once learned, and softens it with autocomplete over real tag values. Datadog scopes a whole page by tags from one control, so filters apply uniformly across every widget by construction rather than by each panel remembering to honour them.
Related
Template variable is Grafana’s implementation of this and the entry that covers the chained-variable case. Cross-filter is the gestural alternative that narrows by selecting rather than by choosing. Search across panels covers free-text narrowing. Saved view is how a useful set of filters stops being retyped. Ranked list is what usually sits underneath and only means something once the population is narrowed.