Saved Filters
Unified Content Library


About Saved Filters

This project is more based on pattern definition and design compared to the Unified Content Library project, which is focused more on detailed screens and the design of a new product and features. The saved filters process was extremely heavy on validation research and interviews with users, and is very focused on defining success criteria and making sure each use case of these new filters are addressed so that the user experience is seamless. 


What's wrong with our current filters?

Lost efficiency. Many use cases across AWN products have very robust filtering requirements, where users have to manually adjust a plethora of filters to whittle down the data into a digestible state. And that can be a lot of filters! This isn't only tedious, but also leads to added inefficiency in the workflow that can lead to lots of wasted time especially when multiplied across the entire userbase. We are trying to address this issue by looking into ways to allow users to immediately save and access filter sets.


Current State

What I did first was to try and dig deep into the Current State of the filters at AWN to understand the pre-established patterns of the product and how this new feature can fit into it, along with making note of ways the user experience may be improved in general. What was important for me to remember is that this ticket is not re-inventing the current filters — AWN has a robust design system and many established patterns throughout their products already, and we want to play within that court. This limited my options quite a bit, especially when I was researching competitors and what was already out there (namely Qualitrics, Notion, and Linear).

My current state research involved:

  1. Consulting with engineers and product of the technical constraints
  2. Learning of established design patterns surrounding filters from SMEs
  3. Identifying pain points through current state journeymaping and flows
  4. Conduct some competitor research to see what was already out there

A critical part in my research was determining the use cases of how filters are implemented across each of the products currently. For this, a workshop for each SME was set up with their respective products to determine individual use cases of filters and whether the saved filters function will be necessary for each case. This helped narrow the scope and focus and helped define exactly where the function will live.


Use Cases

SMEs were prompted with a template to complete a highlighting the ways filters are currently used at AWN today. Screenshots of filters with context and pain points for each product were collected.

Other SMEs and users were pinged to give context on their specific products to get a more wholistic view on how filters are used and integrated and how they may be improved.


  1. Identify current filtering use cases
  2. Gauge utility of Saved Filter functionality across products – if it’ll be necessary or desired
  3. Identify opportunities based on existing research and context


  1. Understanding of the current filtering experience(s), and identifying any opportunities for saved filters
  2. Gauge utility of Saved Filter functionality across products – if it’ll be necessary or desired
  3. Identify opportunities based on existing research and context

The use case workshop looked a little something like this:

(Except there were about 12 of these frames as we had one for each product under each SME. Some details are blurred for privacy purposes.)


🔑 Key Takeaways

  • Development Constraints:
  • Saving multiple filterable pages locally was not technologically feasible -- this rules out the possibility of tabs
  • Validation: Saved filters will benefit existing tables, and improve ease of use
  • The pattern must be flexible and simple enough to be implemented into multiple contexts, as there are many use cases for filters across AWN products that are quite robust. I have to take care to not focus too intently on any single product
  • AWN has many existing pre-established patterns. These patterns exist for familiarity and ease of navigation for users. I need to ensure my designs makes sense with the established patterns
  • These are patterns like the location of CTA buttons always being in the bottom right of a filter bar


Key Flows

These flows are to capture the save filter, view filter, edit filters, and delete filter functionalities. Efforts were made to not draw too much attention or to make the design too salient on the interface itself, in order to not make the user feel as if these were necessary steps. These were developed in conjunction with a future state journey map (not pictured) to give me a more holistic view on interaction and user workflows. This step was extremely helpful in giving insight on how to proceed to next steps.

(User flows for saving filters and editing saved filters.)


Wireframe Sketches

Referencing the above flows, I started putting together rough wireframe sketches. These sketches were quick and rough, to list out all possible options in order to visualize them and immediately rule out possibilities that weren't feasible:

(Some sketch exploration before I dug deep into cleaning and finalizing components and patterns on Figma.)


🎒 Filter Set Selection

Goal: Intuitive, Invisible, Effortless

Designing the user experience and layout around the way users will view, edit, and apply filter sets seamlessly was a particularly challenging part of the design and was the part that went through the most trial and error with design reviews and iterations. Competitors all approached this vastly differently, and none of them seemed to fit perfectly into established AWN patterns. 

Design can’t be done in a vacuum. While the saved filters pattern will be an important QOL update to users, it is not the main purpose of the filterable page. Designing a flow that didn’t demand too much attention away from the main focus required me to put my thinking cap on.


Filter Details Bar

Pattern: Always located bottom right corner of the filter bar

  • Used for save and edit filter flows
  • Save in a combination button: New for saved filters
  • Follows pattern of primary buttons being placed more to the right


Save CTA

Pattern: Saving on an existing filter set overwrites the previous settings

  • The Save CTA is the modal that appears when selecting "Save" when the filter doesn't already exist
  • "Save As" pulls up this modal in all instances
  • This acts both as a confirmation that the user wants to save the filter set, and also to allow the user to name the set for ease of discoverability


Manage Saved Filters

  • A location for users to view, search, and edit their saved filters
  • Presented in a popup modal that will overflow into multiple pages in the case of many saved filters
  • Action menu allows for "Delete" and "Rename" actions
  • Extra resistance in the form of a confirmation modal for deletion
  • Edge case: If the user deletes while the filter set is selected, the applied filters will remain in the filter bar


