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.

Enable users within the same tenant to save, share, and reuse filters, making collaboration between TAMs and clients much smoother.

Saving filters, including both “save” and “save as” logic.

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 to ensure alignment and scalability.

Enabling users to apply, adjust, and save filters as new versions.

My exploration began with using the filter icon or the “more actions” control to trigger a dropdown menu. During iteration, I realized users could already share filtered views simply by copying the browser URL, so a dedicated “copy to share” action wasn’t essential. I also received feedback that users wanted clearer visibility of which filter was currently applied, so I explored surfacing the applied filter name and status directly in the first layer of the UI, and continued the action control iteration. I also reduced the steps required to access saved filters by introducing a dropdown that displayed filters available for the current page. In parallel, I refined the save logic with role-based permissions – only filter owners and admins could update an existing saved filter after editing, while other users could only “save as” a new version.

I later explored alternative information architectures for the filter feature, along with different visual treatments for edited saved filters. However, after consulting with the DS team, I realized the change would have a much broader impact than expected. It required deeper exploration, which would significantly delay the release timeline, and likely couldn’t be rolled out consistently across other XC workspaces at the same time. This would create potential inconsistencies in the platform experience. As a result, we decided not to pursue this direction for phase one, though it remained a strong candidate for future phases or a dedicated design system initiative.

This experience also reinforced an important mindset for me: although I was directly responsible for Bot Defense, my design decisions also impacted the broader XC ecosystem. I proactively aligned with my PM on the importance of designing beyond a single workspace, which further shaped my approach of involving the DS team early and making decisions from a more scalable, system-level perspective.

Continuing the exploration, I moved the “Saved Filters” control into the first layer to make the feature more visible and easier to access, while also giving the “Save” action greater prominence. I also explored consolidating the “Update” action with filter access interactions, and placing the “Save Filter” and filter access controls closer together to strengthen their relationship and improve usability. To maintain consistency with other XC workspaces, I additionally explored using the “More” menu to house actions such as “Show/Hide Filters.” Eventually, we found a way to surface all key controls within the first layer in a cleaner and more concise layout. To make the experience more user-friendly, I also introduced new actions such as “Return to Previous Status” and “Restore Defaults.” Based on feedback from other designers, I categorized saved filters into “My Filters” and “Others” to improve discoverability and browsing efficiency.

At the same time, I refined the underlying logic with the PM and SMEs: Users within the same tenant could access shared saved filters. The namespace-based data isolation was preserved to respect separation across business units. In addition, each dashboard or report page would only display filters relevant to that specific context, helping users stay focused on their current workflow.

To support this workflow, I introduced a side modal in each dashboard and report page to present saved filters. The list was context-aware — showing only filters that could be applied to the current page — helping users stay focused and reducing unnecessary noise. During iteration, I added a “Description” field so users could provide context and quickly understand the purpose of each saved filter. I also introduced a “Created by” column, since saved filters were visible to all users within the same tenant.

I explored multiple approaches for information architecture and interaction design along the way. One idea was enabling cross-page filter access through a dropdown menu. It was suggested during a design review. However, after aligning with the PM and SMEs, I realized users rarely needed to switch pages in that moment, and the interaction also conflicted with design system guidelines, so we decided not to pursue it. I also iterated on how users could view complete filter values. I initially explored accordions, but the component was being phased out due to long-scroll usability issues elsewhere in the system. I then tested hover-based previews, but that conflicted with existing tooltip usage for truncated names. Eventually, I introduced a click-to-view detail pattern using a multi-layer modeless experience, allowing users to focus on filter details such as the name, description, and full filter values. In parallel, I tested multiple layout and learned through SME feedback that a wider layout was preferred because it could accommodate more content more effectively. Finally, I organized filters into “My Filters,” “Others,” and “Expired” categories to improve navigation and easier access.

For the filter apply interaction, my initial design used the filter name itself as a hyperlink to apply the filter. However, this pattern did not align with our design system guidelines, so I revised the interaction by introducing a dedicated “Apply” button within the actions column of the table.

There was also active discussion around the sharing experience. Although users could technically share a filtered view by copying the browser URL, the workflow wasn’t very intuitive or convenient.  I advocated for a dedicated “Copy to Share” action using existing components and moved it into the first layer to make sharing faster and more discoverable.

As more controls moved into the first layer, I realized the interface was becoming visually crowded. To simplify the experience and support future scalability, I moved deletion into a centralized Management page where users could view and manage all filters across pages within the same tenant. In later iterations, I also refined the deletion logic: Users could only delete their own filters, while admins had permission to delete any saved filter.

