Designing a Dynamic Filtering System for a Large-Scale QA Workspace

Executions Tab _ Filters – selected

Overview

This case study focuses on the filtering system designed for the Executions workspace inside a distributed QA platform used to manage large-scale test executions across projects, devices, workflows, releases, and localization environments.

The core challenge was not simply “adding filters.”

The real problem was designing a filtering experience that could scale with:

  • hundreds or thousands of executions,
  • many independent filter categories,
  • constantly changing datasets,
  • dense enterprise tables,
  • and limited horizontal space.

The goal was to create a filtering system that felt lightweight despite the complexity underneath.

The Problem

The original interface treated filtering as a secondary utility placed above the table.

That approach created several issues:

  • filters competed visually with table controls,
  • the header area became overloaded,
  • advanced filtering required too many interactions,
  • and selected filters disappeared into the UI instead of becoming part of the workspace context.

At the same time, the table itself was the primary workspace.

The filters needed to support the table — not dominate it.

Design Goals

The redesigned filtering system focused on five principles:

1. Keep the table visible at all times

The table is the product.

Users constantly scan statuses, workflows, projects, and devices.
Opening filters should never remove the table from context.

Instead of fullscreen filtering, I introduced a side panel that overlays only part of the workspace.

This preserves spatial orientation and reduces cognitive interruption.

2. Separate quick filtering from advanced filtering

Not every interaction deserves a full filter drawer.

To support rapid workflows, I introduced:

  • lightweight quick filters,
  • persistent filter chips,
  • and a dedicated advanced filter panel.

This creates two layers of filtering:

  • fast operational filtering,
  • and structured contextual filtering. 

3. Make filters progressive

Enterprise systems often overwhelm users by exposing every possible filter immediately.

Instead, the filtering panel starts with only a few primary sections:

  • Status
  • Project
  • Workflow

Additional filters are added intentionally through:
“Add Filter”

This reduces visual noise while keeping the system scalable.

4. Reflect system dependencies dynamically

Some filters depend on other filters.

For example:
Release options should not exist independently from Projects.

The system dynamically changes available releases depending on selected projects.

If no project is selected:

  • the Release section remains empty,
  • and contextual guidance appears instead.

This prevents invalid filtering states and reduces user confusion.

5. Turn filters into visible workspace context

Selected filters appear as chips directly inside the top workspace bar.

This changes filtering from:
“hidden configuration”

into:
“active workspace state.”

Users can instantly understand:

  • what they are looking at,
  • why the table changed,
  • and which filters are currently active.

 

The Solution

The final solution consists of three connected layers.

1. Quick Filter Layer

The top workspace bar contains:

  • refresh controls,
  • execution summaries,
  • quick actions,
  • active filter chips.

Selected filters appear as removable chips directly above the table.

Examples:

  • Failed
  • Blocked
  • Titan Protocol
  • Crimson Horizon

This creates immediate visibility without opening the filter drawer.

Executions Tab | Filters – selected – hover quick

2. Dynamic Filter Drawer

The advanced filter system opens as a right-side contextual panel.

The drawer:

  • preserves table visibility,
  • supports scalable filtering,
  • and allows progressive disclosure.

Each filter category behaves as an expandable section with:

  • dynamic counters,
  • collapsible content,
  • checkbox selection,
  • contextual states.

Example:

Project (4)
Workflow (6)
Release (0)

The counts immediately communicate filtering complexity.

 3. Progressive Filter Builder

Instead of exposing every possible filter immediately, users can add filters dynamically.

The “Add Filter” action opens a structured list of optional filter categories:

  • Execution type
  • Device
  • Language
  • Release
  • Revision
  • Owner
  • Finished on

This allows the workspace to remain compact while still supporting advanced operational workflows.

add-filter-dropdown

Key UX Decisions

Persistent table visibility

One of the most important decisions was preserving visibility of the execution table while filtering.

In enterprise systems, losing context is expensive.

Users constantly compare:

  • statuses,
  • workflows,
  • projects,
  • and ownership.

The side drawer avoids disruptive context switching.

Dynamic dependency logic

Release filtering depends on project selection.

Without project context, releases become meaningless and noisy.

Instead of displaying empty dropdowns or invalid options, the UI communicates dependency clearly:
“Select project first.”

This reduces errors and improves learnability.

Filter chips as operational memory

The chip system acts as lightweight operational memory.

Instead of forcing users to reopen filters repeatedly, the current workspace state stays visible at all times.

This becomes especially valuable in large QA environments where users switch between multiple filtered contexts rapidly.

Reduced header overload

Earlier versions overloaded the header with:

  • filters,
  • entries controls,
  • refresh settings,
  • and summary information.

The redesign redistributed responsibilities:

  • table controls moved near pagination,
  • filtering moved into a contextual layer,
  • workspace summary remained visible.

This created stronger hierarchy and better scanability. 

Interaction Design

The filtering experience supports:

  • hover states,
  • expandable sections,
  • removable chips,
  • dynamic counters,
  • disabled states,
  • contextual guidance,
  • and scalable progressive filtering.

The system was designed around minimizing unnecessary clicks while still supporting complex workflows.

Prototype

A clickable prototype of the filtering flow was created in Figma to demonstrate:

  • drawer behavior,
  • progressive filters,
  • chip generation,
  • dynamic dependencies,
  • and contextual states.

Outcome

The redesigned filtering system transformed the Executions workspace from a dense enterprise table into a scalable operational environment.

The final solution:

  • reduced header complexity,
  • improved contextual awareness,
  • supported progressive workflows,
  • and created a filtering experience that scales with large datasets without overwhelming users.

Most importantly, the filters became part of the workspace itself — not a disconnected utility hidden somewhere above the table.

© Zofia Szuca 2024
Brand and product designer