Select Filter

Pattern: Saved filters will be separated from the rest of the filter bar with a divider

  • This is to access the applying filters flow. All saved filters will be selectable from a single dropdown within the filter bar
  • Applying any saved filters will load the specific filters from that set into each field in the filter bar, which is then editable


🎀 A Few Last Steps...

Goal: Ease of Implementation, Understandability

To make sure everything was hitting the mark, I called a few key users from different teams to test the patterns in typical smoke tests.

To minimize guesswork during dev handoff, I also made example use case flows in Figma, so devs know how these elements will look in each one of AWN's products (the one's we indicated will need this function, as we established in the SME Workshop.) This also involved UX Design Guidelines and a lengthy documentation file on Confluence just to make sure we're speaking the same language. Devs are users too! I worked on making everything as easily understood as possible -- having designs implemented incorrectly would be a usability nightmare!


Final Thoughts

In an ideal world where I have more time with the company, my next steps would be to oversee the launch of these saved filters across internal tools and monitor the success. As this is a new feature, I’m curious about how intuitive the flow is. I would’ve loved to analyze initial interactions through HotJar to see where the flow could be improved and iterate upon those findings. I also would’ve loved to analyze the effectiveness of saved filters as a whole in speeding up the workflow of engineers. The saved filters project introduced me to more robust use case research than I was used to typically doing in my previous projects and I’m extremely grateful for the experience I was able to gain in this opportunity. 


About Unified Content Library

I wanted to showcase this project in particular as it took a completely different structure compared to the Saved Filters project, where lots of pre-planning and personal research went into the structure of the final patterns. The Unified Content Library (UCL) ticket was more of a fast paced design process where I had to hit the ground running. While this isn't traditionally what is seen in these case studies which have very defined and detailed design processes, there are many cases where jumping right in is necessary as well.


Where's the inefficiency here?

The UCL is a new feature in the Data Explorer of the AWN Managed Risk. It is a solution to the disarray of risk information the security staff needs to hunt down to address customer issues, and a portal for customers to search their own necessary data instead of contacting Security Services (S2) each time. The need to check multiple sources leads to context switching, increased engineering effort, and therefore increased wait time for customers. The UCL solution will decrease the load on our own staff along with improving QOL for customers. Any reduction in the time S2 takes to address customer tickets is a win.




Research on this project was on a much smaller scale than the saved filters project. A big part of this was speaking with key members of the S2 team to understand their workflow and understand which features would be most important for them to do their job most efficiently. ‍


🔑 Key Takeaways

  • S2 wants to:
  • Search for a type of vulnerability and CVE 
  • Ability to filter on vulnerability and CVE
  • Display a list of updated CVEs/vulnerabilities
  • Display the following columns: ID/Name/Vulnerability/Severity
  • Want a smaller product to ship internally first 
  • Customer facing integration out of scope until a later date

Through this we established an MVP of just the search and details page initially, and the other defined pages will remain out of scope until they are implemented at a later date.


Lo-Fi Wireframes

There were 8 wireframe sketches that were created by the product team for each page that was determined to be a part of the UCL in pre-planning. Out of the 8 pages (overview, browse, catalog, etc.), only the Search and Details page were determined to be the MVPs of the project, and is what we are focusing on. For full context, I created mockups for all defined pages to best sort out how they will all be linked together to be implemented at a future date. The MVP wireframe examples are:

(Low fidelity wireframes for the UCL MVP functions.)


Hi-Fi Designs

The brunt of the work was translating those lo-fi frames into the existing AWN design system with respects to established patterns. This meant I had to take note and flip through past and existing designs and patterns to make sure the components I adhered to adhered to them. This meant I had to tweak the designs away certain interactions and layouts in the lo-fi frames.

Here's a little peek at my designs for the holistic experience in the UCL, including all the interactions and functionality as initially outlined in the planning phase. We decided to just go forward with development for the MVP pages first, but it was nice to have everything to visualize the entire experience, and having everything definitely helped with decision-making during product meetings and design reviews. I won't be able to go in depth on everything as much of it isn't even in development yet, but I hope I'll be able to show off the designs in the future!

(Frames, states, notes, and UX guidelines for the UCL.)


🌟 Final MVP Frames

These are a few of the final frames for the MVP. I've opted to only include the base states of each in this case study, so you won't see every state possible for these pages.

The next steps at this point was getting everything validated and running the designs over members of the S2 team that will be using it the most at first.

The MVP, the details and search page, will be initially pushed internally to S2 and opened up to MR customers down the line. It allows the user to filter and search their risk data and see all important data related to it instead of having to hunt down each individually.


Final Thoughts

What I would've done next involves a lot of data collection and testing. I would have loved to research on the ways this feature increases efficiency and decreases time spent by S2 on customer inquiries. And further in the future I would be ecstatic to learn the statistics around customer requests after it gets opened for customer use. And of course, iterate, iterate, iterate. I didn't have the chance to make a prototype for testing this time, but my next steps given I had more time would be to do moderated testing with S2 members with a prototype and iterate upon those findings.

An internship doesn't give way to much flexibility overseeing the development of the projects finished during the term. It always makes me a little sad I won't be able to see each design come to completion and iterate on the product!

↑  Back to Top