As the iteration progressed, I further refined the filter access and application logic. Saved filters were scoped to their dedicated namespaces to respect data isolation across different business units,  and shared URLs would preserve the associated namespace context. I also polished several interaction details — renaming the feature to “Saved Filters” to make it more intuitive, updating action placements to align with the latest design system patterns, and adding bulk deletion to help users manage multiple filters more efficiently. To prevent conflicts and confusion, I decided not to allow multiple saved filters to be applied simultaneously on the same page. I also explored adding distinct visual treatments for the currently applied filter, but implementing that required additional API support, so it was deferred beyond phase one.

Another major area I pushed on was naming flexibility. I advocated for removing unnecessary input restrictions and allowing users to include uppercase letters, spaces, and special characters in filter names. Initially, the Bot Defense engineering team pushed back due to technical constraints and prioritization concerns. However, when other XC product teams later adopted the feature and supported the change, I used that momentum to drive alignment back into Bot Defense. In the end, we established a more user-friendly naming system while maintaining uniqueness by allowing each filter name to be used only once within the same namespace.

My initial proposal handled these two cases differently: For generic timeframes, I treated them as dynamic and reusable — for example, “Past 7 Days” would always represent the latest rolling seven-day window, so these filters would never expire and could always be reapplied. For custom time ranges, the situation was more complex. If part or all of the selected timeframe fell outside the 30-day retention window, the filter could return incomplete or invalid results. To prevent users from being misled, my initial approach was to disable those expired filters entirely, including their apply and copy actions.

Based on that logic, my initial design used warning icons with tooltip in the filter list to indicate expired timeframes. However, during iteration, I realized this approach relied on real-time API calls, and we couldn’t reliably determine a filter’s expiration status directly within the list view. This led me to rethink the interaction and collaborate with engineering on a more feasible solution. Eventually, I utilized a dedicated tab to categorize expired filters, and paired it with clear expiration messaging to help users quickly understand why those filters were no longer applicable.

In my initial exploration, I considered two approaches: Either automatically removing invalid filter values while notifying users of the changes, or disabling the entire filter set and displaying an error message directly in the filter list view. However, during iteration, I realized both approaches relied heavily on real-time API validation, making them impractical within the existing technical constraints.

I then shifted the handling into the filter detail view instead. After validating with SMEs, I believed the better experience was to still allow users to apply the filter and view the available results, rather than blocking them entirely. I explored marking missing values directly within the filter detail view, and indicating unavailable values again on the results page. However, after syncing with engineering, I learned that identifying exactly which values were missing required additional API calls, which would negatively impact system performance.

Given that constraint, I explored alternative approaches – such as allowing filters to be applied while automatically omitting invalid values and notifying users afterward, or providing a general warning message and guiding users to the filter detail view for more context. I also considered surfacing guidance directly on the results page to help users adjust invalid filters. However, I later realized these approaches were also infeasible due to the same API call constraints.

I further explored giving users two options: applying the original filter set as-is, or applying the filter while omitting invalid values. However, after confirming with engineering, I learned that even when invalid values were not actually applied, they would still appear in the filtered results view. Since we could not automatically remove those missing values from the UI, the experience risked becoming misleading and confusing for users. As a result, I ultimately introduced a disclaimer-based solution as a pragmatic workaround to address the API limitations while still keeping users informed.

I started by mapping out four key scenarios and exploring solutions for each. Throughout the process, I continuously involved the DS team in ideation and iteration to ensure consistency and bring in broader perspectives. I also partnered closely with engineers to validate feasibility and investigate technical constraints, ensuring the solutions were scalable and implementable.

My initial idea was to show an error message when users applied a deleted saved filter, and automatically refresh the page. However, after syncing with engineering, I learned the system could not detect deletion at the moment of application without making an additional API call, which would lead to a legacy issue.

We then co-created a new proposal: triggering an API call to verify whether the saved filter still existed after a filter was applied. If it has been deleted, users would be prompted to refresh and retrieve the latest state. If they chose not to refresh but modified the filter, the “Update Saved Filter” option would be disabled, while “Save As” would remain available.

Although this solution was workable, we believed a pre-check experience would provide a better experience. The DS team and I re-aligned with engineering to evaluate the cost of an additional API call, and found it would introduce roughly 2–4 seconds of latency (server response time). To maintain a smooth experience, we might need a loading state (like a spinner) during the wait.

After another sync with backend engineers, I arrived at a solution that is both feasible and more user-friendly: If users are simply viewing the page with no changes, no message is shown. If they edit the filters and choose to save as a new one, we allow it without interruption. If they attempt to update an existing filter, we notify them that the original saved filter no longer exists and guide them to use “Save As” instead. If users land on a page via a URL linked to a deleted saved filter, we still render the filtered view as-is, treating it as a new filter state, while informing users and offering the option to save it as a new filter.

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.