

Case Study
Search Filters Overhaul
Helping business operatives find information faster by completely redefining a complex search & filtering experience.
Overview
THe PROBLEM
TIMELINE
6 months
TEAM
2 Junior UX/UI Designers
1 Frontend Developer
Product and Customer Services Stakeholders
TOOLS
Figma, FigJam, Figma AI, Maze, Zeplin, Heurio, Google Suite (Docs, Sheets), Jira, Confluence, Slack
MY ROLE
Lead UX/UI Designer
Solution Preview

Phase 1
Discover

Phase 1
Discover
Requirements & Scope
The Challenge:
The initial request was broad: “Overhaul the IA Search Filters UI.”
Because requirements were initially unclear, we focused on understanding the real user workflows to improve through:
Stakeholder interviews (Product, Services, Engineering)
Reviewing past customer feedback & interviews
Performing an audit of the current filters experience.
Researching competitors and filtering UX patterns.
The Final Requirements:
Reduce steps & time to add or edit search filters on the Assets page.
Faster & more flexible settings for categorical fields (i.e. Asset types, Groups, text attributes):
Quickly switch between: select all ←→ all except one ←→ multiple values
Support complex numerical filter settings:
Within a range (min < x < max)
Outside a range (min < x > max)
Equal to/Not equal to one value ( x = y or x ≠ y)
Ability to reset all fields individually.
Designs should be scalable for smooth migration on other IA pages.


Turning Interviews Into Insights
Interviews
To understand more about our target audience's core needs, goals, and pain-points with searching and filtering within IA, we interviewed three Services Engineers from our internal team, since they had direct insights on our customers. It's worth noting that our Services team members were also a core IA user group themselves, since they are often the ones setting up and customizing systems on behalf of our enterprise customers.
We were unable to schedule direct interviews with customers for this project. So instead, we reviewed our past user interviews and survey data for relevant quotes and insights about our target users.
Users avoid using certain filters due to complexity or insufficient context.
Users are requesting multi-selection & “select all” in categorical fields
Users avoid using certain filters due to complexity or insufficient context.
Heuristic Analysis
Heuristic Analysis
Next, we audited the Assets page's existing filters menu to understand the current gaps and usability issues, and identify potential opportunities for improvement.
Key Issues:
Unintuitive settings form patterns for location filtering.
True/false (boolean) filters lacked a neutral "all" state.
Numeric filters only allowed rigid min/max inputs.
Too much clicking – Each field was hidden under expansion panels and had to be opened one-by-one.
Unclear which fields were active when drawers were closed.
Could only select one value for categorical/text fields.
Filters menu was not optimized for mobile.

Competitor Analysis


We took to the web to find direct and indirect competitors to take inspiration from for ideating our new filters menu.
Phase 2
Define
User Personas
Next, we translated our research insights into user personas. They represented the core user roles and archetypes that made up a majority of our target audience. We identified two primary user archetypes:
The admins: Sara, Remote Operations Supervisor
The power-users: Mike, On-Site Maintainer
Across both personas, certain key needs & goals emerged:
Combine multiple types of filters to narrow results.
Continually adjust filter settings on-the-fly.
Customizable data views.
Information > Simplicity (These users were used to dense enterprise views. The more info they can see on one screen, the better).

Information Architecture
The old filters menu didn't provide much context as to which asset types an attribute filter belonged to, which especially became a problem when there were dozens or even up to a hundred different filter fields that could appear in the Asset filters menu (most of which were for custom data attributes on asset types). We diagrammed the information architecture of the Assets page (and its associated filterable data) to help our team–and our stakeholders–visualize the relationships better. Our plan was to match the Assets filters menu's information architecture to its real underlying data structure.

Breaking Things Down:
Filter Data Types
Although a Assets page filters menu could contain up to hundreds of fields to filter on, we were able to simplify the problem by defining the core data types rather than looking at each field as a totally unique UI component. This allowed several fields to be presented as one of a few possible UI components based on their underlying data type:
Text (categorical)
Number (continuous values)
Boolean (true/false)
Date & time
Location
This approach helped reduce design and engineering complexity while ensuring consistency for users.

User Flows for Each Data Type
For each data type, we mapped all the posssible flows and component states that we would need to account for in the final designs, so as to ensure 1. All core business requirements were being met for each filter field, and 2. Users wouldn't find themselves stuck or unable to perform certain functions while interacting with a particular filter field.

Phase 3
Ideate

Our Ideation Process
Designing a complex feature required a lot of rapid iteration and constant collaboration across teams. These were the essential parts of our workflow during the ideation phase:
Collaborative design exploration
Our design team generated multiple concepts for each workflow, running critiques to evaluate tradeoffs and refine the strongest ideas.
Check-ins with Engineering
We regularly consulted with the developer to validate feasibility and re-think solutions when the code complexity outweighed the predicted UX value.
Cross-functional design reviews
Monthly UX reviews brought together engineering, sales, services, and leadership to gather feedback and align on key design directions. These discussions occasionally led to conversations with customers for deeper validation.
Design Iterations
We went through several rounds of iterations throughout the project. Below are some highlights of core aspects of our designs that changed during these many rounds.
Phase 4
Preparing the User Test
Remote usability testing:
Next, it was time to validate our designs. Firstly, we wanted to make sure users could complete the core tasks that were outlined in our MVP business requirements. Secondly, we wanted to confirm that the new filters menu design was, in fact, easier and faster to use than the original menu.
Preparing the user test:
We drafted our test plan & script in Confluence. We made sure our highest-priority research objectives and questions were directly based on our MVP business requirements.
We used Excel & Figma plug-ins to quickly populate realistic data into our clickable prototypes
We created our remote test blocks in Maze. The usability test also included a post-test survey Total participants = 11
Limitations: due to limited resources (mainly in terms of time and participant availability), we focused on the highest-priority goals:
We only tested a subset of all of the features we had designed: entry-point, adding custom attribute filters, editing existing filters, clearing filters,
and we only prototyped the desktop version of our redesign, not the mobile (Based on our Google Analytics data, 75% of our users used Intelligent Assets on a laptop or desktop device).
User Testing Results:
Notable User Feedback:
“I’m questioning whether the ‘Groups’ and ‘Type’ chips should always be visible [in the “active filters” row]. It seems like you’d just want nothing visible if no filters are applied. → Created duplicate paths for the same tasks → Made it more complex than it needed to be?”
A user may not know “Attributes” means asset attributes. Perhaps add an option to filter by column title?
Outcome: We opted to keep the “Attributes” as its own sub-page, in order to reduce excess complexity when we eventually added an “Event filters” sub-page too.
Main Takeaways:
Too many entry-points for editing filters.
Overly complex UI
Users confused by the numerical filter field - likely over-designed. A slider for a numerical filter doesn’t allow for a lot of other filter combos. Maybe just do operator + value field instead.
Results Summary
Average SUS score = 86.36
6 out of 11 users struggled to find the entry-point to the filters menu. Tried to look on the right-hand side first.
5 out of 11 users had trouble understanding how to add a numerical filter.
Post-testing Revisions
Post-testing Changes:
Simplified the numerical filters UI.
Removed the default quick-filter chips from the filters summary row.
Moved the filters entry-point to the right side of the search field.
Saved for Later:
Adding a "search" field on the Filters main menu page.
Phase 5
Deliver

Preparing the design handoff
Handoff Process
We aligned our design work to the developer’s build order by discussing implementation sequencing early, then planning design sprints to deliver the right screens ahead of development.
Divided handoffs into phases for faster delivery.
Consistent naming conventions for all layers and components in Figma.
Thorough UI copy documentation to support consistency and scalability.
Result
Smoother handoff, fewer clarifications, and designs that supported efficient implementation.
Design System & Accessibility
Expanded upon the base Material Design system by creating new custom components.
Refined interaction states and edge cases (error, empty, disabled) to improve usability and consistency
Advocated for accessibility improvements within shared components
Post-dev Q.A.
We used Heurio to conduct post-development QA, verifying alignment with design intent. Feedback was prioritized from "Neutral" to "Critical" so devs know which items to fix first.
What we checked:
1. Ensure all core business requirements were met.
2. Responsiveness at all breakpoints
3. Ensure all filter field types behave as expected.
4. Accessibility (in light and dark mode)

Reflections & Next Steps

Post-dev Q.A.
We used Heurio to conduct post-development QA, verifying alignment with design intent. Feedback was prioritized from "Neutral" to "Critical" so devs know which items to fix first.
What we checked:
1. Ensure all core business requirements were met.
2. Responsiveness at all breakpoints
3. Ensure all filter field types behave as expected.
4. Accessibility (in light and dark mode)
Overview
Insight 1
Users avoid using certain filters due to complexity or insufficient context.
Insight 2
Users are requesting multi-selection & “select all” in categorical fields
Insight 3
Users want to use the search bar as an immediate way to filter
Insight 4
Main goal: Identify assets with abnormal data before things escalate.















