Advanced Data Grid Filtering Framework

§1Context

vSphere Client is the interface enterprise infrastructure administrators use to run virtualized environments at scale. The people in this project managed anywhere from 30 to 25,000 virtual machines across clusters, hosts and datacenters.

Finding a specific subset of that inventory took precise, multi-condition queries the existing filtering could not express:

• no way to combine conditions within a single column
• filtering behaved differently from view to view
• tags, hardware version, snapshots and dates could not be filtered at all

Admins compensated by scanning lists by hand. Adding more filter options would not have fixed that. The work needed a standard operator model, clear rules for logical grouping, and the same behavior across the entire platform.

This was an architectural problem, not a visual one.

§2Role

A platform-level initiative across design, product and engineering. I covered the full design lifecycle: planning and running research with enterprise administrators, turning findings into interaction requirements, defining operator models per data type, prototyping every filtering state, and writing engineering-ready specifications.

Negotiating constraints with engineering was a core part of the job, not a side task. Framework limits shaped interaction decisions directly, and many of those decisions had to be proposed, defended and sometimes revised as technical feasibility became clearer.

§3Research

Two rounds with Senior VI Admins, Senior Engineers and Infrastructure Administrators working across multiple datacenters and vCenter instances.

What changed the framework

• Experts filter by precise conditions, not presets. They need queries like Name contains EUVM and does not contain PROD, Hardware Version 7 or 8, Snapshots between 2 and 8. Simplifying that into shortcuts would have broken their workflows.
• Logical grouping inside one column was a core requirement, not a nice-to-have.
• Consistency across views was a matter of trust. A filter that behaves differently on another screen is a filter nobody relies on.

The most requested filters were Name, State, Snapshot count, IP Address, OS Type, Hardware Version and Creator. Findings from both rounds changed architectural decisions, not just visual details.

§4Trade-offs

Three tensions shaped the direction.

Precision over simplicity

Time-based filtering was first explored with simplified preset ranges. Research made it clear that experienced administrators needed granular operator control. I kept the precision and restructured the interaction so that precision stayed navigable.

Grouped pills over flat pills

A grouped model shows one pill per column with all of its conditions. A flat model shows one pill per condition. Grouped won on scanability in a dense grid, and I accepted the cost: editing a single condition inside a group means opening the full filter dialog.

Ideal interaction versus framework limits

Some patterns that tested well could not be built on the platform as designed. Instead of workarounds, I adjusted the model to stay inside the constraints while keeping the core behavior.

§5Constraints

The existing data grid framework had structural limits that were not visible at the start. They surfaced one by one through engineering collaboration and touched logical grouping, operator compatibility across data types, filter state handling, and performance under high data volumes.

Every constraint ended in one of three decisions:

Constraint negotiation was not a blocker. It was a design activity.

Knowing what the framework could and could not support shaped the filtering model as much as user research did.

§6The framework

The outcome was not a filtering feature. It was a reusable framework with rules that hold across every view, so engineering could apply and extend it without design input for each new screen.

§7Try it

A working reconstruction of the model on a sample inventory. The behavior follows the framework; the visual design is mine for this site, because the product screens are under NDA.

§8Outcome

The first validation round tested the interaction model before the MVP. The second tested the deployed prototype against real administrative workflows.

• Administrators confirmed the grouped condition model matches how they think about filtering.
• Multiple conditions in one column, combined with filters on other columns, was named the biggest improvement over the old model.
• Admins who used to scan lists by hand described the new system as comprehensive for their use cases.
• After deployment the framework stayed stable under complex multi-condition queries in high-volume environments.
• It rolled out across platform views without view-specific adjustments, which validated a framework over a feature.

Saved filter sets, persistent column sorting and broader tag filtering were documented and scoped for post-MVP planning.

§9Reflection

This project moved my work from individual interactions to system-level behavior. Early on I solved each data type as it appeared. Switching to one framework, with operator logic formalized per type and a consistent interaction pattern, meant making decisions that had to hold in contexts that did not exist yet.

What I would do differently

• Define success criteria earlier. The qualitative signal was strong, but tracking time to create a filter, task completion and filter reuse would have shown impact over time.
• Build engineering relationships sooner. Critical technical information sometimes arrived through informal channels. Earlier, direct contact would have sped up constraint discovery.

The domain was enterprise infrastructure. The approach applies elsewhere.