Back to all ArticlesMost enterprise filtering systems are designed like side features.
A few dropdowns.
Some checkboxes.
Maybe a search input.
And then suddenly the product grows.
More projects.
More workflows.
More devices.
More releases.
More execution types.
At some point, the filtering system stops supporting the workspace and starts fighting it.
That was exactly the challenge behind redesigning the filtering experience for the Executions workspace inside a distributed QA platform.
The Real Problem Was Not the Table
At first glance, the issue looked simple:
“Improve the table UX.”
But after analyzing the workspace structure, the real bottleneck became obvious.
The problem was not the data itself.
It was the relationship between:
- the table,
- filters,
- workspace context,
- and operational workflows.
The original layout mixed:
- filtering,
- refresh logic,
- execution summaries,
- table settings,
- and quick actions
inside a single overloaded header.
Everything competed for attention.
In enterprise systems, this becomes dangerous very quickly because users spend hours inside these interfaces. Tiny inefficiencies scale into cognitive fatigue.
Enterprise Tables Need Context Preservation
One of the biggest UX mistakes in data-heavy systems is removing the user from context during filtering.
Fullscreen modals.
Massive dropdowns.
Aggressive overlays.
All of these interrupt workflow continuity.
Instead of replacing the workspace, I redesigned filtering as a contextual side panel that keeps the table visible at all times.
This sounds small.
It is not.
Because users constantly compare:
- statuses,
- workflows,
- projects,
- ownership,
- releases,
- and execution states
while filtering.
The table itself is the product.
The filters exist to support it.
Progressive Filtering Instead of “Everything Everywhere”
Another major problem with enterprise systems is overexposure.
Designers often try to solve scalability by displaying every possible filter immediately.
The result usually looks like airplane cockpit UI.
Instead, I introduced progressive filtering.
Initially visible:
- Status
- Project
- Workflow
Additional filters are added intentionally through:
“Add Filter.”
This keeps the workspace clean while still supporting advanced operational workflows.
The system scales without visually collapsing under its own complexity.
Dynamic Dependencies Matter More Than People Think
One of the most important interaction details was dependency logic between filters.
Example:
Releases depend on Projects.
Without project context, release filtering becomes meaningless noise.
Instead of showing invalid options or empty dropdowns, the UI communicates dependency directly:
“Select project first.”
Good enterprise UX is often about removing invalid states before users even encounter them.
Not explaining mistakes afterward.
Filters Became Part of the Workspace
One of my favorite parts of this redesign was transforming filters into persistent workspace context.
Selected filters appear as removable chips directly inside the workspace header.
This changes the mental model completely.
Instead of:
“I opened filters.”
The experience becomes:
“This is my current operational view.”
Users no longer need to repeatedly reopen filter drawers just to understand why the table changed.
That dramatically improves orientation inside large datasets.
Designing for Real Operational Workflows
This project was not about visual redesign for the sake of aesthetics.
It was about designing for:
- scalability,
- operational speed,
- cognitive clarity,
- and long-session usability.
The final system combines:
- contextual filtering,
- progressive disclosure,
- dynamic dependencies,
- persistent workspace chips,
- scalable table interactions,
- and reduced header overload.
Exactly the kind of UX problems I enjoy solving most.
Full Case Study
I documented the complete redesign process, interaction decisions, and filtering architecture here:
