Figure out a new design pattern that could meet the needs of Bot Defense users but also be applicable to other workspaces in the console.

Support sharing, saving, and reusing a set of filters created by all users in the same tenant to smoother the communication between our TAMs and clients, as well as the communication between security engineers of our clients.

Save filters (including logic for saving and saving as).

Constructing new design patterns.

Iterating on the information architecture design to accommodate the new feature and collaborating with the design system (DS) team to gather feedback and gain a broader perspective for making more comprehensive design decisions.

Apply, adjust, and save as a new one.

There was no existing component that could accommodate the new functionality, so we needed to propose a new one that could meet the needs of Bot Defense and apply to other workspaces in the console. I explored the idea of utilizing “filter icon” or “more action icon” as a control to show a dropdown menu, and with SMEs’ feedback of wanting to know which filter is currently applied, explored presenting the saved filter name with status on the first layer. In the second iteration, I moved the “Saved Filters” control to the first layer to make it stand out and easier to access, made the “Save” feature more dominant, and later figured out a way to show all key controls in the first layer, in a more concise way. I also added new functionalities, including the “Return to Previous Status” control and the “Restore Defaults” control to make the feature more user-friendly. The “save filter” logic was also polished – only allow owners and admins to save (update) after editing a saved filter. Others could only “save as” a new one.

Besides, I explored different information architecture design for the filter feature, and the visual treatments for the edited part of a saved filter. After consulting with the DS team, I realized it was a significant change that required more thinking and would take a long time, which would delay the release time. It might also not be able to be implemented in other workspaces simultaneously with the implementation of this project, which may lead to an inconsistency issue. Therefore, we did not go with this option for phase one.

During the exploration, I gained a deep understanding that although I was working on and responsible for Bot Defense, I was also accountable for other workspaces. Thus, I kept this in mind and actively communicated with my PM to ensure we remained aligned. This concept also shaped my decision to involve the design system team in the feedback collection process and to approach design decisions from a more systematic perspective.

Since filters could not be reused and used by others, and there was no option to delete expired filters, we aimed to develop a feature to address the issues, which information presentation and control required exploration. Some initial ideas I had included: presenting a saved filter list with an apply, a share by copy URL, and a delete control. In each page, only presenting the filters that could be applied to that page. Regarding filter naming rules, allowing any characters (no input restriction), and allowing a name to be used only once in the same namespace (clients' user segmentation). Later with SMEs' feedback, I added a "Description" column to allow users to articulate the purposes of the filter set, and added a “Created by” column as a reference.

I also explored different ideas, such as allowing access to saved filters in different pages through a dropdown menu, viewing all filter values in an accordion, dividing filters into “My Filters” & “Others” to support efficient navigation and access, and presenting a delete feature in a side modeless or a management page. Eventually, we moved forward with a pattern that aligned with the design system and better met user needs.

The system only retained data in the past 30 days, so we needed to figure out a way to tackle the situation when the data was no longer available owing to the outdated time frame, either the whole or part of the time expiration causes the whole or part of the data missing. There were two types of time selection: generic (e.g., past X days), and custom (where users could pick a range in the past 30 days). My initial idea for treatments was that for the filters with a generic time frame, we kept it the same. It would never expire. We would allow users to apply and show the corresponding results. As for the filters with a custom time frame, when the partial or whole timeframe was out of 30 days, we would make the filter disabled without showing the apply or copy control. I also utilized a warning icon to present time expiration messages to users in the filter list view, but I later realized that it required API call. We were unable to know if the time had expired or not right at this moment. Therefore, we eventually presented the message in the detail view instead, and planned to consider the edit feature in phase two.

The filter keys and values were naturally dynamic. They would change based on configuration. It was possible that a filter had been saved, but later some configurations changed, causing part of the filter keys and values to no longer exist. We needed to figure out a treatment for this situation and convey it to users. My initial idea was to either automatically remove the non-existent filter keys and values, and inform users that those values were no longer available, or disable the entire filter set and notify users that the filters could not be applied by displaying messages in the filter list view. Because the proposal could not work due to API call constraints, I ideated other solutions, such as in both the result page and each filter detail view, indicating which exact values were missing. I later realized it was not possible to identify exactly which part was missing without making an additional API call, which would negatively impact system performance.

Next, I explored the idea of giving users two options: applying the original ones and showing the corresponding results, or applying and omitting the missing values in the filter set. I learned from the development team that in the result page, the missing values would be presented, but they were not applied. We were unable to automatically remove the display of missing values from the result page. Eventually, we utilized a disclaimer as a workaround to address API limitations.

In some situations, the system could not present the updated view, so users might accidentally apply a deleted saved filter. (E.g., When a saved filter got removed from UserA side, but UserB has the saved filter detail view open and has not refreshed to get the updated list yet, it is possible that UserB "apply" or "copy the URL" of a deleted saved filter.) I listed down all the scenarios we needed to address first, and started to ideate potential solutions. My initial thought was showing some error messages when users applied a deleted saved filter, and automatically refreshing the page for them. After syncing up with developers, I realized that the system did not know the filter had been deleted when it was applied. It required an extra API call to check it, which would lead to a legacy issue.

Then we collaboratively proposed a new solution: making an API call after a filter is applied to check whether the associated saved filter still exists. If it has been deleted, we would display a message prompting users to refresh the page to get the most up-to-date view. If users chooses not to refresh, but modifies some filter values and attempts to save, the “Update Saved Filters” button would be hidden, while the option to “Save As” a new filter would remain available. Building on the feasible idea, we refined and iterated it, eventually arriving at an alternative version that could be more intuitive and user-friendly: If users are only viewing the page and make no changes, no reaction or message needs to be shown. If users make edits and attempt to update the filter, we display a message informing them that the saved filter no longer exists and suggest using “Save As” to proceed. If users access a page via a URL tied to a deleted saved filter, we still present the filtered view, treating the filters as newly added. We would also show a message to inform users, and they have the option to save the filters as a new one.

In F5XC, users can filter and narrow down the data displayed in dashboards and reports. These filters can be saved for future use, enabling users to quickly revisit specific views. When saving a filter, users can assign a name and description for easier access and reference later on.

The name of the currently applied filter is displayed in the saved filter access control. Once a filter is saved, its status is updated accordingly. Users can use the dropdown menu to access previously saved filters. By clicking "View More Details," they can view additional information about filters, including their own, those created by others, and any that have expired due to the system’s data retention policy. Users can also copy the URL to share or apply filters directly from this page.

Users can edit and update their previously saved filters. If a filter was created by the user, they have the option to either update the existing filter or save the changes as a new one.

Users can also use the Saved Filters Management page to access all filters across pages within the same tenant and namespace. Filters that reference a custom time range beyond the past 30 days may produce inaccurate results and cannot be reapplied. Users can delete their own filters, while admins have the authority to delete any saved filters to help clean up outdated or unused entries in the system.