Building a Complex Data Filter That Is Accessible + Friendly
Project Context
Zengine's online database environment had a global filter tool that allowed you to display a pre-set view of workspace data based on particular conditions. This filter only worked with the platform's data grid and permissions, but as the product grew — and both Submission and Review Portals introduced — the filtering tool was a suboptimal experience and didn't have the capabilities to handle complex sets of data across forms and locations.
Problems to Solve
In many ways, the extensibility of the product made its filter obsolete over time. With the creation of its application-based portal solutions, Zengine was able to handle shared linked data across multiple forms — even complex relationships throughout data hierarchies. However, the filter was unable to match the portal's requests with accuracy.
Customer Feedback
The majority of negative feedback around the filter originated from clients without request, but we wanted to confirm this was an issue with a larger user audience. I created a simple survey about customer's experience using the filter tool to try an illicit some volunteers to expand off of their pain points. The response was overwhelming. I set up a dozen one-on-one interviews with a variety of responding customers, and collected their feedback, categorizing it into common reactions. Some of the most significant pain points included:
The filter is not accessible with screen readers or other assistive technology.
The UX of the filter is clunky, confusing, and unintuitive.
The filter panel leverages multiple scrolling sections, which makes it challenging to manage.
The filter only allows me to filter a single criterion at a time and doesn't allow for nested or a hierarchy of related filters.
There is a huge visual disconnect between the criteria in the lefthand panel and the conditions on the right panel.
I had issues with the filter and wanted to reimagine it since I joined the team — I considered the overall experience to be a UX nightmare, and the UI to be unnecessarily confusing. The customer feedback reinforced my concerns and encouraged a complete overhaul of the tool for the sake of the customers and the platform.
Reimagined
I immediately started having product team brainstorming sessions around how we could better approach the filter panel and maximize our platform technology. We deconstructed the existing filter through daily whiteboarding sessions and separated them into essential parts. Then we focussed on making the experience a top-down, linear UI that never hid anything you were trying to filter — everything was exposed, clear, and accessible.
We needed to expand the filter to account for data more than just the data grid — we needed to introduce them into field rules and summary fields, in particular, to work in conjunction with the portal-used data.
Filtering had to be achievable across multiple forms in multiple places, and we needed to accommodate some complex scenarios of nesting, so we created the concept of "groups" to be flexible enough to handle large numbers of filtering combinations and conditions at once.
Error Handling + Conditions
The filter panel was vague when it came to error handling. When a filter encountered an issue — perhaps a form was deleted, or a record was changed that would have an impact on an existing set filter — error messaging never achieved a state of helpful explanation, nor did it offer up any possible solutions. We created a matrix of possible error scenarios and added that to the overall UI to keep users informed and provide them with inline options. We also expanded the available conditions the filter could utilize, creating a more focused and inclusive experience for the user.
Prototyping
Once we had a focused feature set for the new filter, I designed the UI and put together an initial prototype that would allow a user to create a filter (but didn't filter anything). I wanted to first gather feedback on my inline filter construction paradigm, especially with complex nesting. I shared the prototype with both internal teams and with our customer advisory board. The only common pain point was around the nesting, which I streamlined through the addition of guides to establish visual alignment and prevent disconnect. Feedback on the tweaks was favorable.
Accessibility
Accessibility was a considerable concern that the current filter had not addressed. With the portals, I had made a strategic push to become more conscious of our varied users and make the platform a suitable environment for people with disabilities or impairments, adhering to best practices and accessibility standards. I needed to do the same with the filter panel. I worked closely with my development team to verify that the new filter panel was compatible with assistive technology standards and 508 compliant. We tested this internally but were also fortunate to have the opportunity to share this with some visually impaired testers, who ran the filter through its paces with great success.
Release
Since practically every platform user leveraged filters in some way, we needed to be transparent in our communications before release. It was critical that customers were made aware of the filter changes early on, and be given a substantial window of opportunity to ramp up their product learning on this new feature. I worked closely with the support, marketing, and implementation teams to create a plan of action to address the upcoming release with clear and concise messaging and additional knowledge base resources at their disposal. We had an open feedback forum (structures/presented akin to an AMA session) with interested customers who had questions and concerns, giving them a voice in the overall filter trajectory and allowing our team to levelest expectations. Customers showed little apprehension to the upcoming change and showed more excitement and relief than initially anticipated.
We reached out to several customers post-release to gather feedback on their experiences with the filter, and found positive responses all around.